Hello,
We have a PLC connect by Modbus /RTU to a few Wiren Board WR modules /devices and when we have more than 5 units we start to see lack of speed on the response due to traffic increase in the Bus.
We are going to change the PLC software to Write to the BUS, only when it is really necessary, instead of being permanently send and receiving data. We will polling permanently only the inputs to reduce data traffic.
Is there any tip from your side to improve the response of the devices ? Would be nice to have a kind of " Smart Polling " in your Modules. So the communication would start only after a input change. Is there ?
How do you solve the issue of lack of speed when using your controller ?
Regards,
MDias
Good afternoon.
One request and response (one register) at 9600 has a time of ~ 26 ms.
There are two ways - increase the speed to 115200 (register 110) or decrease the amount of data.
Good morning,
After performing
a few tests we have conclude that there is a huge delay in the input register when compared with counter register for the same input.** Is this suppose to be like this ?
Is this possible to fix ?
This issue was the main reason for the slow Modbus responde.
Regards,
MDias
Good afternoon.
I tried to reproduce the case.
Write
export DEV_PORT=/dev/ttyRS485-2
export DEV_ADDR=42
for i in {0..1000}; do echo "input $(modbus_client --debug -mrtu -pnone -s2 $DEV_PORT -a$DEV_ADDR -t0x03 -r0 | grep Data:)"; echo "counter $(modbus_client --debug -mrtu -pnone -s2 $DEV_PORT -a$DEV_ADDR -t0x03 -r32 | grep Data:)"; done
The value of the input register changes simultaneously with the counter register.
Please show me the way you used to find the delay?
Hello,
When we use the Modbus simulator https://oceancontrols.com.au/ocs-011.html we can easy watch the delay between Input and counter register.
Also when i read in the PLC both register have a big difference. The counter resgister is quicker than the input register by a few hundred of milliseconds…
Please try use the Modbus Simulator of oceancontrols ( works for 15 minutes for free) and let me know the results please.
We also change the input behavior , so the input has been changed to
To complete what i wrote before , the delay accurs when i have the input wired , so when i closed the circuit the time to get the state 1 is slower than the time to see the counter changing/increasing.
Regards,
MDias
May I know what kind of signal is supplied to the input? Are you sure the input stay high after rising edge and doesn’t go low?
Please also tell me the exact device model and hardware and firmware version. They are printed on the label alongside the barcode.
Sure , the input is closed between IGND and one of the terminals numbered from 0 to 6.
We have tried to close the input in many ways , the last test, was joining the wires by hand to be sure that this was not a switch problem. I think would be easy for you to check this behavior if you fiollow what i wrote in the previous message.
Perhaps i will make a video tomorrow and double check the connections although we have already done hundreds of trials using different master devices.
Device model: WB-MR6C V.2
HW: 3. 4
FW:1.14.1
We checked the firmware and confirmed that the both registers (holding register with pulse counter and discrete register with current state) are updated at the same time.
I think what you observe is somehow related to the way the software is polling the registers.
May I suggest you to try a different software?
I would also suggest to increase the baudrate to 115200 b/s. If the delay you observe will decrease at 115200 baud it will confirm that it’s indeed the software problem.
It should also be noted that starting from firmware version 1.15.0 the input handling implementation has been rewritten to handle higher input frequencies. Though neither new nor old implementation have the delay between state and counter registers, I would recommend to upgrade the firmware just in case.
Hello,
Regarding the software , we noticed the problem in our PLC, that is our main device / software.
I refer to the simulator software only because we used it to confirm that the issue was not only found at our PLC and due to fact that is a common tool that both WB and us can use.
In our PLC we are using 19200 b/s , and as already said the counter is very very fast but the input is not.
We will try to update the firmware ( how ? Hope that it´s easy ) as adviced and perfom again the tests than we will give you the feedback.
Our PLC is Micro 820 from Allen Bradley.
Thanks,
MDias
Since you also noticed the problem in your PLC, could you please provide us with the detailed logs of modbus communication?
Please also give us as much information about the simulator setup as possible. I mean a lot of screenshots so we can replicate the exact same setup.
https://wirenboard.com/wiki/WB_Modbus_Devices_Firmware_Update
