I got a problem with modbus rtu over tcp protocal to read some energy device.
A 485 to tcp servert port was used. I had tried with modbus poll to read those addresses，everything goes well.
However with ignition modbus rtu over tcp module, the bellowing warnning was continuously loged.
ReadHoldingRegistersRequest
19Jun2020 21:19:40
Request failed. FailureType==TIMEOUT
TimeoutDaemon
19Jun2020 21:19:40
ScheduledRequest[com.inductiveautomation.xopc.drivers.modbus2.requests.ReadHoldingRegistersRequest@2085e362] request with key "937" failed due to timeout.
I add those nodes 1 by 1 for test, when the number for nodes is 1 or 2, everything is ok, but when the number bigger than 3, the warnning occurs.
It seems something was wrong with that modbus rtu over tcp module.
Does anyone else meet the same probelm ?
Sounds to me like you are putting too many items in your scan. And/or too fast a group rate. Modbus RTU is a rather slow serial protocol–connecting over TCP doesn’t make it faster. See what happens if you test unit 3 alone.
Thanks for your suggestion.
My tag datatype is attached, 10 items for per unit(or node). PD_HOKO.json (3.3 KB)
If only 1 unit was tested, no matter which unit, everything goes well.
But if 3 or more units were tested, the quality of all tags was flashed from “Good” to “BAD”.
The problem is for each device connection, 20 units were listed.
I will say it is not the problem of modbus rtu protocal or the port convertor , because I tested with other software with the same scan rate (1 second) successfully.
Hi there,
Thanks for your coment.
The modbus salves were some power meters,local brand, I can’t even find an English manual for that.
The 485 to TCP convertor was Korenix JetPort 5601.
[https://www.korenix.com/en/product/show.aspx?num=60](http://jetport 5601)
Also a ticket was submit for support.
Just wonder to know if someone else met the same issue.
what network setup (architecture), e.g. LAN, WAN, Cellular from server to Jetport
what is the RS485 baud rate
raw data type? e.g. 32-bit float
preferred or essential
what cable? shielded? twisted pair? csa? end resistors?
100 meters between each power meter, maybe 30 slaves max, total rs485 length from AB of Jetport to AB of last meter = 30 *100 = 3KM??
I am asking more questions perhaps than needed, but you need to consider these points for the final fitted solution
preferred, but when I got first failure, 10 seconds was tried , same problem.
shielded twisted pair.
The power meters was in the same room, so total length for a Jetport 485 wire is around 100 meters.
Agreed, the hardware connection is all good and checked.
I had tried an IIOT device from Beijer to load the same Jetpot with 1 second scan rate. Everything goes well.
Now I use IG as an OPC-UA client to read those data from Beijer temporary.
OK without knowing your hardware (as in, you can’t provide a manual and I have never used those brands)
Go to the Ignition Gateway
Go to status
Go to devices
Click on the device (“Details”) when only 1 JetPort is connected
Look at the information
Now change the min level from info to trace
Then add more nodes until it fails, look again, compare the information
Then go into device settings (config section of gateway)
go to each JetPort and start changing the advanced settings down
e.g. max holding registers per request
etc, etc
Other things to try outside of Ignition;
Increase the baud rate. Note the higher the baud rate, the better your physical cabling needs to be
Change settings in the JetPort
Remember here, you are not asking for 10 tags every second. You are asking for 200-300 tags per second per JetPort. All floats.
Whilst I haven’t used your power meters, I can tell you there are physical, hardware-based limitations on how many tags you can read at once. @pturmel covered this in his first reply.
You should use a Modbus TCP to Modbus RTU gateway (there are many to choose from) instead of a serial device server. Anyway…
Create a unique driven tag group (scan class) for each energy device and assign the tags in that device to the group. Set the scan rate for each tag group that is connected to the same serial device server a little differently. E.g.,
tag group A, 5000 ms
tag group B, 5210 ms
tag group C, 5420 ms
and so on.
Now you are not trying to poll all of the end devices at exactly the same time. See how that works. You will still get some errors, but it should work much better.
To get rid of more errors you will have to use driven tag groups and write a script to trigger the reads one end device at a time, waiting for a reasonable timeout period before triggering the next device read.
Your network load is not the problem. Based on your JSON export, most of your tags are contiguous, words 22-35, with three others: 6-7, 44-45, and 66-67. Ideally, you need four requests to read these blocks, satisfying the ten float tags. Per the modbus specification (PI-MBUS-300 from modbus.org) these requests and their responses should take 62.5ms at 19200-N-8-1 (including the inter-message silent time on the wire). Twenty devices is a modest overload–you won’t get one-second timing.
I believe Ignition will make the requests in the pattern above if the “Span Gaps” setting is turned off in the driver. I suspect that your devices have registers (other than your ten) that respond poorly, and spanning gaps will read unexpected registers. Spanning from word 6 to word 67 would take 75ms, but would read up to 31 floats, which is why it is default “on”. Try turning that setting off.
