Implementing a Custom Serial Bus

Sometimes the best solution is to implement your own communications protocol from the ground up.

The company I work for produces industrial signal conditioning modules and switch-mode power supplies. Signal conditioners are normally small units that take an input signal -- typically an analog signal like a thermocouple -- and convert it into a form that can be processed by a Programmable Logic Controller (PLC) or by a general-purpose computer running control software. Many of these modules have an embedded microcontroller.

Modules are normally mounted on a TS35 rail and housed inside a panel. Here are prototypes of two different modules that we make.(Click here to see a larger image.)

There is a move in the industry to add displays, but because the modules are small and competitively priced, these displays are normally of the seven segment format. Often, the modules also have associated parameters, and setting them up requires DIP switches or some creative use of the displays. Fans of my work (hi, Mom!) will remember that I wrote a series of articles on the NKK Smartswitch in Circuit Cellar in 2002. (See Part 1 and Part 2.) That work was a precursor for a protocol we designed to approach this market.

Our DataView monitoring a power supply. The package requires a standard cutout in the panel.(Click here to see a larger image.)

It would be nice to have an alphanumeric display for the modules, but the cost of the NKK Smartswitch would make the price prohibitive. The modules would also be quite bulky. We rationalized that if we networked a bunch of modules and used a single Smartswitch, then we would amortize the cost, and this is how our DataView was born.

My intention was to create a one-button annunciator that would monitor up to 30 modules (of any combination), display data from each one of them, and also display alarm conditions when they arose. There would also be a provision to drive an external piezo buzzer as an audio alarm.

Memory limitations on the DataView led to a novel approach to both the protocol and user interface. The DataView is the master that continuously polls all of the modules for alarms. It only has a memory map of the different modules on a particular network and no other details of any module.

One of the modules is designated the "focus" and, provided there are no alarms, the data from this module is presented on the screen. The DataView does not know what types of modules are out there or what will be displayed. It merely provides access to the screen, rather like a video multiplexer. It is a master with no control of what actually appears on the screen -- only who writes to the screen.

Alphanumeric data can be displayed.(Click here to see a larger image.)

Graphical data can also be displayed.(Click here to see a larger image.)

A module could have several data screens presented in a rolling sequence by a single press of the DataView button. To change the focus to the next module, the DataView button is pressed twice. To revert to the previous module, the button is pressed three times. To invoke a parameter change, the DataView button is pressed for five seconds and the module is notified to change the screen to its configuration menu. The elegance is that the displays are carried in the device that generates them -- an integral part of the module development without any additional development on the DataView.

An alarm condition will take priority over the display of any module, with a typical response of a flashing red backlight of the LCD and alarm message. The backlight will stop flashing when the alarm is acknowledged by pressing the button.

The protocol consists of a fixed-length message structure. The master has a few commands in its vocabulary. These include interrogating a slave for status, requesting a screen update, reporting the number of key presses, and initiating or quitting a setup sequence in the slave. The slave's vocabulary allows writing text or graphics to the screen (including text size and inverse video), setting the backlight color and flash condition, providing alarm status on request, activating the audio alarm output, and initiating the sequence to move to the next/previous slave module.

Communications are over a half-duplex RS-485 bus at 56K baud. There are no real distance issues, since all of the modules will reside inside a single panel. Another advantage is that the display projects through the front of the panel, so data is accessible without opening the panel. Of course, this setup could compromise the environmental specification of the panel if waterproofing were to be a requirement.

The bottom line is that sometimes you just have to implement your own communications protocol. Have you ever created your own protocol, or have you always used existing solutions?

That too, actually, or "almost." In our case, in 1999 or so, we had to develop an actively redundant link layer protocol, for high speed, high survivability networks. Lo and behold, in 2010, IEC 62439-3 is created: Parallel Redundancy Protocol. It's not identical to ours, and I much prefer our approach for a couple of reasons (nothing like developing your own to understand the advantages and disadvantages of other approaches you had to explore in the process), however overall, the way it works is the same. The differences are in flexibility of the link layer topology and in maximum speed the protocol can support.

The fun part of the job is to keep track of the ongoing standards efforts, and then adopt (and adapt) the successful ones when it makes sense to do so, while still retaining compatibility

the thought occurs to me that on rare occasions this goes the other way, when a proprietary bus is standardised. I'll bet every standard of early serial bus started that way. GIven the structure of Modbus, you can just feel the evolution from a single purpose idea into the general purpose standard.

Absolutely! This topic of rolling your own, vs. using an existing standard, came up in a recent article by Junko Yoshida as well.

We very much created our own protocols, and entire digital networks, before standard ones were good enough to do what we were building. The fun part of the job is to keep track of the ongoing standards efforts, and then adopt (and adapt) the successful ones when it makes sense to do so, while still retaining compatibility with the proprietary protocols that came before.

Ultimately, for our work, adopting standards allows you to improve the products more rapidly. Because you're leveraging off the work of thousands of smart designers all over the world. However that wasn't the situation at the beginning. For my work, this has been true for protocols and also for hardware.