Control/CompactLogix internal clock reset instruction

Hello there,

I'm working on adding a historian, of sorts, to a PLC project where I'd like the data that is being stored to be reset on a certain date and time.

Something that came to mind though is that the machine/PLC could be off at the time that I'd like to reset the data, so my concern is that when the PLC is powered back up, it won't execute the logic to reset the data as the date/time will not match what I set up for it to do that.

For instance, if I want the data to reset on 12/31 at 23:59:00, the machine could be shut down for the holiday. When it's started back up on say 1/2 at 07:00:00, the PLC doesn't know that it went past the date I wanted it to reset and now I have to wait for 360-odd days for that to happen again!

Anyone every do something like that or have a suggestion of how to handle it?

I work primarily with ControlLogix and CompactLogix processors.

Thanks in advance for your ideas!

When the system shuts down, create a task to save the real time clock. Upon startup, compare the shut down time and the current time to determine if a reset is required.

Regards,

Thanks, Garry... I'll check into that.

I've even got some processors I can try that out on. I can try to reset it like in an hour, then try overnight, then a few days to see if it sticks.

Have you got some sample code on how to process a shutdown task, however?

I wouldn't worry about a shutdown task so much. You'd do it in a startup task. All CLX memory is retentive, so if you've got your date/time in a tag somewhere, when the PLC starts up, the date/time in that tag will be the last updated timestamp recorded before the system shut down. It won't "update" to current date/time until the PLC starts executing code again to update it.

So, on first scan, log the "current" value of the date/time tag (which will be the shutdown time), then update the date/time tag, compare the updated value to your previous value, and do whatever you need to do with what you find out!

Hey ASF,

I'm coming back around to this. Your explanation sounds simple enough but I'm not clear on how to capture the last updated time before the processor was turned off/Program Mode.

Can you expand on what you had in mind on that?

I think your best solution is to monitor the Month of Year and not use hours and minutes. Instead of doing reset on the last day of the year at the last minute of the year why not use the 1st month of the year. Use the Month to Latch a January Bit. Use the January Latch Bit to One Shot your Reset. Then Unlatch your January Bit in February. This way your January Latch Bit will not be true again until the following year. Also the one shot will not fire again in the month of January even if power cycled.

Come to think of it you don't even need to latch just compare Month = 1 and one shot reset.

Good point, cwal,

In the scenario I gave, checking the month would be more appropriate.

I'm also developing a historian to record events each day of the month, but I was thinking of writing an array that will just match up the Month/Day to the PLC clock to know where to write the events.

I think where I'm having trouble is how to capture and store any of the WallClock data when the PLC is powered down. I can get it when it powers up, obviously, but I am not sure how to grab it just before the PLC is off to use to compare it against its boot-up time.

Any suggestions?

Well, like ASF said, it would be easier to do as part of an init routine since the PLC doesn't know when it loses power.

So, the scenario would be like so -

You have a tag/array/whatever that houses the current time/date and updates on some frequency, but does NOT update while S:FS is true.
When the PLC powers down or is put in program, this tag will stop updating.
When the PLC powers up or is put back into run, you could use the S:FS bit to run a mov/cop/whatever to copy from the current time/date tag(which isn't updating because S:FS is true for one scan) into a placeholder tag/array/whatever.
Then after the current date/time updates for the first time, do a compare between it and the placeholder tag to see if you need to do whatever action.

There's also a power up handler you can use, but most PLCs have some form of S:FS(on first scan) bit, so this is fairly generic that way.

Ah. Yes, I did observe that, as far as the time/date "stopping" when it went into program mode. I just wasn't sure if there was an actual instruction that saved the time-date when the PLC was being powered down.

I can use the S:FS and some other logic, just seems like it could potentially introduce some error because the PLC could be on for days or weeks, so the Time/Date could be a long ways away from when power is cycled to the PLC again.

I suppose it's an either/or situation in that regard.

Sure, but assuming you aren't running your GSV against the wallclock instantly(maybe a timer to wait 2 secs on power up), you should still have plenty of time to do your MOV/Compare.

Now, Are you going to timesync the PLC from an external system? How would you handle someone reloading the PLC program or monkeying w/ the time?

That's one thing I'd need to adjust, I have the GSV WallClock executing on an S:FS, so it's wiping out my last store data. I hadn't done a lot of refining with that as of yet, but it's simple enough.

The way we build our machines is that we have a screen where the user can enter in the current time, then goes through some logic to SSV the PLC time, and also synch the HMI to the PLC clock. So, it's not picking up on an external reference.

If the PLC were to get reloaded or something and the clock changes, then someone would have to go back into said screen and resync the clock. You can only idiot-proof things so far, right?

Heh, true, the universe will simply provide a better idiot.

Does it even need any fancy start up stuff?
Have a date for event.
If current date is later then
Do task
Add interval to event date for next event

If there is a discontinuity in the date the event will fire multiple times until the new event date is in the future.

There are datetime add ins available for comparison and other operations or you can roll your own using a dint and and cmp instruction (I am in favour of the metric 30 day month)