how often does the Logix Clock Update Tool signal get broadcast?

Hey guys,

Quick question about the Clock Update Tool; I've got it set up on my runtime server to sync once a day with my local PLCs, and that's working great. But, I have several remote sites connected by radio that the runtime server can't directly access because they're on a VLAN. Thus, I was planning to have the master radio polling PLC be the grandmaster, and enable the Clock Synchronization at the remote sites.

My concern is, I can't seem to find any info on how often the Clock Synchronization will occur. I need to be pretty careful with the amount of data I am sending across the radios, and I don't want to inadvertently crash connections with too much bandwidth.

I've checked the technical literature and can't find much to go by, so I thought I'd ask you guys to see if maybe I'm missing something in the settings; all I can find is info on setting Priority, which just seems like which PLC is a master and which are slaves. Any help is greatly appreciated, thanks!

Automatic synchronization can be scheduled at intervals as fast as every hour and as slow as one month

Click to expand...

Found in this presentation.

Your title is a bit confusing. I assume you are working with AB Contrologix. The clock update tool is not involved anymore once it set the time on your "Master Clock PLC".

I have some serious doubt on whether this going to work for you. Precision Time Protocol (PTP) is what Contrologix uses and you can look up the info on that. From my experience, it's syncing all the time. PTP even take account the lag between the network card and any PTP capable switch in between. If you don't require super high precision, I would just set a bit once a day to "zero" out the clock.

nhatsen said:

Found in this presentation.

Click to expand...

Yeah, so I've got that set up to sync my local PLC (the one that does all the polling to the remote sites). The remote sites are on a VLAN so the Clock Update Tool cannot interact with them directly.

What I'm trying to do now is get the remote sites to sync via Time Synchronization (which is accessed in Logix, under the I/O Config Properties of the controller).

harryting said:

Your title is a bit confusing. I assume you are working with AB Contrologix. The clock update tool is not involved anymore once it set the time on your "Master Clock PLC".

Click to expand...

Sorry if it's confusing...let me see if I can provide better info. First off I'm running Logix5000 with ControlLogix and CompactLogix PLCs.

I have a single PLC that controls all the polling of the remote sites, let's call it radio_master. radio_master is getting time sync info from Clock Update Tool, which is running on the local server. The remote sites are connected in their own VLAN over ethernet radios; they're on a VLAN because the radios need to be separated to avoid broadcast network traffic crashing them.

So right now, radio_master has an automatic time sync that happens once per day. What I am trying to figure out is how to get the remote sites on a time sync based on the time in radio_master. I've been reading about the Time Synchronization option, where a PLC can be set as a grandmaster clock and through CIP communications, can sync other clocks.

What I'd like to do is have radio_master as the grandmaster clock, and set up the remote sites to get periodic time updates from radio_master.

I have some serious doubt on whether this going to work for you. Precision Time Protocol (PTP) is what Contrologix uses and you can look up the info on that.

Click to expand...

OK thanks, that's something I haven't yet come across in my searches.

From my experience, it's syncing all the time. PTP even take account the lag between the network card and any PTP capable switch in between. If you don't require super high precision, I would just set a bit once a day to "zero" out the clock.

Click to expand...

Yeah I don't want it syncing all the time, just once a day or so.

The problem with setting a bit once a day is that there are about 15 remote sites, and each takes anywhere from one to ten seconds to poll; so even under best case scenarios, my various sites are going to be several seconds off every time. I was hoping the Time Synchronization could give an actual time stamp whenever it gets around to updating it, so there'd be no appreciable discrepancy.

You could get the time sync'd pretty close by making the hour, minute, and second part of the message data that you write to each "slave" PLC. Just be sure to update the values with actual clock numbers right before the MSG. This would probably make all your slaves about a second or two behind the master at the most if that is tolerable.

Well, ok. I don't think CIP time sync (or PTP) will work for you in any shape or form. PTP is rather complex but when it works as in a LAN, it's transparent. Most people use CIP not really to set the right time but to sync motion control application so having the "real" time isn't as important as to having the "same" time.

I'm ignorant to your application but I can't imaging a minute or so off would be that much an issue if you have 15 remote sites.

I work for utilities and we use GPS time sync because if we need to dig in issues, a few hertz off would be a big deal in troubleshooting electrical events that are miles apart but for other process related stuff, I have never seen anything that's super time accuracy critical.

harryting said:

Well, ok. I don't think CIP time sync (or PTP) will work for you in any shape or form. PTP is rather complex but when it works as in a LAN, it's transparent. Most people use CIP not really to set the right time but to sync motion control application so having the "real" time isn't as important as to having the "same" time.

Click to expand...

Ah ok, that makes sense.

I'm ignorant to your application but I can't imaging a minute or so off would be that much an issue if you have 15 remote sites.

Click to expand...

I work on water and wastewater plants, and the reason why having synced time is so important is because several processes run off of time-of-day control (start at a certain time, stop at a certain time). If the operators set something to turn on at say 11:30 and it doesn't turn on until 11:31 or 11:32 (and conversely, if something stops a few minutes late) that in theory is fine, but from their perspective they're going to think something is broken (why won't these pumps turn on when the HMI says the time, etc etc). Thus, it's actually important from the operator's perspective to have pretty close time even though from a purely analytical perspective, it doesn't matter at all.

If it's easier to simply pack and unpack the time, I can do that since I'm using MSG instructions and it would just be three more DINTs. I was hoping that the Time Synchronization function would work (why not use the tools you're given) but if that's not the best way to do it, I'll do DINTs in a MSG.

The only thing I'd ask at this point is, where do I write my time values in the remote PLCs? Would it be an SSV instruction, with WallClockTime as the class, and LocalDateTime as the attribute? But then I'd have to one-shot that, so the clock wouldn't constantly be overriden with whatever the last value I received...so maybe I need to unpack an always on clock_sync bit, use it to one shot an SSV, then reset the clock_sync bit until it comes in again?

defcon.klaxon said:

The only thing I'd ask at this point is, where do I write my time values in the remote PLCs? Would it be an SSV instruction, with WallClockTime as the class, and LocalDateTime as the attribute? But then I'd have to one-shot that, so the clock wouldn't constantly be overriden with whatever the last value I received...

Click to expand...

I believe all the above is correct.

so maybe I need to unpack an always on clock_sync bit, use it to one shot an SSV, then reset the clock_sync bit until it comes in again?

Click to expand...

I would just make the clock data part of your message. In your remote PLCs, look at a change of state of a heartbeat or the clock second and compare that with its clock second. If they don't match, then call a routine to update the remote clock to match the values received from the master.

Since the remote site will only receive the data from the master at relatively slow intervals, you don't want to constantly compare the two clock values, only at the instant you receive it.

Likewise in the master, since the messages go out periodically, you'll need to update the data within the message with fresh time data right before you send it.