Welcome to LinuxCNC.org

Hello,

I have a question: ¿ Does Modbus TCP (over Ethernet) waits for response of Device1 before send the request to Device2 ?

If i use RS-232, first the port sends a request to Device1, waits for response and then sends the request to device 2, waits for response and then starts the cycle again ¿ I am right ?

I am asking this because i am currently using Modbus RTU over RS-485 at 115200 baud rate (using a RS-232 to RS-485 conversor) to read 4 registers (not continuous) of X axis servo drive (power consumption, status, internal temperature and alarms of a Delta ASD-B servodrive).
I am planning to add 2 servo drives more (Z axis and spindle) but the problem is that i have a slow refresh rate.

I need a better refresh rate because i am planning to graph X Z and spindle real time power consumption in order to optimize feed rates (this is a production lathe and time matters)

RS-232/485 conversor option: 4 reads with 50 ms delay (if not i get an error) x 3 drives = 600 ms = 1.6 Hz refresh rate
Modbus TCP (Ehternet) / RS-485 conversor option (3 conversors in parallel): 4 reads with 50 ms delay? = max 200 ms = near 5 Hz refresh rate
¿ Is this correct ?

Thanks you in advance,
VNR

Modbus over serial line it's not indicated in case you need fast reading or writing .
Another issue is how fast your devices are responding to a Modbus request.
In case you have multiple slave devices to handle , be sure to not use with the serial line an higher communication speed
(i.e. 19200 baud is quite a standard and it is relatively "fast").
I'm surprise tha you are using 115200 baud !
Maybe the slow response you have is because the communication speed is too high and the slaves do not communicate fine so the master (LinuxCNC)
have to retrieve the communication to get a right answer.

Modbus is Modbus ,the difference between Serial line and TCP/IP is only the media used for the communication but the protocol itself is the same.

bigalex

Self response: Yes it does in classicladder (fix me if i am wrong) but the protocol says that you can send many requests before reading the response and additionally you can use many connections to the same device.
This week i am going to buy a "remote I/O with modbus TCP", so i will do some timing tests.
I think i will have to write a new modbus library in order to exploit many connections to the same device and many request at the same time.

You can send only one Modbus request at the same time at the same Slave Device.
Modbus it's not a deterministic protocol.
Modbus is a single master communication protocol that means that if LinuxCNC is the master , it will handle the communication instances and normally it send a Modbus request to a slave device and wait up to a timeout the correct answer from the slave device, then go ahead to the next Modbus request (same slave or different slave) .
I made many tests with the Modbus TCP/IP with different slave devices and I can say it works fine and the communication latency is less that 100ms.
As much you reduce the Modbus requests to a single device (i.e. to read 5 coils you made 5 different requests) as much the communication will be efficient.

bigalex

My BENCHMARK:
==============

---

READ REGISTERS (libmodbus 3 - modbus_read_registers) (Modbus function 0x03)
PLC Simulator on Windows XP: Ethernet 100 mbps TCP-IP

Transfer Rate:
* 1000 cycles x 2 contiguous registers in 13709849.00 us (13.71 s)
* 145.88 registers / sec
Loop Time:
* 72.94 loops / sec (HZ)
* 2811.00 us connect and 1st loop
* 122.00 us min loop
* 24791.00 us max loop
* 899 loop more that 250 us (89.9%)

---

READ REGISTERS (libmodbus 3 - modbus_read_registers) (Modbus function 0x03)
Remote I/O Delta RTU-EN01: Ethernet 100 mbps TCP-IP (Running 6 clients in parallel)

Transfer Rate:
* 10000 cycles x 2 contiguous registers in 50016909.00 us (50.02 s)
* 399.86 registers / sec
Loop Time:
* 199.93 loops / sec (HZ)
* 10480.00 us connect and 1st loop
* 327.00 us min loop
* 11005.00 us max loop
* 10000 loop more that 250 us (100.0%)

---

READ REGISTERS (libmodbus 3 - modbus_read_registers) (Modbus function 0x03)
Servo Drive Delta ASDA-B: RS-232 /dev/ttyS0 115200 bps 8N2

Transfer Rate:
* 1000 cycles x 2 contiguous registers in 4007595.00 us (4.01 s)
* 499.05 registers / sec
Loop Time:
* 249.53 loops / sec (HZ)
* 10443.00 us connect and 1st loop
* 3882.00 us min loop
* 6310.00 us max loop
* 1000 loop more that 250 us (100.0%)

---

READ REGISTERS (libmodbus 3 - modbus_read_registers) (Modbus function 0x03)
Remote I/O Delta RTU-EN01: Ethernet 100 mbps TCP-IP

Transfer Rate:
* 10000 cycles x 2 contiguous registers in 8200305.00 us (8.20 s)
* 2438.93 registers / sec
Loop Time:
* 1219.47 loops / sec (HZ)
* 10478.00 us connect and 1st loop
* 485.00 us min loop
* 5168.00 us max loop
* 10000 loop more that 250 us (100.0%)

---

READ REGISTERS (libmodbus 3 - modbus_read_registers) (Modbus function 0x03)
Localhost Modbus TCP-IP Server created with libmodbus-3

Transfer Rate:
* 25000 cycles x 2 contiguous registers in 459568.00 us (0.46 s)
* 108797.83 registers / sec
Loop Time:
* 54398.91 loops / sec (HZ)
* 171.00 us connect and 1st loop
* 17.00 us min loop
* 8852.00 us max loop
* 3 loop more that 250 us (0.0%)

---

CONCLUSION (1): The total transfer rate of 6 clients running in parallel to the same I/O Remote is equal to transfer rate of 1 client (near 200 x 6 = near 1200 x 1).

CONCLUSION (2): I will _NOT_ write a "non blocking" library in order to exploit many connections in parallel and many request at the same time because the total transfer rate will _NOT_ improve (constrained by device response).

CONCLUSION (3): The hal should run in user-space, cannot be a real time component, because there is not fast enough.

Dear VNR
referred to your point 1 :
In Modbus TCP/IP a node/slave is a server (in the meaning that it own the registers or coils or inputs to be read or write) that is why you have the same transfer rate .
In Modbus TCP/IP different nodes/slaves have different IP address .
So if you will try to communicate with different slaves you should have a different transfer rate.

referred to your point 2 :
It is true that the transfer rate to a slave is related to the slave itself (I mean how fast the slave react to a Modbus Read or Write Instance).
If you try to send an Instance (Read or Write) you should not send another Instance untill you get an answer from the slave
or a communication timeout elapse .

related to your point 3 :
As I understood the Modbus communication (used by ClassicLadder) is a user space component .

bigalex