Troubleshooting RedLion CR3000 Modbus Slave Communication Problem via RS-485

Question:

I have numerous DA30 and CR3000 RedLions that are actively communicating with a PLC through ethernet and transmitting data to third parties via 485. While I have been utilizing a standard configuration for all devices, one recently began experiencing issues without any apparent cause. Upon investigation, I discovered that the problem stemmed from using both integers and real numbers on the same device. When I try to input an integer in a separate block, it disrupts the transmission of real numbers. This issue has been replicated in a lab setting, but the underlying reason remains unclear. It is crucial to maintain the order and type of registers to avoid any disruptions in communication with third parties, which will require coordination to rectify. Your assistance in resolving this matter is greatly appreciated. Thank you.

Top Replies

If you encounter a device that has suddenly stopped working properly, it is important to consider any recent changes in the system. If no changes were made, it is worth investigating whether the issue lies with the software or database. Sometimes, communication issues can cause devices to malfunction and experience timeouts, especially when multiple requests are made simultaneously. Resetting the database on the problematic DA30 or CR3000 device may help, as databases can become corrupted over time. Additionally, it is advisable to try swapping out the device to determine if the problem is specific to that particular device.

For the best assistance, contact Red Lion's dedicated support team. They possess valuable knowledge and solutions that may not be found in the user manual. Oftentimes, user manuals may be outdated or lacking important information. Within Crimson 3.2, there is a feature named "Export Gateway Blocks" which allows for the transfer of configuration data for "PLC1" into a text file, making it easier for troubleshooting. It would be beneficial to know the version you are using and to provide the exported data for further analysis. There may be a discrepancy in the block size due to potential overlapping issues with the tags.

Thank you for the responses. What has changed today? I have installed two new units and transferred the same configuration with only changes in IP addresses and slave addresses (1 & 2). One of the units is functioning properly, while the other is not. I have attempted to recompile the database and communication blocks (File>Utilities) and have also tested with different devices in the lab, including a DA30 and a CR3k. I will be reaching out to RedLion for assistance, but I am wondering if this issue is a common one. Please see the exported gateway block attached. Note that PLC1 is not the specific block I am working with; I have simplified it to the smallest size possible while still encountering the problem. My software version is 3.2.1016.0. I am unsure why there may be an overlap. 40,001 is a Real, requiring two bits, while 40,003 is an int, requiring only one bit.

I found a workaround by merging and performing bit shifts on integers, allowing me to successfully access and interpret the data. Though a bit cumbersome, this method has proven effective for reading the information.

I was testing for overlapping INT block definitions in the system file. It seems the INT block starts at address 400003 with a length of 1, although it wasn't very clear in the screenshot. I agree with another user that the problem may be related to hardware issues or corruption. I have experienced issues in the past with malfunctioning serial ports that displayed some indicator lights, as well as problems caused by incorrect image file writing in Emulator mode that rendered certain hardware components unusable until the issue was resolved.

Interesting issue. It seems like there could be a data conflict, possibly due to the different data type interpretations between your RedLions and the PLC. A potential workaround might be to create and use separate instances for integers and real numbers. This could alleviate any confusion the devices might be having when interpreting different types of data simultaneously. It's crucial to ensure a common language and data format for seamless communication between your devices. Also, have you updated to the latest firmware? Sometimes these glitches can be resolved with a simple update.

It sounds like you've run into a classic data type conflict, which can be a bit tricky in mixed environments. It might help to check if the device firmware is up to date, as sometimes bugs get ironed out in newer versions. Additionally, ensuring that your data blocks are clearly defined with consistent type casting could alleviate the issue. Have you considered implementing different communication protocols for your integer and real number data or possibly using data encapsulation techniques? It could help maintain order and reduce disruptions. Good luck, and I hope you find a solution soon!

That's an interesting challenge! It sounds like you've narrowed down the issue to the data types causing communication headaches. One thing to check is if the device's firmware can handle mixed data types effectively, as some models might have quirks when it comes to integer and real number processing. It might also be worth looking into how those data types are buffered or parsed during transmission; there could be some configuration settings that need adjusting. Coordinating with the teams on the receiving end to ensure they can manage both data types simultaneously could also provide a workaround while you’re troubleshooting. Good luck, and keep us updated on your progress!

More Replies →

Streamline Your Asset Management
See How Oxmaint Works!!

✅   Work Order Management

✅   Asset Tracking

✅   Preventive Maintenance

✅   Inspection Report

We have received your information. We will share Schedule Demo details on your Mail Id.

You must be a registered user to add a comment. If you've already registered,
sign in. Otherwise, register and sign in.

Frequently Asked Questions (FAQ)

FAQ: 1. What could be causing communication issues with the RedLion CR3000 Modbus Slave via RS-485?

Answer: Answer: The issue might arise from mixing integers and real numbers on the same device, causing disruptions in data transmission.

FAQ: 2. How can I resolve communication problems when using different data types on the RedLion CR3000?

Answer: Answer: To maintain consistent communication, ensure that the order and type of registers are coordinated to avoid disruptions, especially when sending data to third parties.

FAQ: 3. Have others experienced similar issues with RedLion devices communicating via RS-485?

Answer: Answer: While not explicitly mentioned in the thread, issues related to data types and transmission disruptions can be common in industrial communication setups using Modbus protocol.

Ready to Simplify Maintenance?

Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.

Request Demo  →