Hello everyone, I am currently working on an exciting project involving a remote Remote Terminal Unit (RTU) system developed by Data-Linc. Specifically, I'm utilizing the CIX-6430 remote RTU paired with the CIX-6435 master unit. Since there is only one remote RTU in this setup, the project remains relatively straightforward. The remote RTU is equipped with two analog inputs sourced from level transmitters, which send raw data to the master unit via a 900 MHz spread spectrum radio signal. My primary goal is to establish communication between my RX3i controller and the master unit using Modbus TCP. After encountering some issues in the field that we suspected might be related to the radio path, I decided to bring both units to my workbench. To eliminate any uncertainty regarding the radio signal, I connected them through an attenuator. Once I configured the radios correctly, I attempted to poll the remote site through the master using software on my laptop. Unfortunately, this approach did not succeed with Modbus TCP. However, when I shifted to Modbus RTU and used a serial cable for the connection instead of Ethernet, everything functioned seamlessly. I have attempted to use Modbus TCP with both qModMaster and SimplyModbus, but each produced error messages. I am currently in discussions with tech support about these issues. However, I wanted to reach out to this community to see if anyone has experience working with these specific devices or similar setups. Any insights or advice would be greatly appreciated!
Let’s begin by discussing the radio connectivity. The radios used in these units are among the most reliable modem technologies available today, and the chances of them being the source of any issues—particularly when tested on the bench—are extremely low. If you’re not employing at least 120dB of attenuation and have the transmit power dialed down to 1 or lower, you risk damaging the receivers. It would be wise to remove the attenuator and replace the antennas. To quickly confirm if the units are communicating effectively, observe the LED indicators. On the remote unit (CIX6430), if the “I” and “O” LEDs flash continuously, it indicates that the remote is successfully communicating with the master unit (CIX6435). However, if you notice these LEDs pausing intermittently, it suggests that the master unit has been programmed for multiple remotes and may need reconfiguring to link with just one remote. It's important to note that since communication was successful with Modbus RTU, this is unlikely to be an issue related to remote or radio addressing. Regarding Modbus TCP, my experience primarily involves systems like Allen Bradley, so my expertise in Modbus TCP is limited. However, I can offer some tips to help troubleshoot common issues. One frequent oversight—please excuse me if this seems basic but I’ve made this error myself—is the terminology: in Modbus TCP, the Modbus Server functions as the Modbus Slave while the Modbus Client operates as the Modbus Master. In this case, the CIX6435 acts as the Modbus TCP Server, while your software (GE RX3i) serves as the Modbus TCP Client. This can be confusing because the CIX6435 is configured as a Master between the two modems, yet acts as a Slave to the PLC. Another area to experiment with is register addressing. In Modbus, there are two types of addressing: “PLC” and “Non-PLC,” with the former starting at “0” and the latter starting at “1.” Sometimes, trial and error is necessary. It's also worth noting that when the CIX6435 operates under Modbus RTU, it may utilize the PLC addressing scheme, whereas Modbus TCP could default to the other (this may be a bug). While I can’t guarantee this is the case, I've encountered similar anomalies before. Unfortunately, I wish I could provide more detailed assistance; however, I no longer work in that capacity and lack access to the units and software for practical testing. If you have the ability to connect via a Modbus RTU port, I strongly recommend that approach, as I've found the CIX6435 to be more stable with Modbus RTU. If possible, transitioning to DF1 or Ethernet IP/TCP would likely yield even better results, but Modbus TCP should function adequately.
Subject: Insights into Modbus TCP Communication Protocol Hello Firejo, I appreciate your prompt response! Today, I dove deep into the intricacies of our situation and gathered some valuable technical insights to share. What better way to kick off the weekend than by exploring raw data at the bit and byte level while reviewing the Modbus/TCP specification, right? Let’s delve into the world of Modbus. It's a communication protocol that effectively assembles bytes and transmits them serially. This allows us to dissect the data string and understand the function of each byte. For instance, to read the first analog input register, the Modbus TCP request message appears as follows: `00 01 | 00 00 | 00 06 | 01 | 04 | 00 00 | 00 01` I’ll break down each section of this string, which is separated by vertical bars for clarity. ### Explanation of Sections: 1. **Transaction ID**: This component records requests and increments with each new request sent. 2. **Protocol ID**: Always represented as `00 00`, indicating that this is a Modbus TCP message. 3. **Message Length**: This specifies the number of bytes in the Protocol Data Unit (PDU), which encompasses sections 4-7. In this case, that's 6 bytes. 4. **Unit ID**: Represents the Slave's address. Note: per the Modbus/TCP specification, it's often suggested to set this to either 0 or `16#FF`, though I’ve found better results using the actual Slave ID during my tests; your experience may vary. 5. **Modbus Function Code**: A value of 4 indicates that we're reading input registers. 6. **Starting Address of Data**: For function code 4, the system assumes an offset of 30001, making `00 00` the starting point for reading from address 30001. 7. **Length of Data**: This defines how many registers we are reading. In this case, we are reading a single register, which corresponds to Analog Input 1. Interestingly, when I send this request to the Data-Linc modem, the response I receive simply reflects the initial request without actual data being transmitted; it merely echoes back what I sent. For example, when I issue the request: `00 01 | 00 00 | 00 06 | 01 | 04 | 00 00 | 00 01` the output observed on the data bus from the Data-Linc modem is: `00 01 | 00 00 | 00 06 | 01 | 04 | 00 00 | 00 01` However, when I perform the same test with another PLC (the Scadapack located in my office), the response is markedly different. A successful Modbus request results in a response that looks like this: `00 01 | 00 00 | 00 05 | 01 | 04 | 02 | 00 00` ### Detailed Section Analysis of Response: 1. **Transaction ID**: Matches the request ID to maintain continuity. 2. **Protocol ID**: Maintains `00 00` for Modbus TCP. 3. **Message Length**: Indicates a 5-byte response, differing from the 6-byte request. 4. **Unit ID**: Remains consistent with the request. 5. **Modbus Function Code**: Confirms the response corresponds with the requested function code (4). 6. **Number of Bytes of Data Requested**: Indicates the response consists of two bytes, representing a single 16-bit register. 7. **Data Requested**: Represents the actual data in the register requested, in this case, corresponding to address 30001 with a value of 0. Additionally, I have configured my GE PLC—matching the model currently deployed in our field project—to interact with the Data-Linc radio. While I can establish a connection, requesting read data results in a "protocol error," with no additional specifics provided. I suspect this is due to the response repeating the echoed request message, which may not be interpretable as a valid response. Given these observations, I’m uncertain why the modem simply echoes the request rather than transmitting an appropriate response. I've shared this detailed information with technical support in hopes that it aids in troubleshooting our current issues. It's certainly been enlightening to explore the underlying mechanics of Modbus TCP, and I believe this understanding will be invaluable for further diagnostics. Thank you for your support, and I look forward to your thoughts! Best regards, [Your Name]
While I might not be entirely accurate, I believe that Modbus is essentially Modbus TCP encapsulated. To gain insights into the communication between your Modbus Master simulator and the response (if any) you receive, I recommend utilizing Wireshark. It sounds like you have a solid grasp of Modbus, but I struggled to understand the intricacies until I completed an online course on Udemy. It was a valuable investment at just $10. For those interested in mastering Modbus protocol and improving their networking skills, exploring online courses is a great option to enhance your understanding effectively.
Modbus is essentially Modbus TCP in a different format. However, it’s important to note that Modbus/TCP is not merely Modbus RTU transmitted over a TCP connection. Many Ethernet master devices offer an alternative known as "Modbus RTU over Ethernet encapsulation," which is distinct from standard Modbus/TCP communication. If your end device operates as a general-purpose TCP/Serial server, this method can be utilized. Notably, defcon.klaxon's observation of receiving an echo rather than a proper response indicates there may be a configuration issue that is causing incoming data to be echoed instead of processed correctly. A frequent challenge when working with Modbus/TCP devices is the Unit ID. This is crucial because a typical Modbus/TCP device functions as a protocol bridge, which unfurls the command and forwards it via a serial port using Modbus RTU protocol. Consequently, the Unit ID is translated into the Slave ID within the Modbus RTU packet. When it comes to setting the Unit ID, there is often uncertainty, as it varies between devices. Some may require you to use 0, 255, or 1 as the Unit ID, while others may ignore it completely. If you can capture a Wireshark trace, please compress it into a ZIP file and share it; this could provide valuable insights for troubleshooting.
According to harryting, there might be a misconception that Modbus is merely Modbus TCP in a different format. To clarify this, I've relied on two primary resources: SimplyModbus.ca and the Modbus/TCP specification document. By analyzing these sources, I was able to decipher the byte strings for both RTU and TCP communication modes. Utilizing the SimplyModbus software for RTU and TCP, I sent messages to various PLCs (Programmable Logic Controllers). The constructed byte strings for requests are documented, along with the responses received, enabling me to track the interaction effectively. I highly recommend using Wireshark to capture the outgoing requests from your Modbus Master simulator and any incoming responses. This analysis can provide valuable insights. As I mentioned earlier, I've been able to monitor data transmission utilizing the SimplyModbus software, and I've tested several other tools as well, achieving consistent results. It seems you have a solid grasp of Modbus. I didn't fully comprehend the protocol until I took an online course on Udemy, which was a fantastic investment at just $10. Now, I feel quite confident in my understanding. Diving deep into the bit and byte levels has greatly enhanced my ability to troubleshoot and comprehend the protocol intricacies.
Hey there! It sounds like you're on a challenging yet interesting path with your RTU project. Since you've already confirmed that Modbus RTU works through a serial connection, it could be worth double-checking the configuration settings for Modbus TCP, especially things like the port number and IP address setup on both the master and the RX3i. Sometimes firewalls or network settings might also block communication, so it might be good to ensure those are configured correctly as well. Have you tried running any diagnostic tools to see if you can get more detail on the errors with Modbus TCP? Best of luck with it, 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.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.