I am currently working on a project that involves loading pallets into 10 test bays and unloading them once testing is complete. To keep track of completed tests, I am utilizing an array and an FFL command to organize the unloading process in a FIFO manner. However, I am facing an issue where the FFL command occasionally fails to load the number of a completed test bay. Approximately 6 out of 100 attempts result in this error. Each test bay is equipped with a proximity sensor that detects the presence of a pallet. Once testing is finished, the operator presses a button at the test bay, signaling that the test is complete. When the button is pressed and the sensor senses a pallet, a test complete tag is activated for that specific test bay. This tagged information is then utilized to move the test bay number into a tag, which serves as the input for the FFL command to load into the array. Despite the successful tagging of test completion, there seems to be a random issue causing the process to malfunction at times. For those interested in examining the routine and troubleshooting the issue, the problematic section can be found at rung 10. Feel free to take a look at the attached routine for further analysis.
It may seem unlikely, but if multiple TESTBAYn_PB1 buttons are pressed simultaneously during the same scan cycle while their corresponding TESTn_PROX sensors are active, the last bay number value written to TESTBAY_COMPLETE_FIFO_SOURCE will overwrite previous values, causing them to be lost. This can lead to the symptoms you are experiencing. To improve clarity, consider implementing the canonical Start/Stop Circuit pattern. For example, include an XIC TESTBAY1_COMPLETE instruction around the XIC TEST1_PB1 instruction on Rung 10, change the output to OTE TESTBAY1_COMPLETE, and remove Rung 11. This will help streamline the PB+PROX-driven logic.
In a rare scenario, if multiple TESTBAYn_PB1's are activated simultaneously during a scan cycle with their corresponding TESTn_PROX's at 1, the latest bay number entered into TESTBAY_COMPLETE_FIFO_SOURCE will overwrite previous entries, resulting in data loss and the issue you are experiencing. To prevent this, consider using 10 rungs similar to the example below instead of Rungs 10-52 with sequential numbers replacing 'then' with 1 through 10. This approach will ensure that all 10 bays can be completed within a single scan cycle without encountering the mentioned problem. Additionally, a query arises regarding the whereabouts of the FFU instructions.
I believe that multiple push buttons being pressed simultaneously during the same scan cycle is unlikely. These buttons are operated by a single person and are located a few feet apart. Thank you for the suggestion regarding logic implementation; I will test it out to see if it resolves the issue. The FFU is invoked in a separate subroutine. Is it possible for the FFU to be triggered simultaneously with the FFL, causing the FFL to not run properly?
Looking at your description, it seems like you've got a complex system in place, but I'm wondering a bit about your proximity sensors. While they are effectively detecting the presence of a pallet, it's plausible that there could be some latency or intermittent issues that are causing the malfunction you observe. Sometimes, accuracy of sensors might fluctify due to external factors. Also, have you considered the possibility of button debouncing? There might be noise in the signal when the operator presses the button to mark the end of the test, causing the information flow to get disrupted occasionally. It might be worth using some additional logic to eliminate these types of issues. This could also account for the seemingly random nature of the problem.
Looking at your provided circumstance, it seems to me like the issue might be stemming from a timing problem. Perhaps the operator button press and the sensor's detection of a pallet are not in perfect synchronization, leading to occasional slips in the loading of the test bay number. Alternatively, it could be a tag updating problem, where the completed test tag gets updated before the FFL command loads the test bay number into the array. You might want to try to place a delay between the operator's button press and the loading process, or possibly modify the sequence in which your tags update and how that aligns with your FFL command execution. Lastly, it might be worth doing a thorough check on your sensors and buttons to ensure they're working consistently, as hardware issues can sometimes creep up in unexpected ways.
From your description, it sounds like there's a robust system in place, however, the inconsistencies in the FFL command reading can be frustrating. Have you taken a look at the timing of your FFL command? As it is multithreaded, there could possibly be an issue of overlapping instances causing it to miss some inputs intermittently, especially in high-speed operations. Try to narrow down if the problem is systematic or completely random - this could guide you to where the issue stems from. It could be worthwhile to employ a form of semaphore or interlocking logic to ensure that your FFL command is only processing one signal at a time. I'll take a close look at rung 10 in your attached routine and let you know if I spot anything that might contribute to the issue at hand.
✅ 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: The FFL command is used to organize the unloading process of completed tests in a FIFO (first in, first out) manner.
Answer: Answer: Test completions are tracked using a proximity sensor that detects the presence of a pallet and a button pressed by the operator to signal the completion of a test at a specific test bay.
Answer: Answer: The issue causing the FFL command to fail occasionally is related to a random malfunction in the process, which occurs approximately 6 out of 100 attempts. The problematic section can be found at rung 10 for further analysis.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.