Micrologix 100 Real time

[dcalderonv 0]

Hi, Quick question. Does the ML 1000 (1761-L16BWA) have any real time clock option, whether an external module or something. If it doesn´t, what would you suggest to capturee avents with time date? (using that PLC) Thanks a Lot!

[finfin 0]

I don't think it has an option for a real time clock. If you are going to have a PanelView on the system or connection to a bigger processor you can get the time that way.

[dcalderonv 0]

Thanks finfin, that's the answer I was afraid of. Im going to watch for another options. Best regards.

[Mickey 71]

Create you own clock. Use a timer to increment a counter or add instruction. One for Hours, one minutes, and one for seconds if needed. With a little math you can combined the three to give you Hours/minutes/seconds ( seconds would be +/- 10 sec.

[finfin 0]

I think you have to be careful doing this as there can be cumulative errors if you don't do it right. Someone else had a very good way of accounting for this... I can't remember just now how it goes, but I think a error is worse when you use a short timer and count the done bit occurrences. In other words use a long counter for hours. and a shorter timer for minutes and a shorter one for seconds.

[Mickey 71]

I completely agree, it will not be accurate. Maybe a upgrade to a ML1100. Edited 20 May 2008 by Mickey

[TConnolly 13]

Upgrade to the 1200, (or 1100). ML1200's are inexpensive and upgrading will likely cost less than other options.

[paulengr 44]

As to implementation, the trick to avoiding timer issues is to take scan time out of the equation. There are two approaches. Approach #1: Use an STI. Use the software interrupt. Since you know your code is going to execute every X milliseconds, put all your counters in the STI. This is the simplest approach. For instance, set the STI to scan a ladder every 10 milliseconds. Then you can run a counter (CTU) with a preset of 100. When the counter DN bit triggers, RESet the counter and CTU your seconds counter, set with a preset of 60. When the DN bit triggers, RESet the seconds counter and increment the minutes counter, etc., etc. Approach #2: Similar to approach #1 except that it runs asynchronously. Set up a timer. I forgot the minimum granularity on a ML1000 but let's say that it's 0.001 seconds. So instead of setting the timer preset to 1000 and using this to increment the seconds counter (the obvious approach), set it to 1000 plus the absolute maximum scan time. Usually I don't calculate it and simply double the number. So set the PRESET to 2000. Now in your code immediately after the RTO instruction, check if the timer ACCumulator is greater than or equal to 1000 with a GRT instruction. If so, then SUBtract 1000 from the timer accumulator and run your seconds counter (CTU). Beyond this point, follow approach #1. This solves the scan time problem because the PLC internally does keep track of the scan time in order to properly execute the timer instruction. You can also use a seconds timer directly. Just make sure to set it to say 65 seconds and subtract 60 off whenever it gets to 60 seconds. The PLC will keep track of "fractional" seconds for you. The downside of either of these is that if you kill power to the PLC, guess what happens? The timer system freezes. In reality, the clocks in most PLC's can drift by as much as a second per DAY. So there is noticeable and significant drift. PC clocks on the other hand usually only drift by that much per week or month. It has to do with the design (more accurate often means more fragile). There are two ways to fix this. You can simply forcibly reset your clocks via a PC or any other device on a periodic basis. This is especially important and easy if you have an HMI. More sophisticated approaches include slewing (drifting a clock towards known or agreed upon "true" time), connecting GPS receivers, and running distributed clocks (everyone exchanges messages about what time it is and taking a consensus opinion with a robust statistic such as a median). These much more complicated methods are actually how it is done in precision time keeping facilities. If you start googling for clock synchronization, you are bound to find technical papers on the subject and how to do it. In my own plant we rarely shut down the PLC's. I have only one Micrologix and the clock doesn't matter on it. We don't run 24/7 so daylight savings time is a non-issue. And we have a large HMI system so every 10 minutes it goes through with the "stupid" approach and injects the raw known good time (updated via (S)NTP coordinated with the national observatory as the tier 1 provider) into the PLC without any slewing or accounting for network delays. Alarms and accounting (piece count) are done at the HMI level. All the PLC does is provide the events themselves. There are several places where I have to do some timer off tricks and such to delay events long enough for capturing but that's just about the only problem with this setup.