Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: ATU on November 16, 2018, 09:21:46 AM
-
If you have 2 devices that you want to communicate with constantly, one has a higher priority over the other. If you create another TCP/IP Device and put them in separate tasks will I get more throughput than if I did them sequentially in one task? Would the Modbus transaction still happen sequentially anyway ? Would the lower priority transaction interfere with the higher priority com? Would it be better to install an Ethernet POM and run the lower priority com through that port?
-
It's generally better to create two devices, yes. If one goes into timeout the other can keep on without interruption. More throughput is harder to answer, but generally the answer is yes to that as well. Throughput depends on how hard you are slamming the port with traffic from both directions.
You could install a POM, but that is something you would have to decide if it is worth the extra cost.
-
Thanks, that helps.
-
To restate what has already been said: 1) Multiple Modbus/TCP client devices run transactions concurrently, and 2) the majority of your time is spent waiting for the remote device to answer, so concurrent comms with more than one device will usually increase throughput.
If you are running a single device, then it is round robin and the current comm will block all others.
-
What is the maximum number of devices that can be run concurrently?
-
What is the maximum number of devices that can be run concurrently?
Modbus? No real limit other than available memory. How many do you need?
-
I only need 2 for this application, maybe 3. I was wondering if there was a realistic limit to the number the PLC could process concurrently. I guess limiting the data length to 125 keeps that from happening?
-
Just scan time and memory. Whether it stays efficient is kinda in the eye of the beholder.
-
This definitely works. Round robin to 4 Modbus devices was 80-100ms. Setting up Multiple Modbus/TCP client devices to run transactions concurrently in their own tasks, 25-28ms cyclical update times with almost no hit on the average CPU scan time. Running 1 device was around 15-16ms.
-
Modbus/TCP is particularly bad because the TCP connection has to be shut down and restarted for each device. Think of each device as a telephone. If I have one, I have to call, talk, and hang up for each target. If I have four, I can call on all four and keep all lines open.
-
So what's the criteria for keeping the connection open or configure when the connection is closed? Is that something that happens in background when there is no activity on the device after a certain time period? I didn't see anything in the Device Configuration.
-
So what's the criteria for keeping the connection open or configure when the connection is closed? Is that something that happens in background when there is no activity on the device after a certain time period? I didn't see anything in the Device Configuration.
Primarily a different phone number. If you are talking to just 1 slave, it will keep it open. If you have a single device talking to 2 slaves, and ping-pong between the two, it must hang up, dial the new number, talk, hang up, dial the first number, talk, hang up. Lather, rinse, repeat.
Dial ATU
Greet each other
Ask what time it is
Get the time
Hang up
Dial BobO
Greet each other
Ask what time it is
Get the time
Hang up
Dial ATU
Greet each other
Ask what time it is
Get the time
Hang up
Dial BobO
Greet each other
Ask what time it is
Get the time
Hang up
Dial ATU
Greet each other
Ask what time it is
Get the time
Hang up
?
versus
two phones
| Phone 1 | Phone 2 |
| Dial ATU | Dial BobO |
| Greet each other | Greet each other |
| Ask what time it is | Ask what time it is |
| Get the time | Get the time |
| Ask what time it is | Ask what time it is |
| Get the time | Get the time |
| Ask what time it is | Ask what time it is |
| Get the time | Get the time |
| Ask what time it is | Ask what time it is |
| Get the time | Get the time |
| Ask what time it is | Ask what time it is |
| Get the time | Get the time |
| Ask what time it is | Ask what time it is |
| Get the time | Get the time |
| Ask what time it is | Ask what time it is |
| Get the time | Get the time |
| |
...
(maybe never hang up)
Although my table representation appears the two conversations/phones are synchronized, they won't be. If one person talks slower (e.g. it must query a Modbus/RTU device at 9600 baud because it is actually a Modbus Gateway), that pace will be slower than the other device that is an actual Modbus/TCP transaction. But, they both will be faster than if you did it with just 1 telephone (i.e. one Modbus/TCP Master/Client device).
-
Good analogy, it explains a lot of what I am seeing. Now that I know that, I can make it better.
-
So what's the criteria for keeping the connection open or configure when the connection is closed? Is that something that happens in background when there is no activity on the device after a certain time period? I didn't see anything in the Device Configuration.
It's hard-coded for clients. Don't remember right off. Guessing a minute.
You can set it for the server side.
-
I changed it so the IP does not change for each Modbus Client Device. It lowered the cycle time to 14-17 ms with an Data Aquisition time for the MRX instruction to be less than 10ms. It knocked a full ms off the average PLC scan time. I was able to lower the time slice in each Modbus Task to 50us without any effect.