Dual mode ECOM-100 use

[Controls Guy]

Is it feasible to use the same ECOM-100 both as a Modbus server (slave) for MMI purposes and in a peer-to-peer role exchanging a small amount of data with another ECOM-100-equipped PLC (via Modbus TCP or ECRX/WX)?  How would the two types of transactions be coordinated?  Would it be better to have the same PLC be slave to the other PLC and to the MMI or have the MMI slave PLC initiate the comms with the other PLC?  Would Modbus or ECRX/WX be preferred for the PLC-PLC comms?

[franji1]

Based off your statement, the MMI is definitely POLLING the ECOM100 as fast as possible (typical behavior for a responsive MMI, unless you like running Windows on a 486 processor).  Also, MMI's are typicaly READ operations, with "event based" write operations (i.e. user hitting a button or a timed event occurs)

However, is the peer-to-peer POLLING or is it event-based?  Also, is it mostly READ operations, mostly WRITE operations, or a close to 50/50 mixture of READ and WRITE?

WRITE operations require 1 backplane operation, while READ operations require 2 backplane operations (you see where this is going).  Yes, time on the wire does affect the overall throughput, but it will be primarily be based on
1. The frequency of READ operations
2. The frequency of WRITE operations
3. The local PLC scan time
4. The remote peer's PLC scan time
5. The protocol (Modbus vs. ECOM HEI protocol)
6. Time on the wire (10-baseT vs. 100-baseT)

[franji1]

Oh, I forgot to mention this one interesting caveat.  We learned this when we developed DS-Data DDE/OPC Server (actually when we developed the old DS-DDE Server).  If your MMI just QUEUES WRITE operations behind ALL OF THE RECURRENT READ OPERATIONS, the Write operations will take a LONG TIME to "complete".

Since most clients of DS-Data (like MMIs) are performing BACKGROUND READ operations, with intermittent event-based WRITE operations, DS-Data ACTIVELY places ALL WRITE operations to the HEAD of the queue.

So if your MMI is not smart in pre-empting its background COMM with intermittent WRITE operations, the OVERALL WRITE operations will be a LONG time (as in SECONDS long, depending upon the MMI screens and any ALARM pages).

[Controls Guy]

Don't know enough about the peer-to-peer portion of the app to say yet if it would be polled or event-driven.

Basic system architecture is that there are two related systems, which can operate independently but can benefit from information from the other machine if available.  So probably fairly low bandwidth on the peer-to-peer part, and I'd assume roughly equal numbers of reads and writes regardless of which PLC is initiating.  If substantially more information is going one way than the other, I would have no problem making the "publisher" initiate the peer-to-peer comms (to optimize write/read ratio), as long as it doesn't cause a problem with the MMI comms.  Would it be feasible to do writes ONLY, from both PLC's simultaneously?

Same story on the protocol.  I can use whatever would work the best for the peer-to-peer, but would prefer Modbus for consistency with the MMI.

All PLC scan times should be fairly low, say 10ms.

Everything on the wire should be 100-baseT compatible, so I assume 100Mb.

Another unknown is if the second system has an MMI.  If so, the which PLC to initiate from issue is changed.

[Controls Guy]

So if your MMI is not smart in pre-empting its background COMM with intermittent WRITE operations, the OVERALL WRITE operations will be a LONG time (as in SECONDS long, depending upon the MMI screens and any ALARM pages).

Yes, the MMI polls the reads and writes are event-driven.  I don't think it inherently prioritizes writes over reads.  However, our bandwidth requirements are such that even a full round of reads takes well under a second, so even if the writes are queued after everything already scheduled, there's no noticeable delay on the writes.  If it became a problem, there are a lot of settings to customize read scheduling, so I can probably force it to prioritize writes by making the read queue shallower.

One of the machines is pretty much the same machine we've built a number of times, and like I said, we have bandwidth to spare, so I could slow down the reads a little to make sure there's time for the peer comms without noticeably degrading the MMI.

[franji1]

From a "responsive system" standpoint, it's best if the number of "masters" is limited (1 is best) and the requests or writes of single data block is "event driven" vs. "as fast as possible".  That is to say, worst case is to have N nodes polling every node for random accessed data as fast as possible.  The more your network topology (physical and logical) can be like the former, the better.  The more your network topology is like the latter, the worse its gonna be.  And it can get worse geometrically.

Your topology is somewhere in the middle, but definitely on the "better" side vs. the "chaotic" side.  However, if you are trying to read non-contiguous data using 100 different requests for a complete "data cycle", then it can get bogged down.

[Controls Guy]

What is the effect of protocol selection and why?

[franji1]

Protocol doesn't mean anything to an ECOM100 as a Server.  It can handle multiple requests of multiple protocols simultaneously.  As a Client, it is usually talking to a specific IP address which understands the specific application layer protocol (e.g. Modbus/TCP vs. DirectNET vs. K-Sequence).  For ECOM100 to ECOM100, peer-to-peer standpoint, it uses a "directed broadcast", and so the receiving ECOM100 knows if the packet is meant for it.

[Controls Guy]

You're confusing your customer.....you listed Modbus vs. Ecom HEI as one of the parameters that would factor into the answer to the original question.  I realize all the protocols work.  Do they have an impact on the issue or not?

[franji1]

It was 5th on the list.  Packet sizes, bit level read/write capabilities can affect the comm.  For example, you cannot do a bit level "write" using DirectNET.  So you have to do a "read/modify/write" implementation from the client side, if you want to do bit level writes with DirectNET.  However, if you write 8 bits on BYTE boundaries, DirectNET is fine.

[Controls Guy]

OK, got it, thanks.