Greetings, We have a client who needs to synchronize the time on approximately 10 PLCs, primarily 1756-L82 models running firmware version 32.014. The client's central time server is capable of broadcasting time using NTP (Network Time Protocol) and possibly PTP. However, there are concerns about PTP causing excessive network traffic due to frequent time updates. Although the 1756-TIME module is an option, the client prefers to communicate directly with the time server without purchasing additional equipment. Is it feasible for the time server to respond to PTP time requests and sync the PLCs accordingly? One potential solution is to have a master PLC query the time server and then instruct the other PLCs to sync their time accordingly. If using PTP, is it possible to schedule time synchronization instead of constant syncing? For example, initiating a time sync only at specific times (e.g., 8 am) to minimize network traffic. Alternatively, would it be more practical to invest in the 1756-TIME module despite its cost? Despite its high price tag, the module simplifies the time synchronization process. Thank you for your input. Best regards, Slick
PTP traffic is not a major traffic concern, as participating nodes regularly update to minimize drift and skew. Using periodic messaging would go against the protocol's purpose of ensuring accurate timing synchronization. To prioritize a specific grandmaster, its Priority 1 should be set lower than others, with Priority 2 used as a tie-breaker if needed. NTP can be implemented through controllers' Socket CIP object, with available sample code for assistance.
Can these controllers support CIP Motion applications over Ethernet? How important is synchronization between them? Is it possible for the customer to use the Logix 5000 Clock Sync Tool on a server to regularly update the Wall Clock Time?
What is the purpose of aligning the times across various controllers? I typically steer clear of manual or external time synchronization in systems utilizing CIP motion over Ethernet. Nevertheless, having a real-time clock is advantageous for displaying and alarming functions. Thus, I opt to utilize my SCADA system to input the current date/time into designated tags on each PLC. This enables the HMI (PanelView Plus 6/7) to periodically synchronize with these tags for accurate clock updates.
Thank you all for the helpful information. The goal is to achieve precise synchronization among all target PLCs in the water and wastewater process, with minimal skew. While exact synchronization may not be necessary in this case, it is still important to coordinate them within a few seconds of each other. Based on the feedback received, I am inclined towards using NTP in conjunction with a socket CIP object, as suggested by one commenter. I was under the impression that this synchronization could only be achieved with the 1756-TIME module, but I will further investigate this on my end. Utilizing their existing NTP server for the synchronization process would be the ideal solution. In response to Ken's suggestion, the Clock Sync tool may be suitable if it can sync with the current NTP server. Thank you all once again for your input. We will be in touch soon.
In response to Ken's suggestion, I believe that the Clock Sync Tool could be effective in synchronizing with an NTP server. However, it is important to note that the Clock Sync Tool is no longer supported. While it may still be possible to download and install it, there will be no technical support available. The reason for the lack of support is due to potential security risks associated with its operation. In the past, we utilized the Clock Sync Tool on our Dev station with scheduled syncs in place. It was a reliable tool for maintaining time synchronization for alarming and logging purposes. However, after transitioning our Dev machine to a Windows 10 environment, we experienced issues with the tool's functionality. Unfortunately, Rockwell no longer provides support for this tool. As a result, we now manually sync our systems twice a year during DST changes or as needed by operators. I have limited experience with alternative solutions for time synchronization, but I encourage you to continue researching. In my experience, my plant did not prioritize investing in time synchronization solutions. Best of luck in finding a suitable option for your needs.
Hi Slick, I think your idea of having a master PLC is a great workaround. It could regularly synchronize with the NTP server and then distribute the time to the other PLCs; this way, you'd only be adding minimal traffic over your network. As for scheduling the synchronization, most PLCs allow you to program the frequency of such updates, so I believe it's feasible to set it at specific times like you proposed, again minimizing the traffic. The 1756-TIME module would be a simpler solution, but if cost is an issue, I believe the master PLC strategy could be just as effective with a bit more programming work.
Hi Slick, You're right to be concerned about network traffic - excessive PTP requests can certainly bog down a system. One potential workaround may be to use SNTP (Simple Network Time Protocol) for time synchronization with the PLCs, which is typically less network-intensive. If you want to use PTP, scheduling time syncs is another viable option, although you'd have to consider if the potential time drift between syncs is acceptable for your client's operations. As for the 1756-TIME module, while it does simplify the process, it's a pretty expensive solution. If budget is a major concern, I'd explore the above alternatives and see if they could work for your scenario. Hope this helps!
Hi Slick, If your client's central time server supports NTP, you can use native Rockwell tools for syncing time to your PLCs. Using RSLogix5000, you can set your PLC to act as an SNTP client. Depending on your network conditions, you may need to adjust your Update Rate for stable operation. Also, keep in mind this works on a request basis, meaning your PLC will ask the time server for updates periodically. Preferably, scheduling syncs could be a good approach for using PTP to keep the PLCs in sync while preventing congesting the network. However, that depends on the PLC's ability to stick to a schedule and the scheduling ability of your proposed time server. The 1756-TIME module provides the highest level of precision, but it's worth evaluating whether your application requires such precision. Bottom line, the choice between PTP, NTP, and a physical module like 1756-TIME hinges heavily on your specific network conditions, overall budget, and application needs.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - Yes, it is feasible for a time server capable of broadcasting time using PTP to respond to time requests and sync multiple PLCs without requiring additional equipment.
Answer: - Yes, it is possible to schedule time synchronization with PTP, allowing for specific times to initiate time syncs (e.g., 8 am) to reduce network traffic from constant syncing.
Answer: - Yes, investing in the 1756-TIME module would simplify the time synchronization process, even though it comes with a higher price tag.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.