ECOM-100 Communication Speed

[johneguinn]

I have some general questions regarding communication speed to the ECOM-100 modules.
1. Communication speed seems to be dependent on PLC Scan time. Is there a way to mitigate this? I have tried to manipulate the scan time variables but this only seems to make matters worse. I have broken up some of the bigger calculations and distributed them over several scans and this helps, but it is a bit of a kluge. (scan times over 45ms seem to be a killer)
2. We are using a modbus driver (vb.net) to communicate to a 250-1 CPU and DL06 CPU in several applications. Our communication speed is far less than we would expect, but perhaps our expectations are too high. 100Mbps equates to 6.25x10^6 16bit Words per second, and our speed is several orders of magnitude below that. Do you have any tips on improving communication rates using the ECOM-100 modules as far as hardware?
3. Currently I am polling my PLC variable blocks in a sequential series of transactions. Will there be an performance improvements if I execute multiple reads simultaneously? I have had errors while doing this in the past, but can look into this further if there is a benefit to doing so. 
4. What should I expect as far as communication speed from the ECOM 100?
Thanks for your help to my questions.   
John

[Controls Guy]

I was going to suggest time slicing your work to minimize scan time but I see you're already doing that.  In most applications it can be done without being too kludgey, but I don't know what you're doing.

Ethernet includes some overhead, so theoretical rates can never be achieved on the wire.

The ECOM has a finite delay (on the order of 20 or 30 ms IIRC) after receipt of a request before it responds.

Modbus also has overhead, which will reduce your throughput of data, although I imagine you're measuring bytes on the wire in citing your performance, which would include the overhead.  The main reason I mention Modbus transaction overhead is that the overhead, both in terms of overhead bytes transmitted and in terms of response latency, is roughly constant per transaction.  Therefore, you'll get the best transfer rates, both gross and net, with the biggest requests.  Try to arrange the data accesses to large contiguous blocks.  If there are words sprinkled throughout the data area that aren't needed, transfer them anyway, so as to avoid creating more non-contiguous blocks.  Rewrite the PLC program to put the ECOM accessed variables (or proxies for them) together.  If you have some 32-bit values mixed in among 16-bit values, don't create separate transactions.  Just read them as if they're all 16-bit values and reassemble them on the PC end.

Applying all these rules, I've improved Modbus performance by over an order of magnitude, but I'm sure you're never going to get 6MM words/sec.

[franji1]

Here's some ideas, http://www.hosteng.com/FAQFiles/ECOM.htm#FAQ0014, so you might try swapping your 250-1 with a 260.

After that, the only other possibility is having multiple ECOM100 modules and dividing up the requests across all of the ECOM100 modules, since each "module" gets equal chance with the PLC backplane.

[johneguinn]

Thanks guys for the helpful responses.
I've implemented almost all of these suggestions already, with the exception of the second ECOM module.
I assume based on the below comments that polling the PLC from two different threads will give no advantage in poll rate. The reason I ask is that it seems that more devices communicating with the PLC does seem to slow communication, but it doesn't seem like a proportional decrease.

As far as the scan time minimizations, I Have a group of bits which I trigger in succession that in turn allow particular sets of calculations to be performed in succession. I say klugey as it makes the logic more complex as I have to condition my value comparisons around when a calculation is actually executed.

Is it possible to force the PLC to scan less frequently leaving more time for Communications? We actually could live with the PLC scanning less frequently. I have tried manually setting the scan time, but this makes matters much worse.

[franji1]

If you have 2 different ECOM modules, that WILL speed up the throughput.  Yes, if you just have one ECOM module, more comm slows it down.  But if you divide the comm between 2 or more ECOM modules, the throughput is increased.

The bottle neck is the PLC Scan, not just the PLC scan TIME.  The overhead to the Scan TIME by the ECOM module is minimal.  However, if the PLC can process MORE REQUESTS per PLC SCAN, then you have more data flowing, with a minimal hit to the Scan TIME (compared to the full-cycle time of a comm request).

[Controls Guy]

What is your target transfer rate, and is there a specific abrupt cutoff point in throughput below which the app is markedly less valuable or is more just better?

[johneguinn]

I don't have a specific Target Transfer Rate. I am trying to maintain 1 second poll rate on variables that I need as our data is logged at that rate, and we are also using the data in trends. Poll rates above 1 second are noticeable in the data as our values are continuously changing. Currently I am polling all my reads to update a database continuously as this simplifies my programming. If I can't improve my communication rate, then I will need to add some smarts to my PLC updating to make the polling more efficient, and not 'always on'. Synchronous queries are not a viable option as the response time is slow, and my GUI doesn't like to wait... So, in short, I'm trying to keep my software simple, my perpetual unfulfilled dream.

To franji1, Is there a way to force the PLC to process more Requests? 2 ECOM modules is not an option as our rack is full, and cost of course.

[franji1]

Other than upgrading your 250-1 to a 260.  The 06 and the 260 have the "best" execution times for fast comm, as compared to a 250-1 or an 05.

The backplane is handled by the firmware in the PLC CPU.  The ECOM100 module is basically the slave to the PLC CPU Master.  When the PLC CPU says it's okay to xfer data, the ECOM100 module transfers any requests across the backplane.

[Controls Guy]

I don't have a specific Target Transfer Rate. I am trying to maintain 1 second poll rate on variables that I need as our data is logged at that rate, and we are also using the data in trends. Poll rates above 1 second are noticeable in the data as our values are continuously changing

Well, that figures to a target rate.  1 second updates certainly aren't unreasonable.  How many words are you reading?  I've read 500-1000 words in 20-25 transactions per second with occasional bit and word writes thrown in.  Are you transferring more variables than that?

[johneguinn]

Yes, that is a target transfer rate isn't it. I'm just getting started, but my current update rate is 300ms with 3 blocks with some overhead in my app. I guess it's not as bad as I thought. I'm currently using the DL06 though. I will be using the same app on a 205-1 with twice the scan time, that is where I have mainly had the problem with my other applications. I will see about going to the 260 there as this seems to be a huge improvement.
Thanks,
John

[Controls Guy]

I actually think there's things you could do which from your point of view would be indistinguishable from "forcing the PLC to handle more requests."  Rather than controlling the execution of just the calculations in a time-slicing fashion, you could do it to the whole ladder.  In other words, lets say you have a ladder program of 1000 rungs.  Create an execution control pointer that recycles from 1-10 then resets to 1.  If the value is 1, execute the first 100 rungs and skip to the end of ladder, incrementing the value to 2.  Next scan, execute the second 100 rungs and skip to the end, and so on.  That way, you're getting 10 times the "scans" in a little more time than one scan now, but the rungs all execute in the originally designed order, so you don't need to do any tricky logic to adjust for the results of some calculations being fresher than others (unless you mean physical time as opposed to scan order).  You could also scan the entire ladder, and follow with 10 null scans of just the END rung.  Or a little cleaner might be to break the program into 10 subroutines of 100 rungs each and then the execution control logic is separate from the working ladder.

Or is it that you're worried about the values being returned by the ECOM being asynchronous to the scan?  If so, use the scan once and 10 null scans method.

You also need to think about if the I/O updating 10 times a "scan" will give you problems (X0 was false for 100 rungs, then true for 200 rungs, then false again...).  If it would be a problem, you can either copy the I/O to a proxy range once per metascan, or again, do the 1-real-and-10-virtual scan thing.

The more I think about this and your objectives, the more I think you'd be happiest with the 1-and-10 approach.  IOW, only execute the logic every nth scan.  Every other scan, jump directly to the end rung.  That method, beside keeping you from having to break the program into chunks, allows you to fine tune the comms-vs-logic time slices at runtime from the MMI.  Don't like your throughput, up the null-scan counter setpoint!

Using that approach, you don't have to worry about any problems with mid-scan changes in I/O, mid-scan ECOM transactions, and the calculations are all performed in the normal scan order and at the same clock time.

[johneguinn]

Great input, thanks.
I agree with you on the simplicity of the Null Scan approach, it definitely covers a lot of my concerns.

Here is a question though:  Is there a cutoff of scan time below which no more communication is done? Does a 2ms scan give more communication than say a pretty fast scan of 20ms?

We actually did somewhat of a null scan approach before, but just not executing the big calculations, limiting them to once every 500ms which definitely improved peak response time. This gave us a big performance hit on our embedded touchscreens though, giving inconsistent responses depending on if we opened a new screen on that computation heavy scan or not. (note: the thread discussion is based on my work on a PC based application that remotely connects to our PLC which is also locally interfaced with an embedded touchscreen) Breaking up the computation into smaller sections seemed to give more consistent results with our embedded touchscreen, while having a lower peak response time at the screen. This seemed to be more user friendly. What I am thinking of doing though is a hybrid of your two approaches, running my series of 'ladder chunks' then run null scans based on a timer or scan counter.

[Controls Guy]

Here is a question though:  Is there a cutoff of scan time below which no more communication is done? Does a 2ms scan give more communication than say a pretty fast scan of 20ms?

I don't know.  I was wondering that myself.  If the ECOM takes 25 ms minimum to do a transaction, then the PLC being free to talk to it every 5ms isn't going to speed things up.  You'd have to play with it, optimizing the outside part of the network for speed, and just see what the ECOM's minimum transaction time is.  Then your scan time target is to be less than that.

I see what you mean about just doing one full non-null scan every so often hamstringing your other comms.  You may be forced to split the computations and just live with the necessity of having the logic to compensate for the phase shift in the computations.

How long do the computations take for one full pass?  What aspect of latency creates a problem that must be solved with the other logic?  Scan order issues or absolute time elapsed between part of the calculation?

[franji1]

You're starting to tread into the "twilight zone".

What happens if timer instructions don't execute, do they still time?  What happens to drums timers?  What happens to RX/WX instructions that hang for multiple scans (those are probably okay), but are their SP busy bits still maintained across multiple scans?  RD/WT?  MRX/MWX?

If you use ANY of these instructions (or similiar ones), you'll have to play around with them to validate their behavior if they only execute every 5 or 10 PLC scans.

Edge triggered instruction behavior (counters, PD, reset legs on timers).

[Controls Guy]

Timers I think should be OK.  The timer works in a conventional program with a scan time of 5ms and also one with a scan time of 50ms (aside from maybe overshooting the setpoint by 1-scan-minus-1ms).  So the timer must work either by remembering the initiation time or precalculating the expiration time and recording that, then comparing every time it gets executed.  I have apps that don't execute the timers every scan and they still work OK, aside from any overshoot issue.  Can't really say for drums but can't see offhand why it would be an issue.  Bottom line is that in general all the instructions will work with scans of varying lengths.  The only difference here is that the END instruction's been encountered a number of times in the interim.

I could see one-shots acting in an unexpected manner, or not at all, but that shouldn't be too hard to work around.