What is the best way to sync the Gateway time to multiple PLC Clock times? I am currently using Allen Bradley’s Clock Update tool.
Don't. Use Logix' built in time synchronization (which is IEEE Precision Time Protocol, the core of Time-Sensitive Networking) and a grand master clock on the subnet. I recommend Time Machines' TM2000B with PTP set to multicast. It also offers NTP for less precise clients. Your Ignition gateway should point at it.
Your PLCs will synchronize to single-digit microseconds and will forevermore have perfect UTC time (GSV => Wallclock => CurrentValue). Your gateway will match your PLCs (and UTC) within a millisecond or two.
The precision time reference can also chain to other subnets through a ControlLogix backplane with two (or more) EN2T/EN3T modules.
4 Likes
Is there a way just to use Ignition to sync the PLC Clock times?
Not that I’m aware of.
The TM2000B is only $500. You set its time zone and PTP multicast. Hang its antenna in the ceiling. You click the time sync checkboxes in your PLCs. I can’t afford to research alternatives at that price and difficulty level (lack thereof).
1 Like
If you have any motion control anywhere in the subnet, or if you need the precision, then you definitely want to go with @pturmel’s approach.
However, if you just want the clocks to have close to the same time, then it is possible to read the time from a time server and then set the clock time with a SSV instruction. Then all you would need to do is point the gateway at the same time server.
Phil’s method is definitely more accurate, but if you’re not worried about milliseconds it will work.
If you're confident you can handle the (non-trivial) code for this (PLC and gateway), more power to you. My recommendation requires no code. And is a dirt simple deployment supported by the vendors involved. High precision is a happy side-effect.
Since AB provides an AOI for using sockets to read from an NTP or SNTP server ( KB-QA49644), I would say it's at least minimally supported. If you have the PLC hardware in place to handle it then it's workable.
1 Like
Uh huh. Latest family (5380) only, or a ControlLogix chassis with an otherwise useless 1756-EWEB. Way more than $500. Plus code to install. No thanks.
Edit: CompactLogix 5370 can do this too. (Not L7x, though.)
Starting with firmware V5.x 1756-EN2T supports sockets with V20 or higher.
But yeah if you're going to need to purchase hardware, then the TM2000B is better all around.
1 Like
We do this on most PLCs using the AOI_SNTP_QUERY AOI from Rockwell. Works very well to sync the PLC with a SNTP server.
1 Like
If your application only needs the time close–say a second or so off is no big deal–it’s pretty easy to write the time from Ignition to date and time DINTs (say 20210215 for date 2021-02-15 and 94805 for time 09:48:05) in the PLC and then use SSV instructions to set the PLC clock.
1 Like
I have tested a script that grabs the gateway time and writes to a tag string in one of the PLC’s, but I don’t know if it is a good Idea to write to the tags every second. I have 7 PLC’s to write to at the same time.
I do it every night at 4am, no need to waste resources updating every second as it’s not going to drift at all within a day or realistically even a month. Once a day isn’t going to hurt though
Yeah, I wouldn’t write every second. Once a night when there’s usually nothing happening has been our method too, except for some PLCs that have no idea about daylight savings time. This was once more fancy, but on conversion to Ignition we went with simple and just write the time on the hour every hour. None of these are applications where time is critical; we could be off by several seconds and no one would know the difference. If you need more accuracy, real time sync methods noted above would be more appropriate.
We use an AOI that requests the time from the plant Ignition server pushed to a DINT[7] array and SSV instruction at PLC power up. The server also pushes to the PLC at 1, 2, and 3 am daily to cover DST adjustments and any drift that may have occurred throughout the day.
It’s a cheap and easy hardware-less solution for all of our systems to have accurate HMI alarm timestamps, that don’t need finer than 1s accuracy.
Talk of DST, really, all times should be in UTC, including at the gateway so that DST doesn’t become an issue, for example if you’re using SQL Server as your database which igntion doesn’t support DST for. Saying that, I didn’t know this before, and we’re still doing this dialy udoate method setting DST time…
Well yeah, America should have been using the metric system a century ago too, but here we are 
The AOI we use pushes down the local and UTC time as well as the time zone and DST offsets, because plant ops and maintenance folks aren't often as zealous as programmers about locale agnosticism.
1 Like
I would still let the clients use their local times, but set everything at the server level to UTC (gateway, PLCs, etc.). I haven’t actually tested that though…
Sigh. If $500 is too much, I would still turn on Logix clock synchronization, and tweak the priority of the most modern of the PLCs to always win the grandmaster role. To adust that one, I would slowly ramp CSToffset until UTC was within your tolerance to an NTP server.
1 Like
Technically the US is a metric country. See the Metric Conversion Act from 1975
It declared the metric system "the preferred system of weights and measures for United States trade and commerce"
However the issue is that [it]
permitted the use of United States customary units in all activities
So you sign on to a metric based country, but you don't make the conversion mandatory. That's the worst of both worlds.
(Steps down from my soap box)
Amusing bit of trivia, I've driven down a country road in southern North Carolina that actually had the speed limit marked in km/h for a significant section.