Messaging Devices Don’t Get No Respect

norespectThere’s a class of devices that just doesn’t get any respect. We all know and love I/O blocks, drives, photo eyes, valve blocks, and all the rest – the I/O devices. There are millions of them. Then there are the process devices – things like meters, gauges, and valves. Refineries have tens of thousands of devices like them.

But we don’t often think about the messaging types of devices – scales, markers, barcode readers, and RFID readers. They play a valuable role but take a backseat to the more common devices we deal with every day.

Messaging devices are interesting because they don’t integrate very well into the traditional factory floor environment. Scales, markers, barcode readers and such don’t play well with factory floor control systems that are designed to collect inputs, process logic, and distribute outputs every few milliseconds. These kinds of controllers were never really designed to work well with asynchronous devices. It’s a real challenge to integrate these devices into Modbus TCP, EtherNet/IP or ProfiNet IO architectures.

Limitations of messaging devices

Command Interfaces – Many of these devices operate based on command interfaces. A controller has to send a start command to start the scale conversion, to initiate a barcode read, or commence a marking operation that may last for several seconds. Programmable controllers can send these kinds of commands but it’s more awkward given their synchronous nature.

Transports – Many of the messaging devices were built to work with PCs. In the old days, that meant they were serial RS232 devices. Now they may have migrated to USB or Ethernet. Unfortunately, that’s Ethernet TCP not EtherNet/IP, Modbus TCP or ProfiNet IO. Most PLCs don’t have serial ports anymore, they certainly don’t have USB ports and don’t support generic Ethernet TCP.

Protocols – Not only are the transports an issue, but many of these devices use some sort of proprietary protocol. For a barcode reader, it might be as simple as a string terminated by a CR (carriage return) or LF (line feed) but even that can be a challenge for a PLC to accept. If the device uses a proprietary protocol, it’s not feasible to connect it to a programmable controller.

Data Types – The data types used by these messaging devices also make life difficult for programmable controllers. Standard Integer or Floating Point configuration or control data isn’t usually a problem but PLCs generally choke on the String data types. Many scales transmit data as ASCII Strings. Instead of a two word Floating Point value for 414.4 lbs, the scale sends five characters, “4 1 4 . 4”. It’s nearly impossible for a lot of the older controllers, and some of the newer ones, to do that kind of conversion. Data lengths also make life difficult. A 3D barcode or marker may be thousands of characters. How can a programmable controller store and transmit barcode, marker, or RDID data of that size?

For all these reasons and more, scale, marker, barcode, RFID, and other messaging devices are often nightmares for integrators to integrate into a factory floor control system. In the next article in this series I’ll describe a strategy to solve this kind of integration problem.