Serial to PLC Gateway Nightmare

We've been using some really handy serial-to-PLC gateway products from Realtime Automation recently that are especially easy to set up and allow us to transfer data bi-directionally between the PLC and barcode readers, printers, etc. You connect them to your serial device and to Ethernet, then configure the device through the embedded web server. You set the IP address of the PLC that will send or receive the data, configure the register that will be monitored or written to, configure the serial port parameters and voila, you have communications! No PLC programming required other than reading or writing the data.

These have worked well, especially for bringing barcode data into the PLC, and have also worked well for simple printing, but we ran into problems when trying to print a large barcode label. The label format was too large to transfer all at once, so we had to chunk the data. Most of the time, the labels would come out perfectly, but occasionally they would leave out entire sections of the label, or even worse, modify single characters in a certain field! Have you ever arrived at a plant early in the morning, only to find the plant manager, and 2 engineers waiting at the door for you?

We didn't know where the cause of the problem lied, so we began trying to isolate it. I first ruled out the printers by writing a small .NET application to do the printing. We ran this for a few days and had no problems, so we could assume the printers were okay. Next, we had to know if there was a problem with the PLC code or the gateway. This was harder to prove. We tried using an RS-232 monitor cable with HyperTerminal to see if maybe the PLC was sending the data improperly, but the data was coming in garbled, so that didn't shed much light. We tried different cables, different RTA gateways, etc., all to no avail. After weeks of trying to pinpoint the problem, I decided to try a different vendor's gateway product. I ordered a Comtrol device, which turned out to be a little more complicated to implement, and required that we write message instructions in the PLC to write the data, but once we installed it, all of our issues magically went away!

Now, I am not saying that RTA's product is bad for printing, as I still don't know exactly what the problem was. We have had great success using the RTA devices with barcodes, RFID readers, and simple printing applications, but on the next printing application, I'm going to avoid the early morning meetings with management and use the Comtrol.