Developing a tester with a Micro850 in Connected Components Workbench involves scanning a barcode during each test cycle to determine the tests to run. To check the barcode buffer's content, an ACB block is utilized to count the characters and verify if it meets the required test length. The ARD block reads the buffer's content and passes this information to the program to identify the necessary tests. In case of incorrect barcode length, an ACL block clears the buffer to prepare for the next cycle. While my approach aligns with standard procedures, I encountered issues with buffer clearance when the barcode length is incorrect. The buffer clears effectively with a zero or correct length for the ARD, but fails to clear with an incorrect length until the PLC is power cycled. A simplified testing setup focuses on counting, reading, and clearing the buffer. During testing, toggling the ScanBarcode bit is done manually, with the correct barcode length set at 36 characters. Challenges arise when the barcode length exceeds 82, causing the ARD block to malfunction and preventing the ACL block from clearing the buffer. Seeking assistance to better understand block functionality, as existing documentation is limited.
Ladder logic connections were not established as intended, possibly due to a reluctance to attach the required links. Check out the following images for a better understanding: https://pasteboard.co/sAuhrwPLxJuD.png, https://pasteboard.co/6657pVKPffrx.png.
I am not familiar with these instructions, but it seems like there may be a timing issue. According to the help documentation, the Q bit is updated asynchronously from the program scan. The BufferCounted in Rung 2 is only true for one scan, which means that CounterReset will also only be true for one scan (in the same scan as BufferCounted). If ACB_1.Q has not become true yet due to an error, you may not be able to reset the block until Q is true. To ensure that the ACB_1 block is ready before considering it to have been counted, you could try removing the BufferCounted coil from Rung 2 and creating a separate rung with XIC(ACB_1.Q) OTE(BufferCounted). This will help in ensuring that the block is ready before proceeding further.
PLC programming revolves around the concept of time and the scan cycle acts as the system's clock. As @Incandenza pointed out, the buffered serial communications operate independently of the scan cycle, emphasizing the significance of when bits change state over how they change state. Effectively managing this process is a complex task. It is worth noting that the ACB instruction is activated by a rising edge, making the -|P|- edge-detection instruction on its feed rung potentially unnecessary. In conclusion, understanding and efficiently handling these aspects in PLC programming is crucial.
Upon closer examination, it became apparent that the ACB and ABL instructions in the PLC programming software serve the same purposes, taking the same inputs and producing the same outputs. This unusual similarity could be attributed to a common trend seen in the development of automation software, where an initial version may have been flawed and replaced with a revised version bearing a slight variation in name. In some cases, the original faulty instruction may have been retained to avoid disrupting existing code implementations or because it still functioned in specific scenarios. This observation calls to mind similar situations encountered with Micro800 PID instructions, suggesting a familiar pattern in software evolution.
After successfully resolving the issue on my own, I made minor adjustments to rungs 5 and 6. I noticed a peculiar behavior with the ACB and ARD blocks - despite being designed to output for only one scan, the Q bits remained high and activated output coils on the rung. By incorporating a normally closed contact to block the output when the count is incorrect, I can better manage the clear bit. It seems likely that @drbitboy's assessment of these blocks being faulty is accurate, as my extensive testing has consistently shown issues. While I am curious to explore other suggestions mentioned in this thread in the future, for now, I am content to leave the code as is to avoid any potential disruption, given that it is currently functioning correctly.
It seems like you've run into a tricky roadblock. From your description, it could be a timing issue. Make sure you've configured the correct timing sequence between your ARD and ACL blocks. Remember that the ARD might need some time to finish its operation prior to executing the ACL. Also consider adding a delay or a latch to ensure the ARD has sufficient time to evaluate the buffer length and to allow the ACL to act accordingly. Manual toggling might be introducing some inconsistency too, because the process might be too quick for the PLC. Lastly, be sure to make use of the error outputs on the ARD and ACL blocks - they could give you additional insight on why the process is not working as intended.
It seems like your issue might revolve around how the ARD block is handling an overflow in data. Since the ARD block is malfunctioning at a barcode length that exceeds 82, it might not be able to handle that many characters, therefore it cannot pass the barcode information accurately to the ACL block for it to clear the buffer. One workaround could be to optimize the logic that handles the buffer clearance when the barcode length is incorrect. You might also want to consider adding an overflow exception that would trigger the ACL block to clear the buffer, rather than waiting for the ARD block to process data that exceeds its capacity. Alternatively, you could limit the scoop into the buffer to a length that you're sure the ARD can handle. Meanwhile, I totally agree on the need for better documentation to clarify the functionality of these blocks.
It sounds like a frustrating issue you're encountering with the buffer clearance. My initial thought is that the problem may lie in the error handling of the ARD block. It might not process the command to clear the buffer by the ACL block, if it encounters an error due to a barcode exceeding the acceptable length. I'd suggest exploring the error handling section of the ARD block to determine if it has any exception handling for such cases, or, you could implement a mechanism yourself to capture such occurrences. As for the limited documentation, I can sympathize – it's often a challenge in the field of automation. You might want to try reaching out to the manufacturer or their online communities for more specific advice.
It sounds like you’re dealing with a frustrating situation, especially with the limitations of documentation. Have you checked the configurations of the ARD and ACL blocks to ensure they're correctly set for your specific application? Sometimes, tweaking parameters like timeouts or conditions for executing the clear might help. Additionally, since you mentioned that the buffer clears correctly for zero or valid lengths, it might be worth exploring if there are any flags or status bits that fail to reset under certain conditions. If nothing else works, consider reaching out to a technical support forum or contacting the manufacturer's support directly; they might have encountered similar issues and could offer insights that go beyond the standard manuals!
It sounds like you're diving deep into some complex testing mechanics with the Micro850! I can see how frustrating the buffer issue must be, especially with the reliance on accurate barcode lengths. Have you thought about implementing a timeout feature for the ACL block, so it forces a reset after a certain period if the length is incorrect? That could mitigate the need for a power cycle. Also, since you're facing issues when the barcode exceeds 82 characters, perhaps experimenting with input validation to catch that before the ARD block processes it might help streamline your setup. Just a thought!
✅ 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 buffer fails to clear with an incorrect barcode length until the PLC is power cycled, which poses a challenge during testing.
Answer: - The ACB block is utilized to count the characters in the barcode buffer and verify if it meets the required test length.
Answer: - The ARD block reads the buffer's content and passes this information to the program to identify the necessary tests.
Answer: - An ACL block is used to clear the buffer to prepare for the next cycle when the barcode length is incorrect.
Answer: - Challenges arise when the barcode length exceeds 82 characters, causing the ARD block to malfunction and preventing the ACL block from clearing the buffer.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.