Pulling DateTime from AB PLC

Hello all,

I’m trying to do some simple data collection on an automated cell and I’m having an issue with what info to pull from the PLC to create a Timestamp in Ignition. I know Ignition has a built-in timestamp feature but I want to store the timestamp from when the part went into the machine.

I’m new to Python/Java/SQL programming so this may be a simple thing, but I’m beating my head against the wall trying to figure this out.

Thanks in advance!

I’m not really sure why you want to pull the time from the PLC. When you do that you have to assume the PLC’s time is accurate. Personally I would use the time in ignition. I’m assuming your trying to collect data through out your process and write it all in one shot but if you have set points that you need to collect data you can use update queries to fill in data as your process is running. If your not comfortable with SQL your best bet would probably be using transaction groups that you set to execute on a trigger.

We’re going to try to use a Store and Forward method so we’ll have a ThinClient on-site near the machine that will pass information through to the database. This would be in case our network goes down for some reason we don’t want to lose the information we’ve gathered. From what I understand if I’m using the time from Ignition it would only take a timestamp of when the information was sent to the database and not when the information was pulled from the PLC.

I’m not positive how the timestamp works for store and forward but you could always do an extra data point that is a date/time and is not the timestamp. You can set up an expression item in the transaction group that is the current time. Even if the timestamps works the way you described this would be treated as regular data that should be stored and forwarded as it was at the time of the trigger.

If you want to pull a timestamp from the PLC:

  1. Create timestamp in PLC. There are various ways to do this depending on PLC and desired timestamp format. You can store it in this format YYYYMMDD & HHMMSS in a couple of DINTs, or use a single STRING.
  2. Make sure PLC time is kept correct (can build a timesync function in PLC that HMI writes timestamp to and then PLC code updates PLC clock).
  3. The timestamp is now just another piece of data you pull in with the other data. Your code in Ignition will need to parse it into a timestamp for stored data. If you’re using Tag Historian, you would use system.tag.storeTagHistory to allow you to set the timestamp on the data.

We do this (getting timestamp from PLC) routinely for some things where the PLC stores the data in a buffer the HMI reads from to avoid lost records on HMI restart.

Ok maybe I’m getting Timestamp and Date/Time mixed up. When we put a part into the cell I’m currently pulling the current date and time from the PLC and storing it into a DTS array of INT[6] (Year, Month, Day, Hour, Minute, Milliseconds). I’m looking to store that information along with everything else as a DateTime in Ignition. I’m not sure how to make that happen.

Use system.date.getDate and system.date.setTime to turn those values from PLC into a DateTime in Ignition.

Unless I’m misunderstanding, it sounds like you’re just grabbing the current PLC time with Ignition. If that’s the case, you’d probably do just as well to grab the current time from Ignition. We grab PLC time (and store it in the PLC as a timestamp) in order to get an accurate time to go with data regardless of when the HMI collects the data. If the HMI is just getting the current PLC date/time when it collects the data, current HMI date/time should accomplish the same thing.

If you bring those INT’s to ignition you can use the getDate(year, month, day) and setTime(date, hour, minute, second) expressions to build your date/time value in an expression. Basically do setTime(getDate(year, month, day), hour, minute, second)

What witman listed is the same functions but for use in a Python script.

1 Like

If you are using Logix processors with Time Synchronization (perhaps with a HIPROM GPS master), the GSV instruction can retrieve a wallclocktime in UTC to microsecond precision as an LINT or pair of DINTs. If you bring these into Ignition, and divide by 1000, you can create a Date() object from that. If you need to keep the microseconds, you can instead create a java.sql.Timestamp.

1 Like

I’m doing something similar to what Phil suggests using the latest CompactLogix with Fast Input cards, which have time stamping to the nanosecond (LINT). The PLC is synced to a PTP satellite clock (probably more than you need), but the Fast Input card records the time at transition. There is a Timestamp tag to read the card timestamp data, then I use an associated data instance in an alarm off of the event tag to record the Timestamp tag value/1000000.

I would agree that the PLC needs to trap the timestamp of the event and the PLC also needs to be synced to a reasonably accurate PTP time source (what CIP Sync uses), if you want any kind of PLC clock accuracy with your gateway.

if you’re using Linux on your gateway, you can install a (free) PTP2 time application which will keep the PLC synced to the gateway time.

1 Like

Microsecond, not nanosecond. These values are “Coordinated System Time”. Which is arbitrary microseconds. The processor maintains an offset that can be added to get UTC microseconds. java.sql.Timestamp can hold these values, and is the default subclass of Date() used by JDBC when reading/writing DB tables with microsecond timestamps or datetimes.

in the interest of accuracy (not argument) the Compact Logix 5380 controllers report the Wall Clock time via GSV in microseconds, of course, but to quote the 5000 Series Digital I/O Modules in Logix5000 Control Systems User Manual:

“The 5069-IB16F and 5069-IB6F-3W DC input modules offer submillisecond timestamping on a per point basis. Timestamp values have ±10 μs accuracy and ±1 ns resolution.”

Why they went with this resolution I don’t know. It’s actually somewhat problematic, since I know of no function that can divide a LINT in Logix5000, but Ignition has no problem doing it.

Interesting. All of the timestamped I/O data I’ve encountered so far has used straight CST (μs). Learn something new every day. (-:

Hmmm. Everything I just checked about CIP Sync says the values are microseconds, not nanoseconds. Suggesting the I/O manual for the 5000-series modules has a typo. Even there, the CIP Sync values are shown as simply an offset from CST.

Are you dividing by a million, or a billion?

Dividing by a million to get millisecond resolution.

When you go into the Compact Logix 5380 controller Date/Time -> Advanced Time Sync, it shows the “Offset from Master” in “ns”. (Synced with a GPS Clock)

I have never used CIP Sync on anything other than this controller, so I don’t know what other Control Logix controllers show there.

Just started using one of these for a time server. $500USD.

There’s also an AOI to poll an NTP server, if your system supports sockets. I use it for systems sitting behind units that won’t pass through multicast packets (e.g. 1783-NATR)

1 Like

On this topic, I am trying to use Ignition time for logic in a PLC. Does anyone have experience writing ignition time to PLC tags?