Does your non-standard instrument connected to your COM1 serial port refuse to communicate without being told how? Do you need to tell the instrument what bank of memory to use before you can extract any data? Does the instrument require setup parameters before it will work? Do you not want to script this in your client application, and don’t want to expect a user to manually initialize a device before doing anything else?
With OmniServer, there is an auto-activated message flag that's exactly the feature you have been looking for when communicating with your non-standard devices and instrumentation. This fifth post in our "OmniServer Did You Know?" blog series focuses on how to use OmniServer's setting for auto-activating a command protocol message to initialize communications with your device automatically on startup.
Many non-standard devices out there may require that a communication channel be setup or initialized before actual data requests and responses can be exchanged. With most devices, this could just be as easy as turning the device on – the initialization (or ‘zeroing out’) happens automatically as part of the powering process – but what about those devices that don't handle that initialization as part of their startup sequence?
If you missed our fourth post on using poll statistics in OmniServer, get caught up here!
Well, you could potentially script this in your client application? But let's think about that for a second. That sounds an awful lot like custom coding, which everyone likes to avoid wherever possible - it's one of the primary use cases for implementing a protocol in OmniServer.
Instead of scripting this in your client application – which can take up valuable time – or expecting a user to manually initialize a device, the OmniServer supports the capability to send out a message when your client first connects and communications with your device begin - a capability referred to as a message being "automatically activated."
When paired with other OmniServer protocol features like chained messages and error recovery (topics that will be covered in future blogs) auto-activated initialization messages offer an incredibly powerful means to not only set up your device, but automatically make sure that the host-device communications do not de-synchronize at any point during communications.
How Can I Do This?
Imagine that we are communicating with a printer that automatically prints part numbers onto a product – the part number incrementing by one with every part that passes the printer. The printer must be initialized with three parameters when we first connect: the expected line speed, the type of part that will be created, and the starting offset (i.e. what is the first part number of the first part that passes the printer).
Thus, it becomes OmniServer’s responsibility to send this message out when the client first connects and the server makes the initial connection to the printer to get the printer ready to work.
- The first step is to simply add a new host message to our protocol that will serve as the initialization message. Setting the message up to send automatically is as easy as checking the “Message should be automatically activated” option on the General Tab:
- Then, the actual initialization message to be sent can then be configured on the request tab, in this case the line speed, part name, and starting part number are passed – separated by horizontal tabs.
- Then, simply connect your client application to the OmniServer topic for this protocol and your device. That’s it, the moment your client connects to the OmniServer and subscribes to an item configured in the protocol the initialization message will be sent.
There are just a few additional things to keep in mind with this functionality:
- The message will never be sent out again automatically as long a client remains connected. This means that when a second client connects and reads values from this same topic/device the initialization will not occur a second time.
- However, the message can be manually triggered again via a trigger or chained message, if required.
- Triggering an initialization message as result of an error message offers an excellent way to gracefully recover from otherwise critical communication errors.
Why Would I Need To Do This?
The obvious reason is that automatically activating a message allows you to easily automate the necessary sequence of initialization messaging to get your device ready for actual communication with OmniServer without having to do any additional scripting in your client application.
It really is just as easy as the 1-2-3 above to set this up, whereas scripting would likely be much more involved and take more time and resources. It's just an additional way the flexibility of OmniServer saves you time and money when integrating non-standard devices.
Where can I get more information?
Do you have a non-standard device you'd like to integrate with your control system (one of those devices that maybe you're collecting data from manually on some schedule or, dare I say it, not collecting data from at all)? As always, we're happy to help answer questions you may have.
Email us at support@softwaretoolbox.com with your questions and subscribe to our blog for more quick and easy OmniServer tutorials and tips. To help you get started, I would encourage you to watch our free getting started video on building a protocol in OmniServer.
