• Resource Library
  • MachineLogic
  • MQTT Communication with MachineMotion
Related Resources:
  • 11 - Intro to Lambda functions
  • State Machine (Beta) - MachineLogic
  • 10 - Intro to MachineCloud
  • Setup of Robot Programming in MachineLogic for Universal Robots e-Series
  • Robot Programming in MachineLogic
See all MachineLogic Resources
Back to resource library
How to guide Updated: Thursday, February 23rd 2023

MQTT Communication with MachineMotion

Contents

  • Overview
  • Introduction to MQTT
    • Definitions
    • Main advantages of having an MQTT broker
  • Programming
  • Wiring & Safety

Overview

In this document you will learn how to set up your MachineMotion controller and automate your machine, while using MQTT as the message protocol.

Typical use cases of bi-directional communication with MachineMotion:

  • Robot-MachineMotion communication (e.g. 7th axis sensors sending command to a robot)
  • PLC-MachineMotion communication

Figure 1: MachineMotion

Introduction to MQTT

Definitions

  • Client: Device that can send (publish) and receive (subscribe) data
  • Packet: Data sent by a client
  • Topic: Subject line through which packets are sent
  • Broker: Piece of software running on a computer which acts as the transit between another device or another broker

Message Queuing Telemetry Transport (MQTT) is a bi-directional lightweight message protocol which consists of a set of rules that defines how Internet of things (IoT) devices can publish and subscribe to data over the Internet. MQTT is used for messaging and data exchange between IoT and industrial IoT (IIoT) devices, such as embedded devices, sensors, industrial PLCs, and now, MachineMotion.

Each client can produce and/or receive data by publishing and/or subscribing. A client can publish a packet for a given topic, and anyone who subscribes to it can receive a copy of all messages for that topic. Multiple clients can subscribe to a topic from a single broker, and a single client can register subscriptions to topics with multiple brokers. This helps in both sharing data and managing and controlling devices. A client cannot broadcast the same data to a range of topics and must publish multiple messages to the broker, each with a single topic given. With MQTT broker architecture, the client devices and server application become decoupled. This allows clients to communicate with a single common recipient, and therefore funnel all information from the same place.


Example:

Here is a simple example to illustrate a common situation in which the user wants MachineMotion to communicate with a robot.

  • Packet: Sensor’s message
  • Payload: Sensor message’s data (e.g. 0 or 1)
  • Topic: Sensor-Topic

  • Client 1: MachineMotion controller
  • Broker 1: MachineMotion’s MQTT broker
  • Broker 2: Robot’s MQTT broker
  • Client 2: Robot

Figure 2: MQTT example 1

If a sensor communicating with MachineMotion has “publish” capabilities, Broker 1 (MachineMotion’s broker) has subscribe and publish capabilities, and the robot’s broker has subscribed to MachineMotion’s broker, a change of state of the sensor will automatically be received by the robot. In this specific case, the sensor status will send the signal to MachineMotion, which will then send the message to the robot.


Main advantages of having an MQTT broker

  • Eliminates vulnerable and insecure client connections while reducing network strain
  • Can easily scale from a single device to thousands
  • Manages and tracks all client connection states, including security credentials and certificates, if configured to do so

Programming

MachineLogic allows you to easily program your machine through its graphical interface and its low-code infrastructure. When it comes to MQTT communication, the same simple programming approach applies. To create a MachineLogic program using MQTT communication, here are the main commands:

To subscribe to a given topic, the State Machine or Wait For command can be used.

Figure 3: Subscribe to a topic in MachineLogic

To publish to a given topic, the General Event output command can be used.

Figure 4: Publish to a topic in MachineLogic

For more complex applications, you can also include payloads via the Variables and Functions features.

Figure 5: Variables and functions feature on MachineLoigc


Example:

To illustrate what you learned in this document, let’s use a design where a robot is mounted on a robotic range extender using a MachineMotion controller.

For a simple use case, the range extender could alternate between 3 different states:

Figure 6: MQTT states example

In order to communicate with the robot, the range extender must subscribe and publish different topics using TCP/IP communication:

Figure 7: Publish and subscribe MQTT example

In this situation, having a range extender communicating with a robot allows the user to easily program a sequence in which the range extender reacts to a few inputs from the robot and vice versa. Digital I/O communication could have been used in this example, but the transfer of payload for specifications such as distance, speed and acceleration would not have been straightforward. Please keep in mind that this example is for training purposes, and it would probably require adjustments to meet your specific needs.


Wiring & Safety

MachineMotion has a Mosquitto MQTT broker. It can therefore publish and subscribe to MQTT topics to send/receive packets of data. Through a single Local Area Network (LAN) cable connection, you can connect your MachineMotion to the other controller or a router. As a reminder, MachineMotion runs on a server 192.168.7.2

Figure 8: MQTT ethernet wiring

In terms of safety, the Robot Safety Module is the interface between Vention’s MachineMotion 2 controller & robots’ safety interfaces. The Robot Safety Module manages the safety fault events that happen on the machine to safely stop both the MachineMotion 2 controller and the robot. Please find below the wiring table for a typical use case in which bi-directional safety is required when it comes to a project using MQTT:

Figure 9: MQTT safety wiring

The client would have 2 requirements to be compatible with this solution: an MQTT broker and a safety interface (for bi-directional safety). For the latter, here are the minimum requirements:

  • 2 x dry contact inputs for STO (to be connected on the TO ROBOT connector of the RSM)
  • 2 x 24V safety output (to be connected on the FROM ROBOT connector of the RSM)
  • 1 x RJ45 connector (to communicate with MMv2 and pendant via Ethernet and the RSM)

Please refer to the Robot Safety Module technical documentation for more details.

Was this information helpful?

Still need help?

Ask the User Forum Contact support