Within a 5380 series controller, I have implemented logic to track the duration of events by capturing the start and end times and calculating the elapsed time. I use a GSV instruction triggered by a one-shot to retrieve the date and time from the PLC's Real-Time Clock (RTC). By dividing the timer's accumulated value by 1000, I convert the duration into seconds for display. However, I am facing an issue where the division by 1000 rounds down the value, for example, 22999 rounds down to 22 when using a DINT data type as the destination for the DIV instruction. My concern lies with the accuracy of the PLC's RTC and the GSV instruction. Will the seconds value read from the RTC be rounded as well? I suspect the seconds value is derived from the microseconds value of the RTC, causing discrepancies in the calculated elapsed time compared to the timer's .ACC value. Despite GSV occasionally displaying the correct elapsed time, there are instances where a one-second discrepancy occurs, aligning with the rounding of the timer's .ACC DINT value.
When performing integer division in ControlLogix, keep in mind that it truncates rather than rounding down. This means that the remainder is not included in the result, only the quotient. If you need to find the remainder, you can use the Modulo (MOD) command or include a REAL tag in your arguments. For those using a 5380 series controller, the firmware should support math operations on LINT datatypes. This allows you to calculate elapsed microseconds by getting the CurrentValue of WallClockTime at the start and end of an event and subtracting the end value from the start value. No need for an RTO in this scenario. The Seconds value of Wall Clock Time is not rounded; it increases by 1 when the Microseconds value increases by 1,000,000.
Thank you for your feedback, Ken. I considered comparing the two GSV instructions as you suggested, but there may be interruptions during the process. Simply calculating the start and finish times and performing math on them could lead to inaccuracies due to potential pauses in the process. I want to avoid any issues that may arise from rounding values, such as when dividing 22999 by 1000 resulting in 22 with a remainder of 999 potentially being rounded up to 23. It is crucial that the WallClockTimes accurately depict the start and finish times of the process in relation to the RTO. While testing the code, I have observed that the WallClockTimes are precise, but the calculated elapsed time has occasionally been off by a second. Knowing that the seconds value will only increment when the microseconds value reaches 1,000,000 provides clarity and reassurance in the accuracy of the calculations.
From what I understand about PLC Real-Time Clock (RTC) functionality and the GSV instruction, the seconds value should automatically be rounded to the nearest whole number. Your suspicion about the seconds value being derived from microseconds is correct, and this indeed could lead to discrepancies. Possible workarounds to this issue include using a floating-point data type for the division operation to accommodate decimals, or implementing your own method to handle rounding. Remember, the goal is to ensure the representation of the .ACC value aligns more accurately with the exact elapsed time.
The issue you're encountering seems rooted in the filtering of integer division rather than a discrepancy with the PLC's RTC or the GSV instruction. When dealing with DINT data type and DIV instruction, the resulting output is always an integer, hence the rounding down you observe. A workaround for this problem could involve transforming your data to a real or floating-point value before performing the division to retain the decimal representation and achieve higher accuracy. Regarding your concern about the GSV command, it fetches the value precisely as given by the clock, without any rounding off. The discrepancy you observe must be due to the division rounding off.
With PLCs, numerical rounding is definitely a challenge. Your observation about the PLC's RTC rounding could well be accurate. If you're looking to enhance your accuracy, consider storing your times as REAL data type rather than DINT. This change will accommodate the fraction part of the second. Despite this, remember that even RTCs aren't 100% accurate and some discrepancy may still prevail due to accumulated clock drift. It's hard to be precise with timings down to the exact millisecond in PLCs. This drift might correlate with the inconsistent results you're seeing.
✅ 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: Answer: One approach could be to use a different data type or method for the division operation to avoid rounding down the value.
Answer: Answer: The accuracy of the RTC depends on the specific model and manufacturer of the PLC. It is advisable to consult the PLC's documentation for information on the RTC's accuracy specifications.
Answer: Answer: It is possible that discrepancies in elapsed time calculations could arise from differences in the resolution or precision of the timer's accumulated value and the RTC's time representation. Further investigation into the timing mechanisms and data handling may be needed to address this issue.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.