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.