MicroLink Remote Control, MicroLink MQTT Remote Control
Streamline IoT in industrial environments. Unlock MQTT capabilities effortlessly through Micro800 controllers.
MicroLink MQTT is a transformative suite of User-Defined Function Blocks (UDFBs) for Micro800 controllers, enabling seamless MQTT communication with any MQTT broker. This package includes three function blocks: one for establishing connections, one for subscribing to specific topics, and one for publishing data. It offers high customizability with settings for unique MQTT IDs, broker/server IP addresses, usernames, passwords, and your chosen Quality of Service (QoS).
Target to use with PowerFlex 523 and 525 component drives from Rockwell Automation.
This code can be used with the following equipment:
- PowerFlex 523
- PowerFlex 525
- Micro850
- Micro870
- PanelView 800d
What is this for?
MicroLink MQTT is a UDFBs suite designed for seamless integration with Micro800 controllers from Rockwell Automation. It's meant to enhance the capabilities of these controllers by enabling MQTT communication with any MQTT broker.
This solution is especially useful for remote control use cases and in the industrial field where data exchange and communication efficiency are critical. MicroLink MQTT provides three function blocks for establishing connections, subscribing to specific topics, and publishing data.
With MicroLink MQTT, users can easily establish a connection to an MQTT broker, subscribe to the data they need, and publish data back to the broker. It offers high customization options for MQTT IDs, broker/server IP addresses, usernames, passwords, and your chosen Quality of Service (QoS), ensuring efficient and secure data communication.
Therefore, whether you're an industrial operator looking to optimize data communication or a developer who needs to integrate efficient data exchange in your applications, MicroLink MQTT can be the perfect solution.
General Features
Our package provides three core User-Defined Function Blocks:
- RA_MQTT_CONNECT_v2: Step into the future with our connection function block. It lets your Micro800 controller establish a connection with an MQTT broker, setting the stage for robust data interchange.
- RA_MQTT_SUBSCRIBE_v2: Leverage our subscription function block to stay connected with the data you need. Tailor your subscriptions to specific topics from the MQTT broker and always keep your operations data-rich and up-to-date.
- RA_MQTT_PUBLISH_v2: Take control with our publish function block. Transmit data with precision by publishing topics to the MQTT broker, making your data-driven operations a benchmark for others to follow.
Each function block is highly customizable, allowing you to specify unique MQTT IDs, broker/server IP addresses, usernames, passwords, and your preferred Quality of Service (QoS). With RA_MQTT v2, every aspect of your MQTT communications is in your hands.
Limitations / Disadvantages
- Limited to Micro820, Micro850 and Micro870
- Third-party MQTT broker dependent
How can I make it work?
The architecture implies using Micro820, Micro850, Micro870 hardware. And this is the required software:
- Connected Component Workbench, version 21 or higher.
- The firmware of the equipment used must be compatible with the version of Connected Component Workbench.
- User-defined Function Blocks:
- RA_MQTT_CONNECT_v2
- RA_MQTT_SUBSCRIBE_v2
- RA_MQTT_PUBLISH_v2
Knowledge
A foundational understanding of ladder programming and system configuration using the Connected Components Workbench software is highly recommended. Additionally, familiarity with MQTT protocols would be beneficial.
Downloads
Please note: You will need to agree to the Terms & Conditions for each download.
Need Help?
If you need help with an application or have feedback from the Innovation Center, please contact us.
Installation Guide
Step 1:
Establishing Connection Settings to Connect to or Disconnect from a MQTT Broker
An MQTT broker essentially serves as a server to manage MQTT messages. To connect to an MQTT broker, we must input the broker's IP address and port number into the RA_MQTT_CONNECT_v2 UDFB. The broker could be housed on your computer (in which case you would need to install and operate an MQTT broker compatible with your OS), or it could be a remote server, such as the ones previously mentioned.
1.1 Assign the IP address and port number of the MQTT broker to your RA_MQTT_CONNECT_v2 UDFB
This example is for connecting to the test.mosquitto.org broker in the cloud. An alternative to entering the IP address directly is to enable Domain Name Service (set ‘EnableDNS’ TRUE) after entering in the MQTT broker URL into ‘MQTTBrokerName’ and the local DNS server IP address into ‘DNSIPaddr’ in rung 2.
1.2 Enter a unique ‘clientName’, as well as a ‘userID’ and ‘userPass’ if your MQTT broker requires it. (Many public MQTT brokers do not require a username and password, so these fields are optional and can be left blank if not required.)
1.3 Set ‘EnableMQTT’ to TRUE to connect to the MQTT broker.
Note:
There are a few things to keep in mind to ensure a successful connection. The MQTTsocketSts should eventually display a 9. If it shows a 7 and then reverts back to 0, it could imply that your broker is either not running or doesn't exist.
The data in resultData_Out is helpful for diagnostic troubleshooting. Typically, when you send a connect command to the server, the server responds with an acknowledgement. The acknowledgement is indicated by the 1st byte, which in this instance, is '32'.
Another frequent response you'll receive is a ping acknowledgement, denoted by '208' in the 1st byte of the returned data. The ping command is sent to the remote broker at 50-second intervals. This interval is hardcoded in the UDFB but can be modified if needed.
If the return data is something other than 32 or 208 upon connection, it could suggest that the client has subscribed to a topic that was broadcasted while it was offline. The message is retained and sent to the client when it comes back online. If you encounter this, process the message and then reinitialize the connection.
1.4 If you want to configure for LWT, you need to access these parameters in the UDFB:
322| willTopic := willTopic_In;
323| willData := willData_In;
‘willTopic_In’ is where you enter the Last Will topic for the connection.
‘willData_In’ is where you enter the testament for the connection.
The MQTT broker will publish the testament to all clients that subscribe to the Last Will topic when the client is disconnected abruptly.
1.5 If you want to disconnect gracefully from the server (without triggering LWT), set ‘disconnect_Cmd’ to TRUE.
This is a rising edge triggered bit, so you can reset it immediately.
Step 2
Subscribing to or Unsubscribing from a Topic
The MQTT protocol exchanges data through subscribe and publish methods. Clients communicate directly only with the MQTT broker. Clients subscribing to a topic will receive a message from the broker when another client publishes to that topic. Clients can be of any form as long as they have a running MQTT client application. For example, it could be software on a PC, a connector or API for the software, an app on a phone, or application code on a PLC.
2.1. Enter the name of the topic (‘topicName_input’) to subscribe to or unsubscribe from.
2.2. Set the quality of service (‘subQoS’) for the subscription. By default, use ‘0’ as it consumes the least bandwidth.
2.3. Set ‘subscribe’ or ‘unsubscribe’ to TRUE to subscribe to or unsubscribe from the topic.
2.4. These bits detect for rising edge, so you can reset them immediately.
2.5 Notice that the resultData_Out from RA_MQTT_CONNECT_v2 is also copied to respondData_In.
Note:
It is recommended to use only 1 instance of each UDFB.
Step 3:
Publishing a Topic
When a topic with data is published to an MQTT broker, the broker then forwards this topic data to all the clients subscribed to it. The client that publishes the message does not know if any remote nodes receive the topic, as that responsibility lies with the broker, depending on the QoS level. Topics can be published or subscribed to at any QoS level, but they will only be delivered at the lowest QoS level.
3.1. Enter the topic to publish into ‘pubTopic_In’.
3.2. Enter the data for the topic into ‘pubData_In’.
3.3. Set the quality of service into ‘pubQoS’. By default, use ‘0’ as it consumes the least bandwidth.
3.4. Set ‘publish’ to TRUE to publish the topic with its data. It will automatically will be set back to FALSE when ‘publishDN’ becomes TRUE.
3.5. Notice that the resultData_Out from RA_MQTT_CONNECT_v2 is also copied to respondData_In.
Step 4
Getting Messages from Subscribe Topics
The MQTT broker handles all topic subscriptions. It sends the data of any published topic to the clients that are subscribed to it. When a topic is received by the Micro800 MQTT client, it populates the 'TopicName' and 'TopicData' array variables in the RA_MQTT_CONNECT_v2 UDFB. The data is stored in a First In/First Out order, so it is crucial to process the data before it gets overwritten.
Step 5
Subscribing to an Array of Topics
MQTT_Subscriptions is an optional Structured Text program that works in conjunction with the MQTT_Client program. It enables you to subscribe to a 'Subscriptions' array of preconfigured topics. Adjust the array dimension of the global variable 'Subscriptions' to the desired size and modify the initial value of the local variable 'maxSubscriptions' to match the array size (default=10). 'Subscriptions' is a User-Defined Data Type (UDT) array that comprises the MQTT topic 'Name', the latest topic 'Data', a timestamp based on the RTC value when the latest topic 'Data' was received, and a 'Subscribed' indicator. Enter the desired topic names to subscribe to as initial values for Subscriptions[i].Name before downloading the project to the controller.
Local variable 'enableSubcriptions' must be TRUE in order to enable this functionality.
Step 6
Automatically Publishing an Array of Topics
MQTT_Publications is an optional Structured Text program that works in conjunction with the MQTT_Client program. It allows you to publish an entire 'Publications' array of preconfigured topics. Adjust the array dimension of the global variable 'Publications' to the desired size and modify the initial value of the local variable 'maxPublications' to match the size of the array (default=10). 'Publications' is a User-Defined Data Type (UDT) array that comprises the MQTT topic 'Name', the latest topic 'Value', the previous topic value 'Valueprev', and a timestamp based on the RTC value when the latest topic 'Value' was published. Enter the desired topic names to publish as initial values for Publications[i].Name before downloading the project to the controller.
Set the local variable 'ChangeOfState' to TRUE to publish any value that changes on an exception basis. Set the local variable 'Interval' to TRUE and 'intervalTime' to a non-zero value to publish all of the current values that aren't null ('') on a timed interval basis. Typically, one would choose either 'ChangeOfState' or 'Interval' as the method for publishing topic updates. For a one-time update, set the local variable 'OnDemand' to TRUE to publish all current values that aren't null (''). 'OnDemand' is set to FALSE once the entire 'Publications' array has been published. The local variable 'enablePublications' must be set to TRUE to enable this program functionality.
