Timestamp in ML 1400

[wilkerson29847]

Good afternoon everyone,

I am setting up an MES server with some production machines that have ML 1400 PLCs in them. When I send the data to the MES software I have to send a unique ID for each part that is produced. I was wanting to use a time stamp for the unique ID, so we could identify when each part was made but how do I take the values from the RTC and combine them to create a readable timestamp?

 

[ASF]

Without having any detail as to what MES platform you're using, I'd suggest you'll need to concatenate all the RTC registers together with spaces and colons ( : ) in the appropriate places using whatever scripting engine is available to you, and then convert the string into a date/time data type.

If you provide more detail as to your environment, you'll get some more specific answers.

 

[Ken Roach]

Find out what type of database your MES system uses and what sort of timestamps are native for them.

The ControlLogix has a 64-bit LINT datatype that can be shown in the tag database as a Date/Time value.

In the ControlLogix, a decimal value of zero is shown on my computer as

DT#1969-12-31-16:00:00.000000 (GMT-08:00)

which indicates that they use the "UNIX epoch", where time began on January 1, 1970 at midnight GMT. Since I'm on US Pacific Coast time, the beginning of time is 8 hours earlier.

The MicroLogix 1400, though, has a "Long" data type that's a misnomer. It's a 32-bit signed integer, equivalent to the DINT data type on the ControlLogix.

To my knowledge, the MicroLogix 1400 uses a dedicated purpose Real Time clock microcontroller that outputs only the YYYY:MM: DD :HH:MM:SS values to the operating system. There's no way to get at the actual 64-bit Unix timestamp.

I am not aware of any example programs that have been written to use the 16-bit operating system of the MicroLogix to reverse the YMDHMS values into four Integer or two Long elements.

Another thing to be aware of before digging into this is that the MicroLogix RTC only updates the Seconds value every 2 seconds. I'd have to dig carefully to find out if that's true of both the MicroLogix 1100 and also the MicroLogix 1400 Series B. If your parts are produced faster than that, you might have to resort to reading each of the RTC elements and the free-running clock S:4 to build a unique identifier in the MES software.

 

[drbitboy]

Assuming 2s resolution is enough to be unique, from RTC, take .SEC + 60 * .MIN, that is a number in the range 0-3598, which requires 12 bits.

Take .HR + (.DAY) * 24, that is a number in the range 24-767, which requires 10 bits.

Take .MON + ((.YR - 2021) * 12), that is a number in the range 0-923 (max .YR value is 2097), which can be represented with 10 bits.

12+10+10 = 32 bits, which fits in a long; if you want the long to be positive, then 31 bits is good through 205-something, or make the low value .SEC/2 + 30*.MIN and use only 9-bits for that and get a system that works through 2097.

It's not pretty, but with a little bit of practice, the hex presentation of the long could be visually read and inverted back to RTC .attributes in your head, or a phone app or web page could be developed to do it.

 

[L33er]

Brute force approach:
CPW #RTC to #N interger file
AIC integer to String ST
ACN concatenate strings to have a unique ID string.

 

[JeremyM]

Another possibility that might emerge is the MES or another controller setting the DateTime on the ML1400 to maintain consistency. If this is done, there’s a *minimum* date the unit will accept without raising a major fault.

 

[Phrog30]

Why not use the MES side for the timestamp?

 

[JeremyM]

Why not use the MES side for the timestamp?

SOE can be time-sensitive.

 

[Phrog30]

SOE can be time-sensitive.

Maybe, also maybe not. I think it's worth exploring.

 

[drbitboy]

Brute force approach:
CPW #RTC to #N interger file
AIC integer to String ST
ACN concatenate strings to have a unique ID string.

Ooh, I like it, and only one rung (Vasily).

 

[JeremyM]

Maybe, also maybe not. I think it's worth exploring.

I have.

It’s a case-by-case thing, but you’re never going to beat controller/device level diagnostic response in any of them.

 

[Ken Roach]

I spent way more time than I should have last night trying to calculate a UNIX timestamp from the YYYY:MMD:HH:MM:SS values in an SLC-5/05 Real Time Clock.

It's hard to do with a 16-bit processor. My approach was to calculate the number of seconds for a given second in this calendar year, then adding that with byte-bashing logic to the UNIX epoch value for the start of each year between now and 2038.

I gave up before dawn because I'm only slightly more practical than I am stubborn.

A lot is going to depend on what the MES supports. I would recommend an incrementing event identifier, or a String with the RTC's values in ASCII, or the RTC values packed into an INT array.

 

[drbitboy]

I spent way more time ...

Heh, a fellow sufferer. Just so you know ...

$ date --date='1970-01-01 00:00:00 +00:00 +2147483647 seconds' --utc +%c
Tue Jan 19 03:14:07 2038


$ date --date='2038-01-19 03:14:07 +00:00' --utc +%s
2147483647

 

[L33er]

Ooh, I like it, and only one rung (Vasily).

View attachment 60354

Ooh I like it too, one rung to rule them all!
Can you double click the rung and copy & paste it here. Thanks.

 

[drbitboy]

Lbl 0 xic b3:0/0 bst ons b3:0/1 bst cpw #rtc:0.yr #n255:0 6 nxb clr n7:1 nxb mov 0 st254:0.len nxb aic 0 st254:1 bnd nxb bst mov n255:[n7:1] n7:0 nxb les n7:0 10 acn st254:0 st254:1 st254:0 nxb equ n7:1 5 bst and s:4 32767 n255:6 nxb mov n255:6 f8:0 nxb div f8:0 16.388 n255:6 nxb grt n255:6 999 bst add n7:0 1 n7:0 nxb sub n255:6 1000 n255:6 bnd bnd nxb bst aic n7:0 st254:2 nxb acn st254:0 st254:2 st254:0 bnd nxb equ n7:1 5 bst les n255:6 100 acn st254:0 st254:1 st254:0 nxb les n255:6 10 acn st254:0 st254:1 st254:0 nxb bst aic n255:6 st254:2 nxb acn st254:0 st254:2 st254:0 bnd bnd bnd nxb bst add n7:1 1 n7:1 nxb les n7:1 6 jmp 0 bnd nxb otu b3:0/0 bnd