l ask you to remember back to 
where took the information we pulled from a device’s protocol document (
) and created a custom protocol in OmniServer. As you’ll recall, our protocol has now been designed.
But how do you go about testing the protocol and proving that it works? This final post in the series takes you through the steps of getting connected and actually troubleshooting your OmniServer protocol.
Our main focus last month was turning the information that we learned from the protocol document of our device manufacturer into an OmniServer protocol. (For a review of how to create the protocol 
).
Now that we have the OmniServer protocol created, what are the next steps?
It’s important that users realize it’s the nature of protocols that hardware vendor documents are not always perfect or clear. That being the case, some fine tuning is typically necessary to work around those limitations of the documentation. Fortunately, we’ve built things into OmniServer to make fine tuning as easy as possible and are always working to make it easier.
And if dealing with a high level of details like protocol design isn’t your thing, our 
are available in as little as 1 hour increments to help you get things done quickly using our expertise.
So I’m going to go through what the steps are to get connected to your device, to start communicating and to analyze and troubleshoot those communications to get everything working the way you need it to. Then, if you really want to get started, I’ll give you access to a 
that goes into connectivity and troubleshooting step-by-step.
The following steps assume that you have a client program available. In this example, we use the generic OPC DA test client which installs with OmniServer (which you can also use for testing) that connects to OmniServer’s OPC DA ProgID “SWToolbox.OmniServer” with an OPC item name in the format “Topic.Item”. For your client application, check with its manual for details on how to connect to an OPC UA, OPC DA, Wonderware SuiteLink or DDE server. (For application notes on connecting to OmniServer with various clients such as Wonderware, 
.)
To begin 
, you’ll need to follow these steps:
Step 1: Create a New Device in OmniServer
A Device in OmniServer represents the physical connection to your actual device in the field. For the Meklar device in our example, we use a Serial/USB Mapped device type, where we specify the COM parameters as determined in the device documentation such as Baud Rate, Parity and Stop Bits. The Omniserver COM device type is also compatible with USB devices having a software driver component that maps them to a Windows virtual COM port.
OmniServer also supports physical connections via Ethernet (TCP, UDP or Telnet) which includes connections to serial device servers, serial terminal servers, serial-to-Ethernet gateways, or Ethernet encapsulation units that have been used to connect serial devices to a network.
OmniServer even supports legacy LPT printer port connections.
Step 2: Create a New Topic in OmniServer
The Topic in OmniServer ties together the Device with the Protocol. It tells OmniServer to look at specified device and use the specified protocol when the client program requests data from that Topic.
You will have a unique Topic created in OmniServer for each device you are communicating with. And this architecture is extremely efficient, as you only have to create one protocol for each of the same make/model of device and re-use that protocol across any number of those devices (as opposed to having to configure the same protocol multiple times). For more details on the re-usability of protocols with OmniServer, 
.
Step 3: Connect to OmniServer with Your Client
The next step is connecting to OmniServer from a client (HMI, SCADA, other). This is because OmniServer is a true “server” in that OmniServer will not make any requests without a “client” asking it to.
As I mentioned previously, we are connecting using the sample OPC DA test client that installs with OmniServer for this example.
Ready to start working with OmniServer step-by-step? 
Step 4: How to Troubleshoot a Protocol
So we’re connected to OmniServer from a client and accessing at least one item that we’re interested in from the protocol we’ve created. If you’re working with a well-organized and detailed document and everything was formatted properly in your OmniServer protocol, you will see a data value in your client application for that item.
However, let’s assume that your device documentation is ambiguous or not well-organized (which is not out of the ordinary) and this leads to your OmniServer protocol not exactly matching what the device is actually sending back. This is, in reality, a common occurrence because building protocols is a very detail-oriented process. We’re talking about making two machines talk to each other. And, in our experience with 
, they aren’t always perfect!
All it takes is for one character to be out of place or not accounted for, and OmniServer will reject the message and not deliver the data up to your client because it won’t recognize the message.
Fortunately, we’ve been doing this since 1996, so we’ve built a lot of great tools into OmniServer that we’ll cover here to help you deal with the very detail-oriented nature of this type of work.
So the rest of this post will cover the various steps necessary to determine issues with your communication and address them. (For our easy-to-use OmniServer Troubleshooting Guide – 
)
- Get Your OmniServer Ready - For the best troubleshooting, we will need to enable all the logging for OmniServer to ensure that sends and receives are being pushed to the OmniServer Logger. To do that, make sure these four buttons are pressed down on the OmniServer Toolbar:
- Determine if the Client is Connected – As I mentioned earlier, OmniServer will not talk with the device until a client program has established communications with OmniServer and told OmniServer that it wants data. So the first thing to check is if the client program is talking to OmniServer. The Item Values window in OmniServer shows us whether this is true or not. In the
, I’ll show you how you can tell.
- Determine if there is a hardware issue - Select the Logger window from Diagnostics in OmniServer. Check the logged entries for any errors that OmniServer may have received on the device. The errors themselves will be fairly obvious in indicating what the issue is.
- Determine if OmniServer is sending out data - Now that we know there are no hardware errors, we can be confident that OmniServer has opened up the port. So the next step is to find out if OmniServer is sending out data on the connection using the I/O Monitor. (We’re looking for black data streams in I/O Monitor, which indicates Sent bytes.)
- Determine if the device is responding to OmniServer - Next, we need to determine that the device is accepting data from OmniServer and responding appropriately, also using the I/O Monitor. (We’re looking for non-black data streams to indicate received data – Green, Blue, Magenta and/or Red.)
- So You Are Receiving Data – But is it Correct? – If you have any colors in your I/O Monitor other than Black and Green (as shown below), this indicates an issue with the formatting of your Command/Response message in the OmniServer Protocol.
- Received Data is Green in I/O Monitor but Item Values Isn’t Displaying Correctly - It's always possible that your data is coming in correctly, but the data does not match what you want. If your data is being received, but interpreted incorrectly, this means that you will need to check your item assignments in the OmniServer protocol and make sure that they are correct or that the data is in the correct format - like reading a four-byte integer instead of a four-byte real/float.
- Item Values Showing Correct Value but My Client is Not - This is definitely a problem with the setup of the client in how it is reporting or formatting the data. You will need to check the client to insure the data is being reported correctly. Check for things like the data type, any scaling that might be applied, etc.
In closing, it's relatively easy to troubleshoot a protocol in OmniServer, if you keep a few ideas in mind:
- Troubleshoot one message or one item at a time.
- Work with just one topic at a time. Once one topic is working, any others should normally work, too. Having a lot of topics at one time makes troubleshooting much more difficult.
As I’ve said previously, if this process is just more than you have time for, remember that we have affordable professional services if you’d prefer that we to take care of it all for you while delivering training and support like you would get with any off-the-shelf driver.
Make sure to 
so you don’t miss future useful topics on OmniServer and other helpful industrial automation topics.
