Greetings to all! At my company, we utilize SLC500-based PLC machines to manufacture parts. Each time a part is produced, a counter increments and stores the count as an Integer. This allows us to view the count on the HMI and transmit it to Ignition Gateway for monitoring. The counts are consistently accurate to the actual production output. However, there is an issue with another tracking product we use. Instead of simply reading the Integer (the same one displayed on the HMI and Ignition), this product detects changes in the Integer and counts them. This unconventional method sometimes results in inaccurate counts, with occasional instances of unusually high numbers like 65537, 2592, or 2675, disrupting the tally. Despite my efforts to suggest reading the number directly instead of performing their own counting, the other team remains steadfast in their approach. I believe the issue lies on their end, but convincing them has proven challenging. Any insights on why these irregularities may be occurring from the PLC perspective? Your input is greatly appreciated. Thank you.
What is the speed at which the integer updates in the PLC, and what is the polling frequency for the ignition system or other methods used to retrieve data? Additionally, does the counter reset or roll over, and how is this accounted for in the system?
Hello robertmee, thank you for responding. The number updates approximately every 1.3 seconds (due to a press with a maximum speed of 45 spm). We monitor when the number decreases below its starting point. While I am unsure of their polling frequency, it appears to be capturing the data accurately. The team can only see the number, not the actual counter. At the start of each shift, the counter is reset to zero, which also resets the number. They have timestamps for the counts they receive, which do not coincide with the reset times. The counter has a maximum limit of 32767, but we are nowhere near that, usually reaching a maximum of 10000 in a shift, which is rare. I have attached a screenshot for reference – it should display all 1s. They have confirmed they are referencing N7:3, so I am unsure about the reference to c:c016.
With a value of 65537, the opposing party is utilizing 32-bit integers in their computations, whereas the PLC is working with 16-bit integers. The PLC is transferring the counter's .ACC value to N7:3. Is it possible that the other party's OPC is accessing both N7:3 and N7:4? If this is the case, does your team ever input data into N7:4?
The number 65537 exceeds the limit of a 16-bit number, with an unsigned int maxing out at 65535. This means that the maximum value for a signed integer, like the counter, is 32767. It appears that the system is actually retrieving 32 bits, specifically from N7:3 and possibly N7:4. Occasionally, both the first bit of N7:3 and N7:4 are high when data is retrieved. It is advisable to check if your program is interacting with N7:4 as well. Look into this issue promptly to ensure smooth operation.
As per the points raised by these individuals, it is important to note that 65537 is not a feasible value for a 16-bit Single Level Cell (SLC).
It sounds like your colleagues might be encountering a rollover error. PLC counters often have a maximum limit, typically 32,767 for signed integers. If the counter exceeds this upper limit, it rolls over and starts from its lowest limit, often interpreted as a negative number. The system detecting the change might interpret this rollover as a significant count jump, hence the high numbers. This is more a fault of the design approach rather than the PLC itself. A direct read approach, as you suggested, can eliminate this inconsistency. Maybe pointing out this possibility of rollover errors to them might help to drive your standpoint home.
I suspect this could be a case of "rollover" or "overflow", common phenomena in PLCs and other computer systems. When an Integer exceeds its maximum value (in this case, 32,767 for the SLC500), it rolls back to its minimum (-32,768) and continues incrementing from there. Now, if the tracking product is detecting changes in count rather than reading the actual values, it might be misinterpreting these roll over events as huge 'increases' in value, hence the unusually high numbers. If they remain adamant about their approach, I'd suggest changing the data type from Integer to Long - the higher maximum of Long should significantly reduce these rollovers.
It sounds like the other team's product might be suffering from an "overflow" or "underflow" error. The PLC machine's counter might be going past its highest or lowest possible number, causing it to loop back around in a process called "integer overflow" or "integer underflow". In computer programming, the number 65535 is the highest number that can be stored in a 16-bit unsigned integer, and 65537 would be the result of a 2 count overflow. It's likely the other team's product is miscounting when this overflow/underflow happens. I would recommend advising them to implement measures to take this into account and prevent miscounts. You might get more buy-in from them if you can bring evidence of this happening and explain it in terms they understand.
These unusually high numbers seem suspiciously close to specific powers of 2, don't they? It's possible that there's an issue with how the second product is interpreting binary or hexadecimal counts. Unless the count is reset frequently, the PLC's count value can reach high numbers and possibly overflow, as PLCs usually store integers as 16-bit signed integers. If the second solution is not handling the overflow correctly, it might account for these discrepancies. You might be able to convince the other team to see if they're handling 16-bit two's complement correctly in their software, and suggest they adjust accordingly if not. Hope this helps!
It sounds frustrating to deal with those erroneous counts, especially when the PLC and HMI are accurately reflecting production. One possibility for their discrepancies could be related to how the other tracking product is interpreting changes in the Integer value—it might be triggering on transient spikes or noise in the signal, especially during updates. If there's any polling or communication lag, a single count could be read multiple times or misinterpreted as a series of rapid changes. Maybe suggesting a clear definition of what “change” means to their system could help clarify the confusion. It might also be worth reviewing any filtering settings or debounce logic in their product that could be adjusted to mitigate such erratic readings. Good luck!
It sounds like you're dealing with a classic case of miscommunication between systems! The irregular counts you're seeing might stem from how the other product processes changes to the Integer—it's possible they’re picking up on rapid fluctuations or even noise that causes it to register multiple counts for a single event. I’d suggest a meeting where you can demonstrate the reliability of reading the Integer directly, maybe even running a side-by-side comparison over a period of time to showcase the discrepancies. If they can see the direct count consistently matching your production output, it might help sway them toward a more reliable method!
âś… 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 issue of inaccurate counts may arise from the tracking product's method of detecting changes in the Integer count rather than reading the count directly. This unconventional counting approach can lead to discrepancies and inaccuracies in the tally.
Answer: - Some examples of inaccurate counts mentioned in the discussion include unusually high numbers like 65537, 2592, or 2675, which disrupt the accurate tally of production output.
Answer: - To address the issue, it may be beneficial to communicate with the team responsible for the tracking product and suggest reading the Integer count directly instead of relying on detecting changes. Collaborative efforts to align counting methods can help ensure accurate tallying of production output.
Answer: - From the PLC perspective, the irregular count occurrences may be attributed to the discrepancy between directly reading the Integer count and detecting changes in the count. Understanding the differences in counting methods and their impact on tally accuracy can provide insights into resolving the issue.
Answer: - Convincing the other team to consider reading
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.