Hi
IN Modbus RTU connection on a single Rs485 bus, there are cases, that master have to poll each device in with some delay in sequence. The delay is important because some times the slave devices need some time to empty their buffer before can get another packet request. As I test ignition Modbus RTU driver I see that it try to poll every device register without any delay. Even I put scan rate to 10s it doesn’t matter the driver try to poll every thing in every 10 s as soon as possible.
I don’t know if this driver have any option to put some delay between polls.
Is there any workaround?
1 Like
Use a Modbus TCP gateway that has this option or use Kepware.
Ok I have questions. How modbus RTU driver create queue for different define device ID? For example if I define 3 devices for ID 1, 3 and 8, in which order they will be polled?
If I know this I can create dummy device with enough timeout between each two consequence device so add some delay.
For example if the order is 1 -> 3 -> 8.
I can create 2, 4 as dummy device and each time driver poll those ID it has to wait for the timeout.
1 -> 2 (wait time out) -> 3 -> 4(wait timeout) -> 8
If you're talking about creating 3 separate devices in Ignition; you can't. Only one will be able to open the serial port.
If you're talking about 1 device where you've addressed tags on multiple slave/unit IDs, e.g. 1.HR1, 2.HR1, 3.HR1, then there is no defined order, it is basically non-deterministic.
Could you create the tags, set them to be not polled at all, and then use scripting and system.opc.read/write functions to manually handle the refreshing of the tags and writing new data?
Also, would subscribe vs read mode on the scan class affect the timing? Wasn’t sure if subscribe would spread the traffic out a little more evenly. Still no guarantee that it would wait between reads though.
1 Like
Unfortunately I notice today that driver issue all poll request at the same time for all IDs in the bus. So every device try to answer the request base on their ID and we have collisions detection on the RS485 bus. It seems the one who write the driver think it works as TCP connection and doesn’t care about serial limitation.
I hope IA fix this issue unless the driver is totally useless in serial mode.
Using system.opc.read is fix the problem and it’s good for small tag count but it ruin rapid development concept here. Even using external modbus TCP TO SERIAL doesn’t solve the problem here.
Can you offer some proof or logs that show this happening? It should only send one request at a time.
Sure tommorow I will.
I use 8.0.12.
No, that is an option on the Modbus TCP driver that allows you to configure more than 1 concurrent request allowed.
Until that release all versions of the driver have only allowed 1 request at a time. I’ve never seen any report that it behaves otherwise.
Are you not specifying the unit numbers? If you leave the unit off in the OPC item, it defaults to zero I believe, which is the broadcast address. On a real serial line, that will cause all slaves to respond. The broadcast address should only be used with fire-and-forget write operations.
(FWIW, I think I will implement this delay on the client side of my coming combined Client & Server Modbus driver. Should be ready by end of the year. I’ll make an announcement soon for beta testers.)
Hi Paul
Yes I use unit number for different device on the same serial port on RS485 BUS.
This is standard method to access several device on a share media.
I’m not using zero ID. The problem with deriver is it send all poll request at the same time and doesn’t queue them. This problem only happens for serial and not TCP so your client server driver doesn’t help me.
You aren’t trying to use different device names pointing at the same serial port, are you?
No same device name connection. only differentiate devices with ID.
[meter]1.HR102
[meter]2.HR102
[meter]3.HR102
[meter]4.HR102
I recommend using a communications tool such as Kepware (or any other) like Mr. Herron suggested.
Best of luck!
It’s not possible for linux system and also it add cost to projects.
So the best option using system.opc as Brain suggest.
Did you try to create a “driven scanclass” to read each tag one after the other?
I’m just brainstorming… But RTU is like a telephone line.
The first command must be completed before issuing the second.
[meter]1.HR102 - Read
[meter]1.HR102 - Done drive [meter]2.HR102 - Read
[meter]2.HR102 - Done drive [meter]3.HR102 - Read
[meter]3.HR102 - Done drive [meter]4.HR102 - Read
[meter]4.HR102 - Done drive [meter]1.HR102 - Read
Could you be more specific how to do that with driven scan class for 600 tag across 10 device?
Memory Tag with value change every X sec 1 to 10…
Scan Class = Value 1 Trig ALL [meter]1.HR102
Wait
Scan Class = Value 2 Trig ALL [meter]2.HR102
Probably the Modbus TCP to Modbus RTU adapter do this automatically
1 Like
Beta announcement for my new Modbus module. It implements this inter-request delay in its Client driver type:
1 Like