Hello, I recently upgraded a customer's Allen Bradley PLC system from an SLC5/05 to a Compactlogix, utilizing the 5069-serial card for maintaining df1 serial communication through mds orbit radios. This new setup includes a polling master communicating with over 20 remote sites using df1 over unlicensed mds orbit radio frequencies. However, I have encountered communication issues since the upgrade. The polling routine was transferred from logix500 to studio5000, with only minor alterations such as using the previous MSG .EN bit to trigger the next message instead of using CLR statements as before. It seems that the new serial card may have different timing requirements causing the noticeable decline in performance. I have included images of the communication port setup, revealing discrepancies in the available options. Has anyone encountered a similar situation and found a solution? Any advice or suggestions would be greatly appreciated.
Utilizing the .EN bit in the trigger for the next message may not provide clear benefits. I was cautioned against enabling Duplicate detection due to inefficiencies. Monitoring the serial traffic and understanding the timing involved is crucial in identifying issues. The MDS Orbits are capable of capturing traffic as it passes through, providing valuable insights into the situation.
The .en bits may not have been essential, but the polling routine processes messages one at a time. Duplicate detection is enabled at the master and all remote sites by default, and I have not changed it. If this is the issue, I am surprised it has not had a greater impact on the SLC. I am unfamiliar with sniffing serial traffic. Would setting up a system on the network to capture and review it be helpful?
One way to troubleshoot connectivity issues is by performing a port capture on both the serial and LNRadio ports. By analyzing the captured data, you can check if the device is continually attempting to reconnect. This method can help in diagnosing persistent connection problems effectively.
I distinctly remember the timeouts on the gateway I used were not flexible, but rather definitive. For example, if you set a 5-second timeout, the gateway would wait the full 5 seconds before processing the packet, regardless of when it was received. This can significantly slow down your operations.
It sounds like you're right on track in suspecting the timing requirements of the new 5069-serial card. I recall facing a similar issue when upgrading a customer's PLC system. You might want to review the card's technical specifications thoroughly again, especially its baud rate. In the case I dealt with, adjusting the MG instructions in my program and tweaking the communications timeout settings in my communication port setup significantly improved the performance. Also, verify the stability of your radio link, as any inconsistency there could upset the communication too. Besides, are you using any error handling or timeouts between messages in your control program? Properly placed timeouts could really help with communication stability. Lastly, ensure that your polling routine isn't overwhelming your card with too many requests at once, which can also curb performance. Hope this helps!
It sounds like you've done a thorough job transitioning the PLC system. As for the communication issues, it indeed may be due to mismatched timing requirements between the new serial card and the existing system setup. However, another thing to consider is any firmware discrepancies between the older and recent versions. Upgrading firmware can often iron out such hiccups. Additionally, I'd recommend a detailed analysis of the port settings in Studio 5000 comparing them with the previous setup in Logix 500. A minor overlooked setting could be responsible for the communication issues. I've seen cases where flow control settings led to similar problems. Lastly, the radio link quality and baud rate for DF1 communication might need to be reevaluated for the new setup. Hope this helps steer you in the right direction.
It does seem like the changed setup could be causing some timing discrepancies. I recall working on a similar issue where the fix was to introduce a brief delay between the MSG instructions given the Compactlogix system is considerably faster than the old SLC5/05. Alternatively, introducing an interlocking mechanism for the transactions might help keep things in check, ensuring that a new message isn't triggered until the old one is acknowledged as finished. Also, double-check your port configuration parameters. Minor differences between SLC and Compactlogix systems can cause significant changes in functionality. Good luck, and keep us informed about your progress.
I had a similar issue with a Compactlogix upgrade a while back. Your suspicion about the timing issues with the new serial card could be on-point. Are you using the standard RSLogix5000 MSG command or the Produced/Consumed tags? A robust error checking and retransmission strategy might also be necessary when dealing with radio communication. Also, try to play around with the port configuration parameters like the Baud, Parity, Data bits, and especially the silent period - I've found that adjusting these can sometimes solve communication issues. I advise checking AB's recommended settings and comparing them to your setup. Don't forget the firmware should also be up-to-date. Hopefully, this can get you in the ballpark, good luck!
✅ 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 new serial card may have different timing requirements, causing a decline in performance. Minor alterations in the polling routine, such as changing how messages are triggered, could also contribute to the issues.
Answer: Answer: Differences in available options on the communication port setup could potentially affect the configuration needed for proper communication, leading to issues in maintaining connectivity with over 20 remote sites.
Answer: Answer: Other users who have worked with similar setups may have encountered and resolved similar issues related to serial communication and timing requirements when transitioning to newer hardware and software platforms like Studio5000.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.