I collaborate closely with the Maintenance/Engineering department in a food and beverage production setting, focusing on PLCs and their functionalities. Currently, we are facing a perplexing issue that our Maintenance manager is unable to pinpoint. I am reaching out for insights and suggestions to resolve this matter. Here's some background information: Click PLCs are utilized across various packaging equipment to manage data processing. The data is transmitted to Streamsheets, where I am developing trending and reporting tools. Primarily, the data involves "TRUE/FALSE" statuses of equipment operation, with additional calculations for finished goods production rate (per hour) and total finished goods produced. Data is collected every 500ms, with values displayed in a table. The problem arises when, at irregular intervals (approximately every 10-30 seconds), the production rate and total produced values spike to 2x, 3x, or 4x their actual values before reverting to the correct numbers. These spikes always occur in multiples of the correct value and often in clusters. The most common deviations are 2x, followed by 4x. Despite various attempts to troubleshoot by adjusting data reporting timing, the errors are only seen in Streamsheets and not in the PLC programming software. We have observed that the discrepancies only affect the active production shift, while the values for the inactive shift remain unaffected. The issue persists without a clear explanation, and we welcome any suggestions on why these spikes occur and how to address them effectively. Your insights and advice would be greatly appreciated. Thank you. -BDKPLCASAP
Just experienced a rare 5x event after not seeing one all day.
It can be quite challenging to diagnose issues without the help of a troubleshooting tool. With the right program, you can easily identify and resolve any issues that may arise.
A possible issue could be that the data scraping process from your PLC may interrupt the calculation halfway through. The PLC always provides a consistent value because it completes the calculation before reporting it. To resolve this, consider performing the calculation in a different register and then transferring it to the register accessed by the reporting system. This adjustment could potentially improve outcomes. Try this method to see if it resolves the issue.
ASF suggested that the issue could be caused by the data scraping process getting interrupted mid-calculation. The PLC will always return the same value because it completes the calculation before reporting. To address this issue, try storing the calculation in a separate register before transferring it to the reporting register. Test this solution to see if it resolves the issue. Additionally, consider adjusting the reporting rate of the PLC to potentially reduce the likelihood of calculation errors. It is possible that slowing down the reporting rate could help mitigate the issue, but further testing is needed to confirm.
BDKPLCASAP mentioned that they will give it a shot and appreciate the suggestion. If we adjust the reporting rate of the PLC, would it affect the occurrence of this issue? Slowing down the reporting frequency could potentially reduce the chance of calculation errors. However, it is important to consider the synchronization of messages as they occur asynchronously to the PLC scan. This issue may arise when the PLC tag changes during the calculation, possibly due to handling a roll over or intermediate value. To address this, it is recommended to modify the PLC to provide a final value within a single computational block for better accuracy.
Hi BDKPLCASAP, this is an interesting problem! From your description, it seems like the issue might be syncing data between the PLCs and the Streamsheets. If you're only seeing those discrepancies on Streamsheets end, there might be times where it records two or more changes within the same 500ms interval. Could your system be misinterpreting this rapid-succession data and interpreting it as a 2x, 3x, or 4x value, given that these spikes seem to be multiples of the actual value? One suggested solution might be to increase the delay between data collections or add a data validation check to prevent multiple collections within the same interval. Also, consider validating the Streamsheets's data interpretation algorithm. I hope this helps you!
Looking at the scenario you've described, it seems like you've done a decent job trying to troubleshoot the issue. Based on my own experience with PLCs and data management systems, one suggestion would be to scrutinize the transmission rate from your PLC to the Streamsheets. Considering the data is collected every 500 ms, there might be some form of data overlap or duplication during transmission which is causing these spikes. I cannot say this is the exact cause without a thorough examination, but it's worth considering. Also, check for any patterns in terms of time, machinery, or any other variable the spikes might be tied to. Sometimes the answer lies in the smallest and seemingly unrelated details. Otherwise, it might be beneficial to seek professional consultation or to contact your PLC or Streamsheets manufacturer for further support.
Hi BDKPLCASAP, it seems like you're experiencing a fascinating issue. It sounds like a synchronization or timing issue, where the data might be read or updated faster than the usual 500ms from your PLCs. The fact that the error isn't appearing in the PLC software but in Streamsheets suggests that the problem might arise during the data transmission phase. You may want to check how Streamsheets is reading and interpreting the data. Could the data be overlapping or duplicating within that short window resulting in these multiplied values? Or maybe Streamsheets reads the data several times due to a glitch, giving the illusion of a higher production rate. If viable, you can try buffering the data first before passing it to Streamsheets to help smooth out these irregular spikes. I hope this helps!
It sounds like you’re dealing with a frustrating issue! Have you checked if the spikes correlate with any specific events on the production line, like equipment changes or shifts in production speed? It might also be worth looking into the timing adjustments in your Streamsheets setup—perhaps there's a delay or miscommunication happening when pulling data. Additionally, consider whether there's any possibility of duplicate data entries occurring during those spikes, especially if you're polling data at such a rapid rate. It might help to review the data transmission process in more detail. Keep us posted on what you find!
It sounds like a frustrating challenge you're facing! One possibility could be a timing issue in how data is being fetched or displayed in Streamsheets, especially if the spikes only happen during active production. It might be worth checking if the data collection intervals from the PLCs are overlapping or if there's any chance that multiple readings are being processed simultaneously, leading to those inflated numbers. You could also explore whether there’s any script or formula in Streamsheets that might inadvertently double-count values. Additionally, it might be helpful to isolate production shifts and see if there’s any shared resource (like a network delay or load) affecting only the active shift. Good luck troubleshooting this!
It sounds like you’re experiencing some frustrating data anomalies! Since the spikes only occur during an active production shift, it might be worth checking if there are overlapping data reads, perhaps from multiple PLCs or equipment being reported simultaneously. Additionally, look into any potential network latency or communication timing issues between the PLCs and Streamsheets that might be causing duplicate readings, especially since you’re gathering data so frequently. If those spikes align with specific operational patterns or events, it might also be beneficial to correlate them with specific machine states or operator actions. Hope you find a solution soon!
✅ 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 spikes occur at irregular intervals, approximately every 10-30 seconds, in multiples of the correct value and often in clusters. Despite troubleshooting efforts, the cause remains unidentified.
Answer: - The discrepancies only affect the active production shift, while the values for the inactive shift remain unaffected. Understanding the impact these spikes have on operations is crucial for mitigation strategies.
Answer: - Suggestions are welcomed on why these spikes occur and how to address them, particularly in the context of data reporting to Streamsheets. Insights and advice on effective solutions would be greatly beneficial.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.