As you may be aware, OmniServer is updated several times a year to add additional useful features and tools, and to resolve any known issues as part of our continuous improvement process.
In this post, I will cover updates and enhancements available in OmniServer V3.2.0.5 to help you with increased flexibility for implementing protocols and updates for OPC UA client connectivity for integrating all of your non-standard devices.
Our development team is constantly working on our ongoing list of features and updates for OmniServer to keep it working in top form for connecting to all of your "other" devices that don't have a standard, off-the-shelf OPC or SuiteLink data server. To that purpose, you may or may not have already noticed the recent V3.2.0.5 release. For full release details, visit the OmniServer release history in our knowledgebase.
Going further than the release history, though, I'd like to cover a couple of the key updates in V3.2.0.5 in a little more detail to help you understand where and how they might benefit you in your OmniServer projects.
Updated OPC UA Server Interface Maintains Security and Reliability
Our development team periodically reviews updates to the Unified Automation OPC UA server toolkit that we utilize to provide a robust OPC UA interface in OmniServer for connectivity by OPC UA clients. As with our own continuous improvement process, Unified Automation has their own continuous improvement process. As such, we regularly consume those updates to keep OmniServer current with the latest standards and components.
To that end, OmniServer V3.2.0.5 has implemented the latest update for that interface which incorporates fixes, SSL and other third-party component updates. This ensures that the UA interface in OmniServer is as secure as possible and continues to perform and interoperate with OPC UA clients reliably.
New Strict Protocol Parsing Option for Increased Protocol Compatibility
As you may have learned if you've ever reviewed a protocol manual for a non-standard device, not all communications protocols are created equal. Occasionally, we come across certain protocols that will work with OmniServer but there is room for improvement. So we evaluate what we could do to enhance OmniServer to work with those and other such protocols more effectively.
In that spirit, we've added a new setting to OmniServer that forces a more strict comparison of the byte structure received from a device by OmniServer to the configured OmniServer protocol. This is particularly useful when a device's communications protocol responses don't have coded starting sequences that allow OmniServer to identify the start of a response.
This new "Use Strict Message Parsing" setting is disabled by default to maintain compatibility with the majority of protocols out there. For protocols where there isn't a clearly defined sequence of bytes beginning a device's response, this setting allows OmniServer to precisely compare byte-for-byte the entire sequence of received bytes to the corresponding response in the OmniServer protocol. If it matches exactly, the items get updated. If it does not match, the message processing enters an error condition, as expected.
For existing OmniServer users with working protocols, you should keep this setting at the default of disabled since you have already confirmed it works as desired. For users implementing new protocols who are having any issues getting their protocol to work and you're wondering if this setting could help, please contact us with details of your protocol.
Don't forget to subscribe to our blog to find out about the latest updates to OmniServer and for how-to videos and other resources on using OmniServer.
Ready to try these new OmniServer updates with your own non-standard devices?
