I recently conducted a program conversion from Logix 500 to Studio 5000. During operation, the machine relies on two ton instructions to stay synchronized, with timers T2 and T1 calculating the difference. In the Logix 500 program, the difference remains consistent, but in Studio 5000, it fluctuates. I utilized a divide instruction to adjust from 0.001 to 0.01. To test the program, I used SLC500 emulation with timers as sync sensors and Studio 5000 with a 1969-L33er and a Micrologix with a flash timing program as sensor inputs. Despite setting the same time parameters on both systems, I encountered discrepancies in the results. Have others experienced similar issues with hardware variations in program monitoring?
If you're encountering unclear results or unexpected outcomes, please provide the code for further analysis. Consider sharing an online screenshot displaying the code behaving inconsistently across various systems for better clarity.
In comparison to the old system, the timer accuracy readings (timer.acc) are more reliable and consistent. However, the new system shows that the timer.accuracy is not consistent, with readings ranging from 20 to 70. Typically, the old timers maintain a steady range of 63-64, while the new timers have a larger spread of readings. This inconsistency can impact machine performance.
The processors running the programming operate timers in varying ways, sparking numerous discussions on timer functionality and accuracy. Additionally, differences in hardware between 5000 and 500 platforms, scan times, I/O update cycles, and more contribute to distinct operational differences.
I may not completely grasp your actions, but it appears that the CompactLogix timers operate on a timebase of .001 seconds. The observed variation of 20 to 70 milliseconds in different applications seems acceptable for standard I/O operations. Each input module features a Requested Packet Interval (RPI) setting, determining the frequency of data exchange between the module and controller. A common RPI value is 20 milliseconds for basic I/O, resulting in a variation of 20 milliseconds for each trigger. The accuracy of timer Accumulated (ACC) values is influenced by the periodic task's scan rate, as the timer is only evaluated as frequently as the task runs. To monitor this, right-click on the task and choose the "monitor" option to view scan times and intervals. It is important to note that tighter ACC values than the task execution plus the I/O rate should not be expected.
If your Division steps involve complex calculations, it's possible that you could be experiencing errors related to rounding or truncation of values.
It sounds like you've done a thorough job with the conversion, but timing discrepancies can be really tricky, especially with different hardware setups. I've run into similar issues when moving between platforms, where even slight variations in how timers execute can cause synchronization problems. Have you checked the scan times on both systems? Sometimes the execution speed and timing resolutions can vary between Logix 500 and Studio 5000. It might also help to look at the overall task priority and ensure they match up between the two systems. Just a thought that could help narrow down the source of the fluctuations!
✅ 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: - The timer operation may differ due to differences in the software logic and programming environment between Logix 500 and Studio 5000.
Answer: - You can address fluctuations in timer differences by adjusting the divide instruction in Studio 5000 to match the settings used in Logix 500.
Answer: - Discrepancies in timer results between different hardware setups may be caused by variations in hardware performance, input sensors, and program monitoring methods.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.