MachineLogic-VSE (so called “no-code” machine programming) primarily focuses on making it easy to move actuators and robots, while also handling events coming from sensors, HMI and external systems.
In computer programming, these actions happening in the physical world (affecting the state of things outside the computer program) are sometimes referred to as “side-effects”. It may sound funny, when you consider that these “side-effects” are the very purpose of the program, but it’s a useful perspective nonetheless. Most MachineLogic-VSE instructions are directly involved with a “side-effect”.
But there’s another side to the story. A control program typically also has “pure” computing tasks to perform (e.g. parse and transform configurations and user inputs, calculate trajectories or target positions based on these configurations or other inputs, search solution spaces based on user, camera, encoder or sensor information, make time-dependant calculations, plan motions etc.). These tasks can be taken care of by processing units alone (CPU/GPU), without requiring other devices or “side-effects” per se. They are “pure” processing: inputs are transformed into outputs, that can then be used to request that the devices perform their tasks. MachineLogic-VSE deals with this sort of stuff entirely in the realm of its lambda functions.
This separation of concerns in a program, between the realm of side-effects, and that of pure computing, is usually considered desirable: the pure computing aspect becomes a lot easier to test, validate and reuse (no setup in the physical world is required to test this side of the program). MachineLogic-VSE imposes this discipline.
To fully benefit from this separation, it’s important to see how the two realms connect:
- lambdas never call MachineLogic-VSE instructions, it’s always the other way around
- you call your lambdas in the input field of an instruction accepting expressions
- n.b. in fact, just about anything could call your lambdas, since they are guaranteed to depend on no other context than their input parameters; for example, you can copy them into your browser’s debugger, or a nodejs session, and test them in isolation
- MachineLogic-VSE’s variables accept all core data types of javascript and json
- i.e. numbers, strings, arrays, dictionaries
- n.b. lambdas don’t have direct access to those variables, but can receive their values as parameters, and produce new return values
- the ‘Set Variable’ instruction acts as a bridge, between the pure and the side-effects sides
- n.b. this is the only place where you can modify the state of your MachineLogic-VSE variables
For example, you could declare a variable MYQUEUE in MachineLogic, and assign to it an array describing some tasks: [{'type': 'lift', 'height': 10}, {'type': 'drop'}]. You could then have lambdas that append new tasks to an array, pop the top task of an array, evaluate how many tasks remain in an array, etc. All of these lambdas will only produce new information. Every time MYQUEUE must be updated, a ‘Set Variable’ instruction will be required.
For more fun reading on this whole topic, the wonderful SICP textbook has a great section towards its middle, when the text starts drifting away from pure processing.