If you're familiar with OmniServer, you likely already know how OmniServer is commonly used to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.
But a common challenge is configuring an OmniServer but not having a real device physically available to test against. However, with a little extra configuration and a second PC with OmniServer installed, you can create a "device" version of the same protocol to test against.
Reviving our "OmniServer Did You Know?" blog series, I will cover how a second OmniServer can be configured to act as a test device for troubleshooting your protocol when a physical device isn't available.
Over the years, I've provided a lot of OmniServer protocol consulting services, helping users configure their devices' protocols for integration with OmniServer. And a physical device is almost never available in these situations. It's typically not practical for a user to ship an actual physical device for use in creating the protocol. While sometimes it might be possible to configure the protocol while remotely connected to the user's OmniServer machine that is connected to a physical device, internal IT restrictions or other limitations often make that impractical, as well.
So it is most common to configure an OmniServer protocol to the best of your ability using simply your understanding of the protocol documentation (for tips on "interpreting" a device manufacturer's protocol documentation, check out this post). And, once complete, that OmniServer protocol can be copied to the user machine connected to the device for testing and can be tweaked at that point using OmniServer's built-in diagnostics tools such as the I/O monitor.
If you missed our original blog series "OmniServer Did You Know?", get caught up here!
However, it can also sometimes be useful to use a second OmniServer configured with a second protocol that acts as a simulated device. That way, the OmniServer where you're configuring your actual primary protocol can connect to this secondary OmniServer, which acts as a device, responding as an actual physical device should.
Now when you’re trying to use a second OmniServer to act as a device (to emulate a device), how the second OmniServer protocol has to be configured differs depending on the specific protocol. You basically have to create a protocol to use on a different machine that is the “opposite” of the actual protocol. I like the analogy of how one jigsaw puzzle piece fits with another jigsaw puzzle piece.
How Can OmniServer Act as a Device?
It’s important to understand the basic functions of the two primary types of message in an OmniServer protocol as a first step:
- Command/Response Message (formerly referred to as a Host Message) - Sends data and may or may not expect to receive a response. The "Request" section defines the packet to be sent to a device and the "Response" section, when required, handles processing any the response (where applicable) back from the device in response to the request.
- Response Only Message (formerly referred to as an Unsolicited Message) - Receives data and may or may not send a response. The "Received" section defines the packet that OmniServer should expect to receive from the external device or client and the "Response" section (where applicable) defines the packet that OmniServer should send back when a packet has been received matching the "Received" section.
So if the primary protocol has a Command/Response Message, the “emulation” protocol acting as a device would need to have a corresponding Response Only Message configured to receive the command from the actual protocol and, if applicable, a Response message that matches what the primary protocol’s response is expecting. For example, the diagram below shows a primary and secondary protocol that mirror each other for communications between different OmniServer instances.
And the reverse would be true if the primary protocol has to be Response Only (this is common for barcode scanners and other devices that simply send data as soon as it's available). The “emulation” protocol acting as a device would have to have a Command/Response Message configured with the command being the message the actual protocol’s response only message is expecting and, if the primary protocol will send a corresponding response, the “emulation” protocol’s Command/Response Message would also have the response portion configured to match that response from the primary protocol.
This all works because of the nature of OmniServer – it’s all just sent and received data (either over Ethernet or serial) at the end of the day. You just have to determine which side is the sender of a message and which side is the receiver and configure the “emulation” protocol accordingly. The goal is for the “emulation” protocol side of things to behave the way you’re expecting an actual device to behave based on the manufacturer's protocol documentation.
As for configuration of the Devices in OmniServer, assuming Ethernet communications, the primary OmniServer would have an Ethernet device configured with the IP Address of the secondary OmniServer machine. The port that is used just needs to be an unused port on both machines and match what you will use in the corresponding Ethernet device on the secondary OmniServer.
The secondary/device OmniServer would have an Ethernet device configured with the IP Address of the primary OmniServer machine and the same port as the primary OmniServer's device.
In the scenario where the primary OmniServer is sending a request and not waiting for unsolicited communications, you just make sure the "Inbound Connection" settings is enabled in the Ethernet device properties of the secondary OmniServer's Ethernet device (here, the port will be defined as the "Listen Port").
Alternately, in the scenario where the primary OmniServer is receiving a request in an unsolicited fashion, the "Inbound Connection" setting is enabled with the corresponding "Listen Port" entered for the primary OmniServer's Ethernet device.
Are There Other Uses for Two OmniServer Instances to Communicate?
Over the years, I've seen situations where the use case might warrant actually having two OmniServer instances communicating beyond just protocol design and troubleshooting. If you happen to have two OPC, SuiteLink or DDE client applications on separate machines with no other shared interface or means of communication, you could certainly use two OmniServer's configured with items and messages to share data between the two pieces of software.
With this sort of use case, though, I encourage you to contact us with the specifics of your systems and the exact use case, as we may have alternatives that make more sense for your particular application. But OmniServer is definitely one option we would consider for such an application.
In such a situation, your options for how the two companion protocols would be formatted is wide open given that you're not limited to a specific device manufacturer's protocol. You would need to first consider what data items you would need to share and if the communications needs to be uni-directional or bi-directional.
You'll likely want to include some form of starting character or characters at the beginning followed by one or more items (for more than one item, you'll want to use some form of delimiter such as a comma or semi-colon between items/fields) and then terminated by one or more characters. For instance, you might have a data string that looks like the following in a Command/Response Message for one protocol (on the side of the system sending the data) and in a Response Only Message in the corresponding protocol (on the side of the system receiving the data):
{$STX}{DataItem1},{DataItem2},{DataItem3}{$ETX}
And vice versa if you needed both systems to be be able to send data variables bi-directionally. Other options like checksums or other error detection are also possible.
Where can I get more information?
Are you working on a protocol and don't have a physical device but would like to do some testing in advance and the above steps sound like a good fit? Or do you have a use case for sharing data between two OPC, SuiteLink or DDE client applications but aren't sure how to get started? As always, we're happy to help with a complimentary protocol review of your protocol documentation or to answer questions you may have and suggest a path forward.
Email us at support@softwaretoolbox.com with your questions and subscribe to our blog for more quick and easy OmniServer tutorials and tips. Then, make sure to download the OmniServer trial to try it yourself for free.
