Adventures in Data-driven Automation Systems

Sunday, March 29, 2009

ControlLogix DateTime Add-ons

A cool new feature of ControlLogix v17 is add-on instructions. I had originally hoped that these would be great replacements for indirectly addressed subroutines since zooming into an instruction shows you the logic but only displays the data of the current instance of the instruction. However, Rockwell strongly discourages using add-ons for large, complex subroutines, and the inability to edit them online really made them undesirable for that use.

They are good for encapsulating reusable pieces of code though, and Rockwell has provided some samples that perform manipulation of DateTime values, which I have already put to good use. The instructions included are:


  • T_Add - Adds a time span to a DateTime and returns a new DateTime
  • T_Clock - Sets or returns the controller clock time
  • T_Diff - Returns the difference between two DateTime values
  • T_Dow - Returns the day of the week for the passed in DateTime value
  • T_Equ - Compares two DateTime values for equality
  • T_Geq - Compares if one DateTime value is greater than or equal to another
  • T_Grt - Compares if one DateTime value is greater than another
  • T_Leq - Compares if one DateTime value is less than or equal to another
  • T_Les - Compares if one DateTime value is greater than another
  • T_Lim - Compares if the DateTime value is within a low and high limit range
  • T_Neq - Compares two DateTime values for inequality
  • T_Now - Returns the current controller clock value
  • T_Scan - Returns the previous scan time
  • T_Sel - Uses an input bit to select one of two DateTime values
  • T_Sub - Subtracts a time span from a DateTime value and returns a new DateTime value
  • T_Sun - Returns the local sunrise and sunset times
  • T_TtoS - Converts a DateTime value into a human-readable string
  • T_Valid - Checks if the given DateTime value is valid

I used the T_Now and T_Sub instructions to calculate the local date/time using a local offset. We use UTC time in the PLC to avoid time change issues and calculate local time using the current local time offset.

You can find these by opening the Start Page in RSLogix5000, selecting Open Sample Project, and then choosing Add_On_Instruction_Samples.acd, or going to [Drive]:\RSLogix 5000\Projects\Samples\ENU\v17\Rockwell Automation\.

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.