As someone who has worked with non-standard device connectivity using OmniServer for almost 18 years, I've encounter most of the subtle nuances of certain protocols that a user might need to implement and how to do so in OmniServer. One such nuance (which is true even with "standard" protocols such as Modbus) is that it's not uncommon for device vendors to implement their communication protocols with variable or parameter values that use a unique byte order compared to ordering by the first byte received to the last byte received (also referred to Most Significant Byte to Least Significant Byte, Big Endian or Motorola Byte Order).
You may not be aware that OmniServer has several flexible ways to manipulate the ordering of bytes parsed into Items to be shared with client applications to ensure that the correct and expected value is always displayed in your HMI, SCADA, historian, MES or other client applications.
Returning and expanding our "Did You Know" OmniServer blog post series, I'll cover what byte ordering settings are available in OmniServer, when you might need to use them and how.
So users of OmniServer will likely recall that OmniServer makes it possible to configure a custom protocol/driver without custom code based on device vendor protocol documentation (or potentially other sources, when protocol documentation isn't available). So, once you've reviewed your protocol documentation and confirmed the format of messages to either be sent to the device or received from the device, you'll be configuring those messages in an OmniServer protocol. This tells OmniServer how to send or receive those messages and parse the appropriate byte or bytes in those messages.
Now ASCII strings of data (human readable characters) are generally parsed as they are received (i.e. ABCDEFG is literally received in that order from the device and would be the value displayed to a client application). Where ordering tends to come in most is with binary coded numeric values, where the value will differ depending on which order of bytes the device manufacturer intended the value to be interpreted.
For example, let's take a raw data value and look at how the value changes depending on how it's interpreted with respect to which byte is interpreted first:
Two-Byte Binary Value Represented as Hexadecimal 0x00 0x64
- Interpreted as MSB to LSB (0x0064) = Decimal 100
- Interpreted as LSB to MSB (0x6400) = Decimal 25,600
And this is a basic 2 Byte Integer value - the complexity compounds when there are 4 Bytes involved since it's technically possible to swap the byte order for each of the 16-Bit Words or possible to even have different byte orders for each of the 16-Bit Words.
OmniServer provides a couple of options for easily swapping which order such values are interpreted as coming from a device so that your client applications see the expected value as intended by the device manufacturer for a particular variable or parameter.
How to Swap Byte Order for OmniServer Items at the Protocol Level
For device protocols where the same ordering is used for all 2-Byte or 4-Byte integer type variables or parameters, it's very easy to swap how OmniServer interprets your Item values for the entire protocol for all messages and items in a single section of settings - under Protocol Settings > General/Byte Order.
[Screenshot]
As you can see, there are the following settings for swapping the Byte Order depending on what data type the item will be:
- Two-Byte Integer
- Four-Byte Integer
- Four-Byte Float (IEEE)
By default, OmniServer uses a Byte Order of LSB...MSB for each of these options.
Swapping these settings will result in all binary-encoded two or four byte integers or four byte (32-bit) IEEE floating point items defined in any of the protocol messages for that protocol being interpreted accordingly.
Going back to our example from earlier, let's take a look at an OmniServer protocol message response for a two-byte unsigned integer formatted item named "Temperature" (any Two-Byte or 4-Byte Signed or Unsigned Integer type with Binary encoding would be affected by these Byte Order settings):
With the default setting of LSB...MSB selected for Two-Byte Integer in the OmniServer protocol, we'd see the following result:
You can see that in the OmniServer I/O Monitor, the two bytes are coming in with 0x00 first followed by 0x64. However, you can see that the value displayed is 25,600 in the OPC Test Client. Decimal 25,600 converted to Hexadecimal using the Programmer version of the calculator included with Windows shows that value is generated when interpreting Hexadecimal 0x64 0x00 instead.
So, then we can change the Byte Order for Two-Byte Integer to MSB...LSB instead:
And we'd see the following result:
This makes it really easy to apply the same Byte Order formatting for all items in the same protocol. Most protocols will typically respect the same byte ordering for all fields. However, that is not always the case, which brings us to the even more flexible following options for applying Byte Ordering variations at the individual item level.
How to Swap Byte Order at the OmniServer Item Level
If you find that your device manufacturer has implemented their protocol such that variables or parameters don't following the same ordering all the time, OmniServer has an answer for that challenge. It's possible to assign specific formats to each of your item references in protocol messages by right-clicking on the item reference and selecting "Format" as shown below:
This launches the OmniServer Sequence Builder which makes it possible to perform multiple different tasks that are beyond the scope of this post, such as assigning items for bit-within-byte access and more. For our purposes, the Formatting tab has the settings we need for manipulating the Byte Order.
Of particular note here are the following settings:
- Reverse Text - This setting reverses the processing order for non-binary data types - so, for instance, an ASCII string of ABCDE12345 would be interpreted as 54321EDCBA
- Reverse Bits - This setting reverses the processing order for the bits within each byte - so, for instance, Binary 11000100 would be reversed and interpreted as 00100011
- Reverse Nibbles - This setting reverses the processing order of each 4-bit sequence (or nibble) in each byte - so, for instance, a byte with the bit pattern 11000100 would have the nibbles reversed and be interpreted as 00100011
- Order - This setting allows you to specify an exact order of the 2, 3 or 4 bytes of a sequence for processing by OmniServer, as you'll see below - the order specifies the bytes in order of Most to Least Significant.
For this topic, the most important of these settings is the Order setting - as you can see, any order pattern is selectable using this dropdown setting. For the example we used earlier, instead of changing the Byte Order at the protocol level, we could have also specified the desired Byte Order here.
Obviously, if it's a 2 byte sequence, there are only the options O12 or O21. As the number of bytes increases, so does the number of possible orders of processing those bytes. Knowing the right order to use ultimately depends on the device manufacturer and how they've implemented the protocol - ideally, they'll have documented the proper order.
Alternately, you would be left with trial-and-error of each possible byte order until you see the correct/expected value in your client application (or the OPC Test Client that installs with OmniServer - and is also available as a standalone installer for use with any OPC DA server).
You could also use the method you saw me use earlier - looking at the raw data response in the OmniServer I/O Monitor (for details on using the I/O Monitor in OmniServer and other troubleshooting tools, you can refer to our OmniServer Troubleshooting Brief) and using a calculator or other Hex to Decimal convertor. If you know the Decimal value you're expecting, you can enter that and confirm what the corresponding Hexadecimal bytes would be. Compare that to the raw data bytes and determine the proper order and set the Order appropriately for your item reference in the OmniServer protocol.
Using the example from earlier, the expected value was Decimal 100 (as opposed to Decimal 25,600), which told me, after plugging that into the converter, that the Hexadecimal bytes for a 2 byte sequence would be 0x00 0x64. And since the raw data in I/O Monitor was in the order of 0x00 0x64, then the corresponding Order for that item reference would need to be O21.
How to Recognize You Might Need to Swap Byte Order for Your OmniServer Protocol Items
As I've alluded to, if you're successfully communicating with your device (i.e. you have a value and good quality in either the test client or your own client) but the value is incorrect, that is one indication that OmniServer might not be interpreting the proper order of the bytes.
That, of course, isn't the only possible cause of that behavior - you'll first want to make sure you're accessing the right variable or memory location - once you've confirmed that, the other most likely cause is that the bytes aren't being processed in the right order.
In that case, using the information from this post should enable you to configure your OmniServer protocol to account for the byte ordering for your device and properly interpret your data.
Where can I get more information?
If you're new to non-standard device connectivity, perhaps you have a device with a protocol manual but you’re not really sure how to get started. As always, we're happy to help with a complimentary review of your protocol documentation and we have a library of detailed how-to video tutorials for OmniServer available here.
You can always feel free to contact us with your questions and remember to subscribe to our blog for more quick and easy OmniServer tutorials and tips. And, if you haven't already, make sure to download the latest free trial version of OmniServer to get started connecting your own non-standard devices.
