In case you're not familiar with OmniServer, it is a user-configurable I/O server solution that you can configure through a user-friendly interface to communicate with various devices that do not already have off-the-shelf drivers written for them.
A question that our support engineers at Software Toolbox sometimes receive from both new and veteran OmniServer users alike is whether an item in the OmniServer sequence builder, which is used to build the send and/or receive message for a device protocol, requires a formatting code or not.
Continuing our Tech Support Corner blog series, this blog post covers under what situations a formatting code is required for an item defined in the OmniServer sequence builder of a protocol and when a code isn't required.
Since OmniServer is such a flexible communication server with so many different aspects of configuration, it's possible to learn something new even after having used the solution for years. If you've ever built an OmniServer protocol or even looked at some of the messages in one of the protocol samples included with OmniServer, you've likely noticed that sometimes an item defined in a message might have a formatting code at the end but sometimes they don't. (Need help getting started with an OmniServer protocol? Getting Started Here)
By default, if a formatting code isn't defined for an item in the OmniServer Sequence Builder, the parsing engine will look to the data type of the item as it's defined in the item list of the protocol. If the data that is actually received from the device matches that data type, everything is nice and the data is parsed correctly.
If the data received does NOT match the data type (for example, if a string value such as 123ABC was received but the item had a data type of "Real") the data will not be parsed correctly and an error condition will result.
When is an OmniServer Item Formatting Code NOT Necessary?
In an OmniServer protocol message, if you leave your item "unformatted", like this:
the OmniServer parsing engine looks at the original data type of the item and expects that type of data in the data stream being received from the device.
That behavior, as such, follows these guidelines based on the item's data type:
-
Discrete: An integer value that translates to "0" or "1" (i.e., "0000"=0, "0001"=1, "ABCDE"=1)
-
Integer: A valid set of integer numbers (i.e., "123"=123, "12.3"=Error, "ABC"=Error)
-
Real: A valid set of real or integer numbers (i.e., "123"=123, "12.3"=12.3, "ABC"=Error, "1.2E+03"=Error (see note below))
-
String: Any set of ASCII characters.
Note on the Error with Scientific Notation: Although "1.2E+03" is technically a valid "Real" number, OmniServer will see this as an error because of the way the parsing engine handles floating point values. You will need to use the "E" formatting code in OmniServer to read in that number.
When is an OmniServer Item Formatting Code Necessary?
If you expect any data fitting a format other than those described the above, you will have to format your data (such as data being Hexadecimal, for instance).
Now, all of that being said, there's absolutely nothing wrong with defining formatting for an item in the Sequence Builder even if it isn't technically necessary. For example, defining a ":S" formatting code for a string item will still work normally even if it isn't really necessary.
So it's perfectly okay to go with what you're comfortable with when building your OmniServer protocols if you prefer to define formatting for items all the time.
And, if you haven't already, don't forget to subscribe to our blog to get more useful tech support tips like this one and for the latest Software Toolbox product news each week. And download the OmniServer free trial to connect your own non-standard devices.
