Do you have a multitude of non-standard devices with unique identifiers such as a Device IDs or Node IDs that must be sent as part of all protocol messages to communicate with each device? If so, you could certainly accomplish this by hard coding your Device/Node IDs as part of each message in your OmniServer protocol and simply have a separate protocol for each device.
But OmniServer has a better way: Topic Variables. In this sixth post in our “OmniServer Did You Know?” blog series, you'll learn how to use Topic Variables to create one flexible protocol that you can use across any number of devices using the same communication protocol.
Say you have 2, 3, 50, or maybe even 500 similar devices connecting to one computer. (By similar, I mean they’re using the same communication protocol.) And each of these 500 devices has a unique Device or Node ID (or address) and each device won’t respond to requests unless its own Device ID is included in the request. Or, in the case of report-by-exception or unsolicited, each unsolicited message will have a unique Device ID to identify which specific device the message came from.
For example, consider the Modbus RTU Serial protocol. If you’re familiar with the Modbus protocol at all, you know that the first byte in a request is the device’s Node ID, which is required to match what the device is configured for; otherwise, the device won't respond. Rather than creating a separate OmniServer protocol for each device with the unique Node ID hard coded, it’s easy to create a single protocol to talk to them all using the Topic Variable component in your messages in OmniServer.
If you missed our fifth post on how to initialize your device with OmniServer, get caught up here!
Why Would I Need To Do This?
In many installations, especially factory floors, devices are used throughout the building to measure and track the manufacturing process. The number of instruments in use could range into the hundreds - especially barcode scanners and weigh scales.
The implementation architecture of these devices is usually similar: groups of them are linked to a device such as a terminal server or an RS-485 line which then relays the information back to a main server or group of servers (which is where OmniServer would be installed).
To most effectively account for these individual devices, the OmniServer protocol needs to be streamlined to prevent unnecessary processing overhead for the best performance. Using the Topic Variable, OmniServer protocols can be configured so one protocol can be used for all devices.
This increases processing efficiency in the OmniServer runtime as well as reducing the engineering time required to create an OmniServer protocol that covers all devices using the same communication protocol.
How Can I Do This?
In most serial protocols, there's at least one byte that represents the device's ID or address on the line. The concept with a Topic Variable is that the Topic Variable will replace this address in the message so the protocol will be generic enough to use for many devices instead of hard coded to work with just one Device ID.
This use case applies to both unsolicited communications (i.e., the device sends data messages as they're available without OmniServer having to request it) and solicited communications (i.e., the master - OmniServer in this case - must send a request to get a response).
As an example of unsolicited communications, suppose a barcode reader on a serial network outputs the following information:
12,5584ABC1<CR>
The ID of the device is first, then a comma, then the barcode itself, and finally a Carriage Return.
Here's how to set it up in the OmniServer protocol:
- Create and test your protocol for the instrument as if only one existed. Using the example above, your Unsolicited Message will look something like this:
(Where {Barcode} is a String item for receiving the barcode value) - Next, create a new Topic Variable in the OmniServer protocol called “DeviceID”.
- In the Received portion of your Unsolicited Message, replace the 12 in the message with the sequence {DeviceID:I}. This sequence uses the Topic Variable you just created.
As the term indicates, this results in a new variable being available in your OmniServer Topic when this protocol is assigned to that Topic. OmniServer will take the number defined in the Topic Variable field of the Topic (explained below) and replace it as an integer number (the ":I" in the message). Your Unsolicited Message will now look like this:
- Save your protocol, then open your Topic configuration from the OmniServer tree view. You’ll notice you now have a new section called Variables with a new field. Type in the address of the device in the new field. Your topic definition screen may look like this:
- Click Save to apply the change to the Topic Variable field.
- Test your protocol. Since the Topic Variable value of 12 means OmniServer is still processing the message such that it is looking for an integer value of 12, it will return the barcode value from your device with Device ID 12 into the Barcode item in your client application. (If for some reason this doesn't happen, please refer to our easy Troubleshooting Guide.)
- Now, to connect a second device (let's say with a Device ID of 5), simply create another topic that uses the same protocol and the appropriate device and insert the number 5 in the Topic Variable field.
- Then you'll create another tag in your client application, one that points to the same item, but a different Topic.
Internally, when OmniServer receives a message, it will look at the number in front of the comma and, using the construct {DeviceID:I}, determine to which specific Topic the data value will belong.
So how does this allow you to have 100 of the same type of device on one COM port with one protocol? Easily!
Just create the protocol using a Topic Variable as covered above (and, as I mentioned earlier, the same concept applies with solicited communications using Host/Request messages – the Topic Variable is defined in the same fashion as the Received portion of an Unsolicited Message), and create 100 different topics, making sure you place the device's specific ID in the Topic Variable for the appropriate Topic.
Then create 100 different tags in your client application, one for each Topic/Item combination, and you're done.
Where can I get more information?
Topic Variables, where your devices’ protocol supports them, are a crucial tool in making sure you’re working smarter and not harder when creating your OmniServer protocol. It’s one of the many ways OmniServer provides economies of scale for larger device counts with non-standard device integration.
Email us at support@softwaretoolbox.com with your protocol questions to determine if you can take advantage of Topic Variables and subscribe to our blog for more quick and easy OmniServer tutorials and tips. And for more detailed information on advanced OmniServer protocol subject matter, I encourage you to watch our free deep dive video on advanced protocol features in OmniServer.
