Software Toolbox Technical Blog

6 min read

How to Implement a Custom Protocol for a Non-Standard Device with No Code

Dec 21, 2017, 2:00:00 PM


So remember in our blog post last month where you just have a protocol document from the manufacturer for a device you need to integrate with your control system?  And for this new device, there is no existing, off-the-shelf connectivity driver or server available.

And remember asking yourself, “How do I connect to this non-standard device?”  With custom software development being very expensive and time-consuming, we discussed a better way using OmniServer.

This post, the second of three, goes beyond the protocol details we gathered from the document in our blog post last month to provide the basics on how to actually use those details to build a working protocol in OmniServer without custom code for a fast, affordable solution with industry-standard client interfaces including as OPC DA and UA.

So last month we talked about the challenges of integrating the multitude of “non-standard” devices out there without a common protocol like Modbus where there are no existing drivers or servers on the market.  Again, typical devices falling into that category that we’ve seen over the years are barcode scanners, weigh scales, printers, RFID systems, sensors and so many more.

And the key focus of the post last month was going through documentation that the manufacturer of that devices has provided to find the necessary details for the commands and responses needed for communicating with those devices.

So now you’ve reviewed your documentation and found all of the relevant details that we discussed last month that you need to get started using OmniServer.  But what are the next steps?

I’m going to go through what the steps are, in general, to get you oriented to working with OmniServer and what the process looks like.  Then, if you’re ready to start working on your own protocol, I’ll give you access to a how-to document that goes into more detail.

Step 1:  Create a New Protocol in OmniServer

The first step in working with OmniServer is always to create your Protocol.  The Protocol is the heart of all communication operations in OmniServer.  It is responsible for all sends and receives to the device.

Creating a New OmniServer Protocol

This includes taking data from your client applications (HMI/SCADA and others) and properly formatting that data such as written setpoints or other variables or configuration settings so that the device recognizes the data and executes the request.

And, just as importantly, the Protocol is responsible for interpreting data coming in from the device, separating out the data you’re expecting and sending it to your client application.

The Protocol includes all of the variable items, messages to and from the device, error detection codes and more.

Think of the Protocol in OmniServer the way you would think of a “driver” in your typical off-the-shelf server for communicating with a specific device.  You will have a unique Protocol in OmniServer for each type of device using the same protocol.

Ready to get your hands dirty?  Click Here to Access Detailed Protocol Design Steps

Step 2:  Create the Register Numbers in the OmniServer Protocol

In an OmniServer Protocol, we define addresses/registers (used mainly by PLCs or RTUs) in what is called a Register Number.  This will allow us later to describe the data item with a number at the end of the name, thereby telling OmniServer that we want the data from a particular register.

Creating Register Numbers in OmniServer Protocol

This keeps us from having to define one item for every address we need to address in the device, which is a great tool for time-saving when building an OmniServer protocol.  Do you have to use Register Numbers?  No.  You can explicitly define each item you need and hard-code the address in the host message.

This means you will have to create a host message for each item. If there are 20 or so items, this is not a problem. If there are thousands, then this will be a burdensome task.  So using Register Numbers are all about efficiency and time-savings when building your Protocol.

For further details on what Register Numbers are and how they work, see our video blog post on Register Numbers.

Step 3:  Create the Items in the OmniServer Protocol

The next thing to look at is the number of data items to be returned by the device.  An Item is how your client application interacts with OmniServer for commands and requests.  Through Items, your client can pass data to the server for further processing, and in turn, the server parses data and sends it back to the client through the Item.

Register Numbers can be used in conjunction with Items to allow you to minimize the number Items you have to define in your OmniServer protocol.  When using Register Numbers, OmniServer can read in only one item at a time, so the Item count will automatically be one data item for each register.

Creating New Item in OmniServer Protocol

What OmniServer will do is read in the number at the end of the Item name and associate that number with the Register Number “Reg”. Any place that “Reg” appears in a message, that number at the end of the data item will be inserted.

And for responses from the device containing that register number, the value will be passed into that specific instance of the item.  Again, for further details on what Register Numbers are and how they work, see our video blog post on Register Numbers.

Step 4:  Create the Command/Response Message in the OmniServer Protocol

Now we need to tell OmniServer how to communicate with the device. This is done through a Command/Response Message.

Command/Response Messages are designed to obtain responses from or send data/commands directly to the device. This is accomplished through the Request and Response portions of the message.

Creating Messages in OmniServer Protocol

For further details on the different settings available in the Command/Request Message definition, I encourage you to watch my video on the basics of configuring a solicited Omniserver protocol.

Want to get started?  Click Here to Access Detailed Protocol Design Steps

Step 5:  Save the OmniServer Protocol

Last, but certainly not least, make sure to save all of the changes you’ve made in your OmniServer Protocol.  I always recommend saving frequently just to make sure you don’t inadvertently lose any important work you have done.

Saving Your OmniServer Protocol is Important

And, if all that you’ve seen is more than you have time for, just remember we do have affordable professional services which is a popular option for users who would really just like us 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

Once you have your OmniServer Protocol ready to test, the bulk of the work is behind you.  Make sure to subscribe to our blog so you don’t miss the rest of this series where next month we’ll polish things off by creating a Topic and Device, in addition to going through the testing process to debug your new Protocol.

Click for Detailed OmniServer Protocol Design How-To

Kevin Rutherford
Written by Kevin Rutherford

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