BRX TCP com

[mhw]

I have a BRX that I am using the internal Ethernet port to do TCP reads and writes to 5 devices. Each of the 5 devices is configured as individual TCP clients in DMD. I have  each MRX/MWX in a separate stage. It will jump do the next MRX/MWX upon success or fail of the previous MRX/MWX. All works will until one of the devices goes off line. It will time out and continue for about 5 or 6 cycles through the program. After this it will hang in the offline stage for about 15 seconds. I can put a brute force timer in the stage to kick it to the next after 50ms and it will work. Shouldn't it work with the timeout settings in the device configuration?

[BobO]

Is there a reason to sequence the MRX/MWX instructions? Since each is its own client, they can actually run concurrently. The MRX/MWX instructions have internal timing, so unless there is a reason to sequence them, I would just set the interval you want in each and turn them all on and let them run at once.

As for the timeout, it's hard to say what is going on, but TCP link layer timeouts are quite long...long being like 30 second or more.

[Garyhlucas]

I had NO idea they could all run at once!  That would hugely simplify the code I have talking to 8 VFDs with about 4 reads and 3 writes to each one.

[BobO]

I had NO idea they could all run at once!  That would hugely simplify the code I have talking to 8 VFDs with about 4 reads and 3 writes to each one.

To clarify, each client device can run simultaneously. If you have more than one instruction on a single client, they will automatically round-robin. Unless you specifically need to sequence them, just turn the instructions on and let them run.

[mhw]

Is there a reason to sequence the MRX/MWX instructions?

Apparently not. I changed it today and it works great.
What about DLX/DWX instructions using the internal Ethernet. Can/should these be setup the same way?

[BobO]

Is there a reason to sequence the MRX/MWX instructions?

Apparently not. I changed it today and it works great.

In most cases there isn't. If you don't know why you need to, you probably don't.

What about DLX/DWX instructions using the internal Ethernet. Can/should these be setup the same way?

Yes. Although they are UDP and there are fewer issues.


Stage is the absolute best way to sequence things...when sequencing is required. We made MRX/MWX/DLRX/DLWX/RX/WX work with no external sequencing required...turn them on and let them go. The only consideration in that group is for MRX/MWX; you probably should use one client per target device.

[mhw]

I want to make sure we are on the same page on how to create the most robust communications.
1. Create a separate "UDP connection" device for each DL PLC.
2. Sequence MRX/MWX to the same device.
3. No sequence for MRX/MWX to separate devices.

Do I need to throttle coms to D0-ECOM100 to prevent it from being overloaded?

[Controls Guy]

I don't think you even need to sequence comms to the same device (BobO?)

I think just the order of the boxes in ladder will automagically cause them to round robin, so if that's what you want, just turn them on and let er rip!

[BobO]

I've got you confused...

1. MRX and MWX use TCP, which is like making a phone call. You want to use a Modbus TCP Client device for each target device to prevent the driver from calling, exchanging data, hanging up, etc. It's very inefficient. If you use a client per, it calls and holds the line open for as long as you keep exchanging data. Much faster.

2. DLWX, DLWX, RX, and WX use UDP. The single internal Ethernet device is all you ever need to use.

3. Sequencing is *never* required to make any Do-more MRX, MWX, DLRX, DLWX, RX, or WX instruction work. They are internally interlocked...it isn't possible to mess them up.

4. The only reason you would ever want to externally sequence is if the order of instruction execution was significant to the process, i.e., if the data you were writing was order dependent.

5. You can't overload the D0-ECOM100 unless you are hitting with with many different masters. All xRX/xWX instructions send a single request and wait for the response. No more than one instruction per Do-more device (Internal Ethernet, Modbus TCP Client, etc) is active at a time.

[BobO]

And I should have started with: "Forget everything you know about DL comms...".

[franji1]

There is one potential "here's why you might care" about the actual sequencing, but it is more important when dealing with Modbus/RTU, not Modbus/TCP.

It is when one of the slaves typically can go OFFLINE.  Rather than create a bottle-neck dealing with timeouts/retries that affects the throughput of ALL your RTU slaves, you might want to be able to independently take each slave offline programmatically so that your ONLINE slaves can still communicate SMOOTHLY.

[mhw]

Forget everything you know about DL comms

That's not hard. I see that I asked the same question in 2015 and got many of the same answers.
What happens if a DL goes offline will it hang the rest?
I am having problems at a location where occasionally communications will stop for 3 to 10 seconds. There are 5 DL06 PLCs that I am DRX/DWX from the internal Ethernet on a H2-DM1E.

[BobO]

What happens if a DL goes offline will it hang the rest?

The instruction will block the driver until it times out. The initial ACK timeout defaults to 100ms, so it won't kill it for a long time.

As Franj mentioned, the best thing to do is to remove a failing unit until it quits failing. An easy way to do this is to use a variable for the interval time and greatly increase the interval time when you get a failure, then reduce it when it succeeds.