How to Connect a Non-Standard Device with No Code

Posted by Kevin Rutherford on Jan 4, 2018 2:00:00 PM

l ask you to remember back to our blog post last month where took the information we pulled from a device’s protocol document (in the prior month's blog) 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 click here).

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 professional services 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 detailed how-to 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, click here.)

To begin troubleshooting the protocol, 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.

Configuring OmniServer COM Settings

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.

Configuring OmniServer Ethernet Connection

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.

Configuring OmniServer Topic Settings

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, click here.

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.

A Sample OPC DA Test Client Installs with OmniServer

Ready to start working with OmniServer step-by-step?  Click Here for the Detailed How-To

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 hardware vendor protocol manuals, 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 – click here)

  • 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:

    Enabling Sends and Receives in OmniServer Logger

  • 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 detailed guide, I’ll show you how you can tell.

    Using Item Values to Determine Client Connectivity

  • 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.

    Troubleshooting Hardware Errors with OmniServer Logger

  • 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.)

    Viewing Sent Data with OmniServer I/O Monitor

  • 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.)

    Viewing Unknown Received Device Data in OmniServer I/O Monitor

  • 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.

    Viewing Successful Received Device Data in OmniServer I/O Monitor

  • 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.

    Confirming Good Item Value and Quality in OmniServer Item Values Window

  • 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.

Click Now for Free Protocol Evaluation

Make sure to subscribe to our blog so you don’t miss future useful topics on OmniServer and other helpful industrial automation topics.

Click for Detailed OmniServer Protocol Troubleshooting How-To

Topics: Wonderware, Device Integration, OPC UA, OPC, Protocols, OPC DA, OmniServer, drivers, connectivity, ProtocolDesign

Join Our Journey

Working in industrial automation since 1996, the Software Toolbox team has seen a lot. The level of automation system sophistication of our integrators and users has evolved, each driven by the demands of their market and clients.  Everyone's learning continues as technological change accelerates.

This blog is about sharing from these journeys.  From tips on implementing software, successes our clients have experienced, or new ideas and things to consider in your journey, we'll be sharing them here.

Subscribe to Our Blog

Recent Posts

Posts by Topic

see all