Practical use case: Operation orchestration

Automation and orchestration are the biggest strengths of the scripting approach. Do you know the actual difference between them? When we refer to automation - this means to perform an individual, repetitive task without human intervention. When we refer to orchestration - this means to sequence multiple such tasks so that they are executed in a specific workflow.

In other words: Orchestration sits on top of automation.

With this in mind, imagine that the operations in Process Simulate represent the automation tasks and the SCL scripts on top represent the orchestration logic. This logic determines when the operations start so they do not interfere with each other.

The concept is not new. You can do kind of the same with logic blocks and modules but the SCL script brings this use case to its full potential. Not only it makes the logic centralized and deterministic but allows you to make it much more complex. You are no longer limited to a single expression. You have the state machine of the script at your disposal. You can organize your logic more intuitively by means of statements and expressions. Use out of the box and/or custom functions and function blocks. Implement algorithms and debug the script looking for logical errors.

The script can trigger operations using their 'start' signals and monitor the execution using their 'end' signals. It can generate and/or destroy part appearances. It can organize operation loops. Use arrays and/or UDTs. In other words - it orchestrates the workflow.

But where do you start?

First you do the classic way of defining operations that are triggered by signals. These can be robotic, flow, device, human or non-sim operations.

In the operations tree create a new non-sim operation along with your target operations. Create 'start' signals for the target operations using the dedicated commands. Use the sequence editor to link the non-sim operation to each of the operations you want to orchestrate. Then use the transition editor on the non-sim operation to define alternative branches for the linked operations. Each operation should be triggered by its own 'start' signal. Then create a resource (Orchestrator) and open it in the SCL editor. Create input (BOOL) variables for all operation 'end' signals and output (BOOL) variables for all operation 'start' signals. Connect the signals to them. Now what is left is to define the logic for running the operations.

To run an operation set the corresponding output variable to 'true'. To stop it set the same to 'false'.

To check if an operation has finished, detect RE on the corresponding input variable.

In a simplified demo, let's say that we have a PNP operation that should be executed periodically and each time a new part appearance should be picked. We also have a generic robotic operation that returns the robot to the pick position. Both operations should run sequentially. One after the other.

Following the idea above, this is the code that I came up with:

FUNCTION_BLOCK "MAIN"
VERSION:1.0
VAR_INPUT
	op1End : BOOL;	// operation 1 (PNP) end
	op2End : BOOL;	// operation 2 (Return) end
	part : TX_OBJECT;	// part to pick
END_VAR
VAR_OUTPUT
	op1Start : BOOL;	// operation 1 (PNP) start
	op2Start : BOOL;  // operation 2 (Return) start
END_VAR
VAR
	op1Trig : R_TRIG;
	op2Trig : R_TRIG;
END_VAR
BEGIN
	if SIM_TIME() = 0 then
  		// create the part appearance at time zero
  		CREATE_PART_APPEARANCE(PART:=#part.NAME);
  	end_if;
  
	#op1Trig(CLK:=#op1End);
  	if #op1Trig.Q then // operation 1 (PNP) ends ?
  		// re-create the appearance
  		CREATE_PART_APPEARANCE(PART:=#part.NAME);
  	end_if;
 	#op2Start := #op1Trig.Q; // trigger operation 2 (Return)

  	#op2Trig(CLK:=#op2End);  
  	#op1Start := #op2Trig.Q; // operation 2 (Return) ends ?
						  // trigger operation 1 (PNP)

END_FUNCTION_BLOCK

Place the resource with this script at the pick location so part appearances are created there. When you run the simulation, the appearance will be generated but the operations won't run until you toggle one of the start signals. You can also use a dedicated signal to trigger the process. Just change the code! Adapt it to your needs!

Add an emergency stop following: Practical use case: Safety button.

Add one more operation in the workflow.

In reality it would be the job of a PLC to organize the process. In our virtual environment this job is given to a simple SCL script.

Recently the idea of operation orchestration was successfully implemented by one of our teams. I would like to thank them for the inspiration that lead to this post.

Nice work guys!