In industrial settings, engineers often use Xinghengxun industrial routers to send Modbus data to the cloud. A common and frustrating issue arises: everything works perfectly when the PLC is directly connected via serial cable, but the connection becomes intermittent and unreliable once switched to wireless transmission.
The problem is usually not with the Modbus protocol itself. Instead, it stems from the characteristics of the wireless link (latency, jitter, packet loss) and the device configurations (transparent mode, protocol conversion, timeout parameters) that secretly disrupt communication.
Based on hundreds of real-world projects using Xinghengxun equipment, this guide summarizes the 8 most common pitfalls when using wireless devices for Modbus transmission.
1. Transparent Mode vs. Protocol Conversion: Are You Using a "Pipe" or a "Translator"?
The Pitfall: You assume the router simply forwards data "as is," but it ends up silently modifying the message format.
Xinghengxun industrial routers typically support two working modes:
Classic Failure:
The PLC sends RTU format (with CRC). The router is set to Protocol Conversion mode, converts it to TCP, and sends it to the cloud platform. The cloud platform, expecting RTU, then fails the CRC check.
Or, the cloud sends TCP, the router converts it to RTU but loses the Unit-ID, and the PLC rejects it.
How to Avoid It:
First, confirm the expected protocol format on both ends (RTU or TCP), then select the router mode.
Protocol Conversion Mode is ideal for scenarios where your HMI/cloud only supports Modbus TCP, while your field devices only support Modbus RTU.
If you're unsure, use Transparent Mode and write your own conversion logic for maximum control.
Use packet capture to compare byte-by-byte on the serial side and the network side to check if the router made any changes.
2. Wireless Link Latency: Timeouts Set Too Short Cause "Disconnections"
The Pitfall: A PLC responds in 100ms via serial. Over 4G, occasional timeouts occur. You try to fix it by lowering the timeout from 500ms to 200ms, but it only makes things worse.
The Reality: 4G/5G networks have jitter. Latency might be 30ms normally, but spike to 300ms during peak times. Setting the timeout too tight means a perfectly fine response packet may arrive late, and the master will declare a timeout and retransmit.
An even more subtle problem: Retransmission causes the slave to receive duplicate requests, which can confuse some PLCs. They may return an exception code 06 (device busy), creating a vicious cycle.
How to Avoid It:
Use the ping command to first determine the maximum latency of your wireless link, and set the timeout to 2-3 times that value.
Enable the heartbeat and link detection features on your Xinghengxun router to detect link anomalies early and avoid invalid retries.
3. Endianness: The Router Doesn't Change It, But You Should Verify It's Not "Helping"
The Pitfall: Floating-point numbers read from the PLC are always wrong, and you suspect the router is altering the byte order.
The Reality: In Transparent Mode, a Xinghengxun router does not change the byte order. In Protocol Conversion Mode, it only handles the MBAP header and CRC and does not modify the register data's byte order. More often than not, the problem lies in inconsistent endianness conventions between the two connected devices, and has nothing to do with the router.
Three-Step Diagnosis:
Connect the PLC directly via serial. Is the value correct? → This confirms the PLC's own endianness.
Capture packets on the serial side (using a USB-to-serial tool) to see the original byte order of the raw data → This tells you what the PLC actually sends.
Capture packets on the network side (using Wireshark) and compare them with the serial capture → This tells you if the router changed anything.
How to Avoid It:
In Transparent Mode, the router is a "pipe." Endianness issues stem from the connected devices themselves.
In Protocol Conversion Mode, the router only changes the ADU encapsulation format and doesn't alter the register data's byte order. Prioritize checking the storage method of the devices themselves.
For 32-bit floating-point numbers, there are four common byte orders: ABCD, CDAB, BADC, and DCBA. If the documentation doesn't specify, try all four.
4. Serial Parameters: Are You and the PLC "Speaking the Same Dialect"?
The Pitfall: If even one parameter (baud rate, data bits, parity, stop bits) doesn't match, communication is intermittent or fails completely.
The most common Modbus RTU combination is 8N1 (8 data bits, no parity, 1 stop bit), but industrial sites are diverse:
Power meters often use 8E1 (even parity).
Some older devices use 7E1.
High-noise environments might use 8N2 (2 stop bits, better noise immunity).
Classic Failure:
The PLC is set to 9600/8E1. The router is set to 9600/8N1. Occasionally, data gets through (due to interference accidentally matching the parity), but most frames have CRC errors.
If the baud rate is slightly off (e.g., PLC at 9600, router at 19200), communication fails completely, with no error logs.
How to Avoid It:
Take a photo of the PLC's serial parameters and match them one-by-one on the router configuration.
On Xinghengxun routers, serial parameters are configured via the web interface. Changes apply immediately without a restart.
Enable the serial log during debugging to see transmitted/received bytes and CRC status, allowing for quick identification of the issue.
5. Multiple Masters: The Router Becomes a Traffic Bottleneck
The Pitfall: Two HMIs accessing the PLC simultaneously through the router cause data to become corrupted.
The Reality: Modbus is a master-slave protocol. Only one master can send a request at any given time. When multiple HMIs (e.g., a cloud platform and local SCADA) access the PLC through a single serial port on the Xinghengxun router, requests will collide.
Classic Failure:
The cloud platform polls every 500ms, and the local SCADA also polls every 500ms. Their requests collide inside the router, causing the PLC to receive out-of-order frames and return exception codes.
The router sends Master A's request to the PLC, but Master B's response returns first, leading to Master A receiving incorrect data.
How to Avoid It:
For single serial port scenarios: Implement request scheduling at the application or edge computing node to queue and forward requests sequentially, preventing concurrent collisions.
For multi-serial port scenarios: Connect each PLC to its own router for physical isolation.
Stagger polling intervals: For example, set the cloud platform to 500ms and the local SCADA to 700ms to spread out the peak load.
6. TCP Port Number: 502 Isn't Always the Answer
The Pitfall: You assume 502 is the standard Modbus TCP port, but some devices don't use it.
Common Variations:
Some domestic PLCs use 503 or 1502.
For security, cloud platforms may require a custom port on the router that maps to an internal 502.
The corporate firewall might only allow ports 80/443, blocking 502.
Classic Failure:
The router's destination port is set to 502, but the cloud platform listens on 1502. The connection is established, but no data gets through.
The enterprise firewall hasn't opened port 502. The router shows "connected," but packets can't be sent out.
How to Avoid It:
Confirm the actual listening port on the cloud platform/HMI; don't assume.
Use the port mapping and DMZ features on Xinghengxun routers to translate port numbers at the router level when the internal device port is inconsistent.
Use a packet capture tool to confirm if the TCP three-way handshake is successful. If the handshake fails, check the firewall first.
7. Heartbeat Packets: The Cure for a "False Online" Wireless Link
The Pitfall: The router shows "online," but Modbus requests sent to it get no response, and then it works again after a while.
The Reality: To save resources, carriers often silently terminate idle TCP connections over 4G/5G (especially in NAT scenarios). The "online" status at the router level simply indicates the registration state, but the actual TCP session may already be dead.
Classic Failure:
The polling interval is 5 minutes. It works fine a few times, then suddenly times out. Restarting the router restores the connection.
The heartbeat interval is too long (e.g., 30 minutes), and the carrier's NAT table entry has already expired.
How to Avoid It:
Configure a custom heartbeat packet on your Xinghengxun router. A recommended interval is 30-60 seconds.
The heartbeat can be an empty frame or a Modbus function code 08 (diagnostic) to ensure both ends recognize it.
Set up link quality alerts on the ComCloud platform to get notifications if the heartbeat is lost.
8. Slave ID (Unit-ID): Don't Lose It When Passing Through the Gateway
The Pitfall: The Modbus RTU serial side has a slave address (e.g., 01), but after converting to TCP, the cloud platform can't identify this address.
The Reality: The Modbus TCP ADU header has a Unit-ID field, which theoretically corresponds to the RTU's slave address. However, some routers, when performing protocol conversion, default to filling the Unit-ID with 0 or 255. When the cloud platform tries to route by slave address, it can't find the device.
Classic Failure:
The original RTU frame from the serial side (slave ID 01, function 03, read 1 register):
01 03 00 00 00 01 84 0A
After protocol conversion, the TCP frame becomes:
00 00 00 00 00 06 00 03 00 00 00 01
(Here, the Unit-ID has changed from 01 to 00, so the cloud platform can't find the device.)
In simple terms: The slave address 01 from the RTU message is changed to 00 by the router during conversion, making the device invisible to the cloud platform.
How to Avoid It:
In Protocol Conversion Mode, ensure the router is configured for Unit-ID passthrough or a custom value, matching the cloud platform's expectations.
If unsure, capture packets on the TCP side and check the 7th byte of the ADU header – is it the expected slave address?
In Transparent Mode, the slave address is contained within the PDU and won't be lost. However, this requires the cloud platform to be capable of parsing RTU format.
Summary
Using 4G/5G to transmit Modbus data doesn't change the protocol itself, but it does change the transmission medium. Your configuration logic must adapt.
Three Key Steps for Modbus Over Wireless:
Confirm the Mode First: Transparent or Protocol Conversion? Ensure the formats on both ends are aligned.
Adjust Timeouts: Wireless links have jitter. Setting timeouts too tight will cause problems.
Always Capture Packets: Compare messages from the serial side, the network side, and the cloud side byte-by-byte. The truth is always in the packets.
