Synchronize Network PLC/SLC system clocks

We have a DH+ network of PLC5s, SLC500s, and a Logix5555. Want to use the Logix as a master time source. Also need to use a day increment counter wherein Monday is day 1, Tues. day 2, etc. and roll over again to 1 following Sunday (day7). The clock and day increment are used in each location for production shift tallies and we need them all to be on the same day and time... thus, the synchronized system clocks.

We have been allowing each PLC/SLC to manage their own clock/date. This is tedious maintenance, so we came up with a way to message the integers from the Logix5555 GSV instruction (and subsequent arithmetic) to the PLCs in the network so that they all are updated at least once per day. This has proven to not be dependable. Over time, one or more of the PLCs ends up with the wrong day increment. The time S:37-42 sync works very well.

Anyone have a suggestion on how to make this accurate? Your ideas are appreciated. I can provide more info if so needed.

My suggestion is don,t do the time synch at midnight or at minutes =00 do it at any other minute of the hour and the days should also stay synched

Good morning:
Thanks for the reply. Actually, our "day" runs from 06:00am to 05:59am. So..our clock syncs are at O5:55am. The reason, all production following midnight needs to tally on the preceding day.
For some reason, the calcs don't happen consistently for the day increment. I have check'd the tag array and the integers are correct. So it must be something to do with the comms or message config.??

Marshall, as far as I understanding, now you just send the time information, and let each PLC to calculate the date by themself.

If I am right, why do you send the day information in the message, so as long as the master(CLX)'s data is correct, the others should be OK.

Why not just do the day's in one PLC and message it to the others, you are already messaging the time?

If you are tracking the user date and time scheme you used in your first post, I have some questions.

Is there logic in each PLC to update the shift info, or are you just changing all the times?

Can you send just "hours, minutes, seconds" to each PLC's internal clock, and let your internal time stamp program just merrily run its own way?

I think that this may be an "overthought" solution to network clocking. How many PLCs are involved?

I have done something like this on DH+ networks using DDE through excel. I had only PLC5 and SLC processors.

On my spreadsheet, the times from all of the machines were displayed. I added a button to trigger a VBA script that would open each channel and write the already parsed PC time to the appropriate S registers. I found that immediately after "synch-ing" the last one updated would be "behind" by several seconds, which was not a problem for me, but just for chits and giggles, I modified the script to compensate for this, and was able to get them all (about 30 nodes on three networks) within 1 second after some trial and error.

After a week or so without being re-sync'd, I found that all of the PLC5 clocks were less accurate than the SLC clocks, and they would be off by up to 30 seconds.

Just my experiences, not knowing what your error tolerances will be. In my case, if they were within a couple of minutes it was good enough for us. We were using each machine to calculate its production data and would get inaccurate numbers when (for example) a machine was powered down for a long duration or had its program reloaded without setting the time. It was not mission critical, but more of a production aid to scheduling.

Toward the end, I set up the script in excel to set all of the clocks when any of them was off by more than 1 minute. I would leave it running on my desptop during weekends and through daylight savings.

I believe rockwell has a utility for jsut this type of thing too.

Instead of writing the time from the CLX to the other PLCs, have the other PLCs read the time from the CLX. Write messages require more overhead and take more time than read messages. Depending on how often you record the data, don't use the local time registers at all, always read the most current info from the CLX.

Thanks, each of you, for the very good input.

Alaric: You have a good point. Since we are only updating the time/date/day increment once per 24 hour period, it may not be such an overhead (if my thinking is correct here). I really haven't found the anomaly that causes the day increment to fail. The actual systems clocks updates have been working very well for a few months, and all within 25 seconds of the master (to partially answer OkiePC's reply) which is fine. Of course, there is more latency to those PLCs near the end of the blue hose.

We really have quite a loose tolerance in that we only need the clocks to re-sync once a day and since the message writes once a day (@ 05:50am), I am sure the scan times and updates are received without problem. Currently I am using the MSG.dn bit of say MSG1 to trigger the next message and so on. The group of rungs begin with a comparator checking the current day increment with the updated increment integer. The group ends with an update of the current value. I wonder if the MSG.dn initiate next MSG is happening to quickly and with the added calc for the changeover from Sunday (day7) to Monday (day1) the update is being dropped on one or more of the end of the hose PLCs?

OkiePC: Interesting idea regarding MS Excel. We actually are using Excel extensively in DDE to look at most all of our plant locations data in one form or another. We are also using it to poke integer values to production controllers.

tomalbright: As far as writing (or receiving) the system clock S: files from the ControLogix5555 to each PLC/SLC, and then allowing them to compute their own day increment, I tried that. Same issue. There are 10 processors involved. Our production reports (numbers) are written to a buffer a few minutes after the end of a shift, and those buffers are written then to an archive buffer just before the beginning of the next shift. The reason for the delay in writing the archive is in case we happen to run longer on a particular shift.
The real herring bone in this is due to the fact that our Sunday shifts start/stop at different times from Monday - Saturday... hence, the need for system clock syncs.

That being said, I do appreciate everyone's help. I will keep plugging away at this and possibly something unusual will pop up.

Thanks to everyone.