SLC 5/04 and daylight savings time

[bernie_carlton]

And now that everyone has their DST changeover code all working the US Congress is working to change the start and stop dates to make it even longer. Oh boy, job security.

 

[gbradley]

I guess what I'm trying to figure out is...
Why does the counter behave differently when a one shot is used?

This type routine could be called at PLC startup and then once at the start of each hour after that (OSR of seconds = 0).

Also Bernie can you elaborate on how you could do this?

Thanks

 

[Ken Moore]

I pretty much just copied Kieth's logic, and adapted it for the U.S., he used a one shot, so I did too.
I think the one shot is required because the scan rate is faster than one second. At midnight on Saturday when all the registers equal zero, the counter done bit will be set, on the next ladder, the done bit resets the counter. So on the next scan all the reqisters still equal zero, since the counter has been reset, all the control bits have been reset, the counter will count. By adding the one shot you get rid of the "double count".
I never tried the 1=SUN, but don't see why it wouldn't work.

 

[theDave2]

When I need to reset counters / generate reports for each day, to tell when it's a new day I do just that. Compare the current D-O-M (day of month) register to my previously saved one. When they differ, then it's a new day. No need for compares of HH:MM:SS = 0, and it will always work.


As for DST, we ignore it. Either use ST or GMT +xx. Now if you need to reset counters 3 times a day due to shift change, that's a different story.

 

[gbradley]

I think the one shot is required because the scan rate is faster than one second.

Thanks that makes sense.


originally posted by theDave2

When they differ, then it's a new day.

That sounds like a better idea.
My dad always said that there was more than one way to skin a cat. (sorry Pierre)

Thanks Dave.
I like this because it doesn't rely on the PLC to be on at a particular time in order to Count.

 

[Jiri Toman]

I would not rely on a counter to maintain day of the week
memory. If you lose the program you will need to not only reset the
time of the day clock in the PLC but also this day counter.
That is not something you would want your customer to do
if you are an OEM.
Inevitably this will lead to a problem in the future.
Instead I suggest that you enter all daylight saving(s) times
for next 20 years in a data table and then use a routine that will
point to these dates and adjust the time accordingly.
This is the way I have always done it.
Once you have been around for a while and have bunch of programs out there that use the Daylight saving(s) time routine you don't need the hassle of reminding people to reset the day counter each time there was a program reload.

 

[gbradley]

I would not rely on a counter to maintain day of the week

Actually I'm not too woried about DST.
I just have a SLC 5/03 and I want to know what weekday it is, so I can display production counts.
It's not that big of a deal, but I am learning much info. :site:
Thanks.

 

[WireGuy1950]

Just a thought...

Since it looks like our government is going to totally revise the Daylight Saving Time start and stop dates why don't you set your plc clock to GMT time?

That way you never have to worry about when the time "changes", you just set the time you'd like to collect your data and your on your way.

Also, on the newer OS Versions of SLC (5/04 for sure), bit S:53 is the day of week I believe 0=Sunday.

Guy

 

[kamenges]

Originally posted by gbradley:

I tried it without the one shot, and it still works, but skips the 0. I don't completely understand why.

Ron B. probably has a real explanation for this but my quess is it's the way the SLC firmware handles the counter reset. If the count up input is asserted when the reset is asserted and released the counter probably 'sees' a leading edge on the trailing edge of the reset. Just a guess. But if I'm right you are probably looking at a firmware bug.

Keith

 

[Jiri Toman]

Also, on the newer OS Versions of SLC (5/04 for sure), bit S:53 is the day of week I believe 0=Sunday.

WireGuy,
I have a fairly new SLC 5/04, 1747-L542C, 32k Memory OS401 series C and I just ran a test.
S:53 is the day of the week just like you say and Sunday is 0.

Thanks a lot for this info!!!!

Forget about the counter.

 

[gbradley]

But since I only have a SLC 5/03 no S:53
I think theDave2's solution should work pretty good though.
I'll give it a shot.

 

[msinclair]

Ron B. probably has a real explanation for this but my quess is it's the way the SLC firmware handles the counter reset. If the count up input is asserted when the reset is asserted and released the counter probably 'sees' a leading edge on the trailing edge of the reset. Just a guess. But if I'm right you are probably looking at a firmware bug.

Keith

You are mostly right Keith. When you RESet the counter, you clear the .CU bit which is effectively the counter's one-shot bit. With that one-shot no longer asserted, the counter is free to count again . . .

You can test this by toggling the .CU bit while a counter rung is still true . . .

Marc

 

[gbradley]

You can test this by toggling the .CU bit while a counter rung is still true . . .

I was messing around with this and I think I understand.
I did a test with a Micrologix.
I branched a loop around to make the Counter rung always true.
I think what it does is Sail right past the 0 count when the CU bit is true.
It's all because of the RESet.

I don't need the one shot when I use the NEQ because that is only true for one scan anyhow.
Thanks again.

 

[msinclair]

I don't need the one shot when I use the NEQ because that is only true for one scan anyhow.
Thanks again.

Yes - I agree that your NEQ will effectively be a one-shot, so you should be OK.

The other way around this is not to use the RES command, but instead MOV a "0" into the counter .ACC register. Depending on what you are doing with the .DN bit, you might need to OTU that as well . . .

Marc

 

[PhilipW]

Absolute Daylight Saving Calculation

I've put a method for doing absolute Daylight Saving calculation and popped it into the download area. The key feature is that it will get the calculation right regardless of whether the CPU is running at the time of the transistion or not. The file is fully commented and has symbols; best viewed with the ladder viewer properties set to "Symbols Only".

I wrote it some time ago for a MicroLogix and I've just changed to the SLC Status file addresses for the RTC. Let me know if anyone spots any bugs. It's more involved than you might expect; comment welcome.