Components: Graphs: MainGraph: Parallel: - A # two graphs are executed - B A: Sequential: # children graphs are executed sequentially, next is started as soon as previous is finished - Parallel: # children graphs are executed in parallel, all started at the same moment and this block is finished when all children finish - Type: MOVEMENT # start Motor 1 Parameters: motor: Hardware.Motor1 speed: x rotation: 90° - Type: MOVEMENT # start Motor 2 Parameters: motor: Hardware.Motor2 speed: y rotation: 360° - Type: MOVEMENT # Motor 4 is started when Motor 1 and 2 are done Parameters: motor: Hardware.Motor3 speed: z rotation: 360° B: Sequential: # children graphs are executed sequentially, next is started as soon as the previous is finished - Type: MOVEMENT # Motor 3 is started Parameters: motor: Hardware.Motor3 speed: x rotation: 180° - Parallel: # when Motor 3 is done, start Motors 1 and 3 in parallel - Type: MOVEMENT Parameters: motor: Hardware.Motor1 speed: s rotation: R° - Type: MOVEMENT Parameters: motor: Hardware.Motor3 speed: x rotation: 360° To interact with the PC, a simple line of code is enough. For example, to change the speed parameter x, all we need to do is: local graph = actiongraph.ContextGraphPath actiongraph.SetPram(graph .. 'x', 1.5) This is an arbitrary example, but it quickly becomes clear that you will reach the limitations of inexpensive motion controllers at some point. Complex motion controllers can, of course, provide the desired results, but this has its price tag in both value and complexity. Let's increase the requirements again. If we assume that the system has to process parameters from a camera in real-time and control a digital output to trigger a gripper, this is where things usually get really complicated – and expensive. With our technology, this does not have to be the case.