Greetings to my fellow engineers, I am currently facing a unique challenge as we upgrade one of our oldest systems to PLC controls. As part of this process, we are integrating an Accu-Sort AV6010 scanner with serial communications (RS232) connected to a Siemens ASCII scanner. However, we are encountering issues where the system is only receiving data and not sending acknowledgments back to the scanner. The existing system setup involves a PC-based controller communicating with the Siemens ASCII scanner through Profibus. The scanner sends a heartbeat signal to the existing system every 5 seconds. The serial port settings on the scanner are as follows: BaudRate 19200, stopbits 1, parity none, databits 8, flowcontrol none. In our new configuration, we are using an L83E/A4 Backplane with a 1769-Aen2tr that has a 1769 ASCII Scanner on its backplane. We have replicated similar settings as above to configure our ASCII scanner and used a cable with swapped connections (2-3, 3-2) while keeping 5-5 consistent. We are utilizing RS232 to connect to the 1769 ASCII scanner. The issue we are facing is that we are not receiving data consistently at the transmit point. Sometimes we receive data in the correct location, while other times it is delayed by 30-40 seconds after scanning is completed. We are seeking assistance in identifying and resolving this issue. If anyone has any insights or solutions to share, please do not hesitate to reach out.
When troubleshooting, it's beneficial to have a breakout box for monitoring RS232 traffic with a laptop. It's important to verify if the AV6010 relies on hardware handshakes. Can you confirm if the cable pinout is the same as the previous one, with TXD-RXD and common connections?
According to the customer, handshakes are not involved in their system. After disconnecting the TXD wire from the Siemens ASCII scanner, they found that the system was only receiving scanner information without transmitting anything back. The setup utilized only TXD, RXD, and Common cables, which were tested multiple times with consistent results. Despite trying different pinout configurations found on the internet, the Siemens ASCII scanner only has 3 wires connecting to slots 4, 5, and 8 for TXD/RXD and Common functions.
To clarify, does the current system not initiate a request to the AV6010 for data without a TXD connection? Does the AV6010 simply transmit data at regular intervals, or is there a specific signal or mechanism that prompts it to do so? This is reminiscent of how we previously had to remotely trigger Cognex cameras.
In a recent discussion, nspr2195 mentioned the issue of the system only receiving scanner information without transmitting any data back to the scanner. This could be resolved by ensuring a locally wired photoeye triggers the scanner, followed by various possibilities such as transmitting based on position or timing after trigger. Another common method includes using a transmit delay to add time for falling edge or encoder transmits. It is also common to have a separate 'timeout' send with an error code. This equipment may be used in conveyor systems. It is worth noting that Accusort is now part of Datalogic, and they may provide assistance if there are hardware issues.
jstolaruk inquired about the data transfer process of the AV6010 system. Is there no TXD connection for requesting data from the AV6010? Does the AV6010 simply send out data periodically or is there a hardware signal that prompts it to do so, similar to a remote trigger used with Cognex cameras? Once a barcode is scanned, the data is transmitted to the system without the need for a relay or TXD connection.
Hi, sounds like a tricky situation you're in. Ensuring that your devices communicate properly can indeed pose challenges. You mentioned that you're using RS232. Have you checked if your scanner and PLC are sharing a common ground? This is crucial for the RS232 communication. Also, to isolate the issue, try and set up a simple communication test with a separate device, it might help you figure out whether the problem lies with your scanner or the PLC. Additionally, it might be worth looking into whether your scanner requires any form of end character to be sent after your data. I've heard of cases where devices wouldn't send an acknowledgment until it receives certain end characters. Good luck with troubleshooting.
Hey there, It sounds like quite a challenge you're dealing with. Based on my personal experience, I'd suggest double checking the 1769 ASCII scanner settings and the serial settings on your PLC. There might be a discrepancy causing these inconsistencies, such as baud rate, stop bits, or parity bits. Additionally, you may want to look into any potential time-outs in your PLC code or possible misconfigurations with the data buffering that might cause data to get 'stuck' or delayed. Lastly, don't overlook physical elements – sometimes a bad serial cable or port can cause sporadic issues. Hope this gives you a new path to explore. Good luck!
From your explanation, it seems like the issue might be related to a possible delay or time lag due to the use of the 1769-Aen2tr module. I've noticed that this particular model struggles with in-time data transmission. You might want to try using an alternative model that can better handle RS232 communications. Additionally, you may also consider exploring the settings on your ASCII scanner just to make sure no delay settings have accidentally been activated. Just an afterthought, have you investigated if there is a firmware update available for your ASCII scanner module? Sometimes, such updates include improvements or fixes to data transmission issues.
It sounds like a tricky situation you're dealing with! One thing to consider is checking the buffer settings and timeout parameters on both the scanner and your PLC. Inconsistent data reception could stem from either a mismatch in communication settings or perhaps the way the data is being processed on the PLC side. You might also want to verify the integrity of the physical connections and the cable—those swapped pins can sometimes create headaches if not perfectly aligned. Have you tried logging or monitoring the serial communication to see if anything specific happens before the delays? That could help pinpoint where the hiccup occurs.
Hey there! It sounds like you're dealing with quite the challenge. One thing to check is the timing between your heartbeat signals and how your new system interprets them. Since you’re getting intermittent data, it might be worth looking into whether the serial buffer is getting overwhelmed or if there’s a mismatch in timing causing the delays. Also, ensure that your ASCII instructions are set correctly for both sending and receiving data; sometimes, those simple settings can cause unexpected behavior. Have you tested the cable and connections thoroughly to rule out physical issues? That could be a potential culprit as well. Good luck, and I hope you get it sorted out 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: Answer: The serial port settings for the Accu-Sort AV6010 scanner in this setup are: BaudRate 19200, stopbits 1, parity none, databits 8, flowcontrol none.
Answer: Answer: The issue being faced is that the system is only receiving data and not sending acknowledgments back to the scanner consistently. Sometimes data is received at the correct location, while other times there is a delay of 30-40 seconds after scanning is completed.
Answer: Answer: The existing system setup involves a PC-based controller communicating with the Siemens ASCII scanner through Profibus, while the new configuration uses an L83E/A4 Backplane with a 1769-Aen2tr that has a 1769 ASCII Scanner on its backplane, utilizing RS232 for communication.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.