Message-passing is integral to multi-agent or distributed systems. The IO automaton of distributed systems, for example, constitutes a pretty decent way of modelling the interface of a machine (such as a conveyor).
MachineLogic was built upon the node.js ecosystem, which provides for a multitude of options in terms of communications protocols, transport layers and interoperability. In its current state, MachineLogic only supports MQTT, HTTP, and (more recently) Ethernet/IP. There is a multitude of communication protocols out there - if there are some you would eagerly want to see on the Vention platform, do let us know (ideally with some context)!
The rest of this article will demonstrate various flavors of message-passing currently supported in MachineLogic.
1. MQTT
Sending MQTT messages is as simple as using the Output instruction with the Generate Event option. The Message can be formatted dynamically by a lambda function (e.g. passing in variables evolving over time). In the example here, we just inline a hard-coded json object.
Note that the MachineMotion controller comes with a MQTT broker. It’s possible for multiple agents to communicate via that broker.
Receiving messages is just as simple. A WaitFor instruction (illustrated below) is required, usually in the context of a dedicated parallel event handler (n.b. alternatively, a target state in a FSM instruction may also be triggered by a received MQTT message). In the example below, the Unpack Variable Name establishes a sequence-local variable that will automatically be assigned the payload of the received message. You can then parse this message and extract the fields of your choice, using a lambda.
Note that the pub-sub model of MQTT provides for great flexibility, as it lets you receive messages asynchronously from any other activity.
2. HTTP
Communicating with a HTTP REST server represents a simple way of extending MachineLogic, or of integrating external components. For example, you might want to delegate persistence of some values measured during the operation in MachineLogic, to an external system (*). Another use case could be to obtain an entire mission definition from a webapp (e.g. a spatial arrangement of objects to pick or place somewhere), to be translated by your MachineLogic program into an actual physical process.
In any case, the pattern is similar to the one seen earlier with MQTT (though arguably simpler since it appears in a single pseudo-synchronous request-response form; in the example below, we did not use a lambda to parse RETURNED_PAYLOAD - as we had just above in the MQTT case - but this would be a typical pattern).
(*) in which case you would
POSTaPack Messagethat you may have formatted using a lambda function accepting some of your variables