Bandwidth and playing nice in a multi-use application

[Controls Guy]

I have an application where a 260 with an ECOM is a Modbus/TCP slave to an MMI, with the same port being used for commissioning and troubleshooting with DirectSoft, and on this particular unit, we will also be talking to 1 or 2 scales that can do Modbus/TCP as slaves.  The MMI hits about four times a second and collects a couple hundred words, plus the occasional small transaction for a button press or setpoint change.  I could probably slow the MMI down a little.  Is it feasible to do all this with one ECOM or should I use a second one?  And how does bandwidth work again with more than one ECOM in the rack?    The scale feedback is controlling the addition of recipe components, so I don't want a lot of latency, or I'll overshoot.  I'm leaning towards a second ECOM, but then I'm out of open slots and should probably add another base, so if I'm pretty sure it would work, I'd just as soon not.

[BobO]

PLC scantime will greatly affect the answer. We can do as many as three simple memory accesses per scan. The large number of words might take two accesses to get them all.

Adding a second ECOM slows down the PLC a bit, but doubles the number of transactions per scan.

No faster than you are needing data for the MMI, I'd say you will be fine...but...I don't want you mad at me if it isn't fast enough.

[Controls Guy]

For this app, I'd expect 15-20ms range on scantime at worst, and I might be able to time slice some of it as well.

One aspect I'm concerned about is mixing PLC master transactions (to the scale(s)) with slave transactions (from the MMI master).  How does one go about coordinating and optimizing that?

[franji1]

Optimize based on necessary latency.  Make the "fast as possible" be that.  Make the things that can be "as slow as possible" do that.  The more "as slow as possible" you have, the faster your "fast as possible" will be.

If EVERYTHING is "fast as possible" - it won't be (finite resources).

I used to work for a company that designed multi-sample medical diagnostic equipment.  One of the operating mode flags for a specific sample was "stat" - i.e. run this patient's set of tests ASAP, and it would put it at the front of the queue.  However, EVERY doctor would flag EVERY test as STAT, because, of course, their patients are more important than every other doctor's patients.  So guess what happens - they all run at the same priority as if NONE of the tests were STAT.   

[Controls Guy]

That still doesn't address the question of mixed master and slave transactions, which is what I've been trying to get at.  The PLC can't proactively prioritize transactions it's not scheduling, so what control if any can the PLC exert in this situation?  And further, what are the architectural features of an ECOM with DL CPU that allow master and slave transactions to coexist on the same port at all, when you don't (or if you can't) do anything explicit in the PLC?  (Buffers, etc.)

[franji1]

The ECOM has no control over what a remote master is doing, but I assume that you do.  The backplane transactions are still scan synchronous (done at the bottom of the ladder scan), and the 260 can do 1, 2, or 3 incoming transactions per scan, based on the type of transaction.

The outgoing transactions initiated by the 260 can only handle 1 pending outgoing transaction at a time.  These transactions have no affect on the mechanism of the incoming transactions, only from the standpoint of the response buffer (i.e. collisions, but highly unlikely on a non-saturated network, but the chip has built-in collision handling).

Hence, I would make your masters poll at a "just fast enough" rate.  If they are event based, then that will probably work out best for the ECOM.  However, if the events occur at the rate of about once a millisecond, you'll probably end up losing some packets, let alone respond fast enough.

[BobO]

As Mark said, the incoming and outgoing mechanisms are different. As many as three per scan incoming, and one pending outgoing. Is that enough comm? Can't answer that. The 15ms to 20ms scan time is probably the biggest influence on the outcome, and won't be tremendously helpful.

[Controls Guy]

The ECOM has no control over what a remote master is doing, but I assume that you do.

Yes and no.  I can slow down the acquisition rate (probably), but I'm in the same boat as the PLC in the sense that I can't coordinate events, some of which I don't know about.

These transactions have no affect on the mechanism of the incoming transactions, only from the standpoint of the response buffer (i.e. collisions, but highly unlikely on a non-saturated network, but the chip has built-in collision handling).

That's what I'm concerned about.  By "collision" do you mean literally, with bytes coming over the wire simultaneously, or does the term also include the more general sense of transactions overlapping, with receptions entering the buffer out of order?  I've seen from the MMI's point of view a delay of 50 ms or so between a request and its response.  If that's typical, I could easily see a case where an MMI master request arrives between a request by the PLC to one of the scales, and the corresponding response.

Does the PLC have the ability to look ahead down the buffer and rescue a response that has been cut in front of by another reception, or just request the next response be spit out of the buffer, processed and discarded?  If it has to do them strictly FIFO, can it process the MMI request, and then get the next transmission out of the buffer, which is the scale response, and still be able to process that without crashing the ECxX?

[Controls Guy]

As Mark said, the incoming and outgoing mechanisms are different. As many as three per scan incoming, and one pending outgoing. Is that enough comm? Can't answer that. The 15ms to 20ms scan time is probably the biggest influence on the outcome, and won't be tremendously helpful.

So if I'm understanding you, incoming and outgoing aren't capable of getting in each others way, other than with an (unlikely) outright bytes-on-the-wire collision, which seems like a rare and recoverable event.  Is that correct?  Do most switches have a buffer per port so they can store and forward, if they get two transmissions for the same recipient at the same time?

As far as the scan time, that's just a guess, may be conservative, and may be able to be managed by allocating tasks to be done over more than one scan.

And if you can handle at least one incoming and one outgoing transaction per scan (or even one or the other per scan) that should be plenty of bandwidth for the amount of information.  I was mostly worried about management issues and the possibility of bring the bandwidth effectively to almost nil.  If that can't happen, I'm not too worried.

[franji1]

From a physical layer sense.  50ms is a long time in Ethernet speak, so that isn't an issue.  If you have a video camera broadcasting data constantly on the same network, that will definitely saturate your network.

There is a physical queue, but these are fast, and I think interrupt driven in the ECOM modules.  The 260 master requests get processed in a different area of backplane "shared RAM", so the 260's request's responses will not get "hung up" based off the remote requests.

As long as you don't have BROADCASTS occuring CONTINUOUSLY (e.g. some security cameras), or just a A SUPER FAST Modbus Client, you should be okay.  Funny, I think DirectSOFT will be your "fastest" client (it tries to read things as fast as possible).  Modbus/TCP has built-in error detection/handling with retries, so your HMI should be okay, but check its error log to see if you lose any packets when DirectSOFT is doing ladder or data view status.

[Controls Guy]

No, no "streaming" content.  Just the cyclic requests from the MMI, event driven MMI stuff (writes from buttons or setpoint changes, these write on change-of-state only), DirectSoft, and cyclic requests to the scales.  I haven't seen the scales' memory map but I can't imagine it's more than 20 words or so, so a fairly small transaction, and several times a second is probably sufficient to avoid overshooting when mixing the batch.

Sounds good.  I'd rather not add another rack if I don't have to.

Oh, and we've done the same MMI with DirectSoft over the same ECOM in the past, so I know we have enough gas for those two.  The scales (and attendant issue of mixed master/slave) are the only new wild card added to the mix.

[franji1]

Yes, as much as we like selling hardware, we really want to help customers solve their problems - I think you should have no problems with your current setup (one ECOM100 module).

There's one customer out there that carries an ECOM module with his laptop, and he just plugs in the ECOM module to his 205 base as a designated port for his DirectSOFT debugging sessions.   

[Controls Guy]

Two actually, unless you were talking about me.   

[franji1]

It's YOU!  Ha!  That's funny!  It's a small world (queue the children)...

[Controls Guy]

We ended up going with two ECOM-100's, one slave for MMI and programming, and one master polling the scales.  Thing goes like a bat out of hell.  Thanks!