PDA

View Full Version : SLC 5/04 and daylight savings time


Ken Moore
June 22nd, 2004, 10:45 AM
I am currently working on a project that totalizes raw material charges on a 24 hour basis, each morning at 8am the current totals, are copied to storage registers, and then the totals are reset(zeroed). This is using an existing 1747-L542C and a RIO Panel View 1400.

The Panel view will display the current totals, and the stored data from yesterday.

My question is if this needs to happen every day at 8am, how do I handle day light savings time? I know I can access the PLC and change the time twice a year, but was hoping someone had already had to deal with this, and could give me a jump start. I'm not sure it's possible, since the time shift doesn't happen on a specific date, it is usually the first or last Sunday of the month.

thanks,

Ken

Beryl
June 22nd, 2004, 10:52 AM
The easiest way I know of is to synce the date/time registers to a SCADA PC that is doing the logging. The PC's automatically change for daylight savings. Hopefully you have this type of setup or something simmilar.

Ken Moore
June 22nd, 2004, 12:47 PM
No...SCADA isn't an option.
Modification of an existing system, with limited budget.

Ken

grs
June 22nd, 2004, 01:42 PM
A quick google gave me the daylight savings time changes up until 2009. You could probably find more and then just set up a subroutine in the SLC to update the system clock of the panelview and SLC when that exact date/time happens.

keithb
June 23rd, 2004, 07:05 AM
Here's a routine I used some years ago which worked OK on a 503

C5:0 is the day of week counter as the 503 I used had no day of week register.

B11:6/2 is used to prevent the clock continuously retarding 1 hour at 02:00

Note: this routine assumes UK daylight saving time changes on the last Sunday in March and the last Sunday in October.

Ken Moore
June 23rd, 2004, 08:32 AM
kiethb
Your solution looks good, what are you using to index the day of the week counter? I assume you looking at the hours and indexing at zero.

Ken

bernie_carlton
June 23rd, 2004, 09:14 AM
Other complications - This solution requires that the PLC is on at least during the hour of 2AM on each change day. How about routines which will work with the assumption that the PLC is on at least once during the Standard Time and during the Daylight Saving Time periods? This type routine could be called at PLC startup and then once at the start of each hour after that (OSR of seconds = 0). The testing eats up a lot of PLC time and this would mimimize that.

gbradley
June 23rd, 2004, 09:16 AM
Keith Cool logic!
Please explain.


B11:6/2 is used to prevent the clock continuously retarding 1 hour at 02:00

I assume the One shot B11:6/0 does this for March?
Why doesn't the One shot B11:6/1 do this in October?


In October you change the clock 30 seconds later. Why??

Thank-you

Ken Moore
June 23rd, 2004, 10:10 AM
Kieth,
I tried your logic, works great, had to change it for the US, which changes the first Sunday in April vs last one in March.

gbradley,

You need the latch because at 0200 you retard the clock to 0100,
you do not want to retard again at the second occurance of 0200. If you didn't have the latch , you would be stuck in a do loop. At 02 retard to 01, the when you get to 02, retard to 01 again.


Ken

gbradley
June 23rd, 2004, 10:24 AM
Thanks Ken

How does that go?
DoH

I know that this is Sacrilegious, but I've never been a fan of the Simpsons.

Ken Moore
June 23rd, 2004, 10:40 AM
I've uploaded my version of Kieth's logic.

keithb
June 24th, 2004, 01:09 AM
gbradley

The 30 seconds later thing...
It was some years ago I wrote that logic, and I can't see any reason for it now.

gbradley
July 27th, 2005, 04:44 PM
Ken
I was looking at the Counter for the Day of the week.
I learned from you last week that Counters only count on false to true transitions.
So why is the One shot needed in your example?

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

http://www.plctalk.net/qanda/uploads/Counter.jpg

Also I see that you had 0=Monday 6 = Sunday.


If I change the preset to 8 and use 1= Monday 7= Sunday everything seems to be ok.
What do you think?

rsdoran
July 27th, 2005, 05:46 PM
The PLC will officially start at 00:00:00 but the transition from 24:59:59 will be hard to "see". I would assume the OSR is to prevent false triggering between "time counts"...ie if the second went to zero before the hour changed from 00 to 01. I think I ran into that once. The counter will count to Sun (7) and on next scan reset to zero so Mon will be 1. This gives you 7 counts to equal 7 days, 8 counts would add a day.

Greg Dake
July 27th, 2005, 07:15 PM
One thing I never knew, It's "Daylight Saving Time" not "Savings". I realized this last year when we were doing 21CFR11 chart recorder stuff....time updates are a critical part of it.


Greg

bernie_carlton
July 27th, 2005, 08:24 PM
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
July 27th, 2005, 09:40 PM
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
July 28th, 2005, 05:08 AM
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
July 28th, 2005, 07:46 AM
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
July 28th, 2005, 08:15 AM
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)

http://www.plctalk.net/qanda/uploads/DayOfWeek.jpg

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
July 28th, 2005, 10:43 AM
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
July 28th, 2005, 11:07 AM
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
July 28th, 2005, 12:15 PM
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
July 28th, 2005, 01:19 PM
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
July 28th, 2005, 02:00 PM
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
July 28th, 2005, 02:15 PM
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
July 28th, 2005, 02:19 PM
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
July 28th, 2005, 04:26 PM
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.

http://www.plctalk.net/qanda/uploads/Test.jpg

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

msinclair
July 29th, 2005, 09:55 AM
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
July 31st, 2005, 05:10 AM
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.

Ken Moore
July 31st, 2005, 05:57 AM
Tried to down load your file, but it is listed with a file size of zero. Downloaded it anyway, but there is nothing there.

PhilipW
July 31st, 2005, 02:31 PM
mmm, just tried again myself and it arrived fine.

gbradley
July 31st, 2005, 03:01 PM
It downloaded fine.

This code relies on Bit S:53 which is only available in higher end processors.

But aside from that I don't understand rung 000.
It seems like it will pulse once per scan, not once per second.
The N7:11 bit is 0 does it ever change?

PhilipW
July 31st, 2005, 03:07 PM
Well spotted. Actually I cut the file concerned from an STI file in a much larger project running at 200msec and the S_1SecSP = 5.

The 1 sec pulse was used elsewhere in the project, but not in this routine..maybe I should have cut it out.

Yes S:53 is only available in the later Series processors, but the RTC in the MicroLogix processors has a DOW value too.

Ken Moore
August 1st, 2005, 05:01 AM
Well....I still can't open it, says I don't have the proper access level. I'll try from another PC at work.