Please tell us what your experience has been with Do-more...

[BobO]

So from the point of view of the Do-More, will ERM100's with remote EBC's be a transparent I/O expansion like the native port, or will it still map to memory like current ERM/EBC systems?

This is an ongoing discussion. It a minimum, the ERM100 will paint native Do-more memories X, Y, WX, and WY...so no more dealing with DLX, DLY, etc. As to whether we will try to do everything with the ERM100 that we are doing with the onboard master, jury is out. Some of what we are doing might be painful due to the backplane being slower than direct access to the Ethernet port. Haven't fully explored the engineering realities, but it may simply not be feasible.

There is another aspect that we are considering though. Because we are using the same rules on the onboard master as the local base master, it isn't really conducive to more data-centric mastering. What does that mean? Some apps use remote bases for optional data acquisition and the I/O isn't really I/O in the local base sense, it's more of a remote data source that happens to use PLC I/O. I am not making any provisions for a more relaxed data-centric acquisition in the onboard master. Apps like that are easily managed by using Modbus/TCP instructions to talk to the I/O rather than using the Remote I/O master...but some folks would rather have a module handle the comm and eliminate the programming requirement. And to that end, I am somewhat inclined to leave the ERM100 like it is, just with the addition of native memory access.

It seems like a subtle point perhaps, but I have much stronger opinions about the way native I/O should work, and leaving the ERM100 working as a memory painting co-processor, while treating the onboard Ethernet master as local I/O that happens to have a cable connecting it, gives us the ability to do both. Clear as mud?

[Controls Guy]

This is an ongoing discussion. It a minimum, the ERM100 will paint native Do-more memories X, Y, WX, and WY...so no more dealing with DLX, DLY, etc. As to whether we will try to do everything with the ERM100 that we are doing with the onboard master, jury is out. Some of what we are doing might be painful due to the backplane being slower than direct access to the Ethernet port. Haven't fully explored the engineering realities, but it may simply not be feasible.

There is another aspect that we are considering though. Because we are using the same rules on the onboard master as the local base master, it isn't really conducive to more data-centric mastering. What does that mean? Some apps use remote bases for optional data acquisition and the I/O isn't really I/O in the local base sense, it's more of a remote data source that happens to use PLC I/O. I am not making any provisions for a more relaxed data-centric acquisition in the onboard master. Apps like that are easily managed by using Modbus/TCP instructions to talk to the I/O rather than using the Remote I/O master...but some folks would rather have a module handle the comm and eliminate the programming requirement. And to that end, I am somewhat inclined to leave the ERM100 like it is, just with the addition of native memory access.

It seems like a subtle point perhaps, but I have much stronger opinions about the way native I/O should work, and leaving the ERM100 working as a memory painting co-processor, while treating the onboard Ethernet master as local I/O that happens to have a cable connecting it, gives us the ability to do both. Clear as mud?

Nope.  Makes perfect sense.  With the internal overhead and interlocking, do you expect the on-board port be adequate for simultaneous remote I/O mastering and HMI slave, particularly a Modbus slave?  It shouldn't be a problem bandwidth-wise, but what about indirect bandwidth limitations due to a max number of transactions per scan?  (Course blinding fast scans tend to make that issue go away too!) 

[BobO]

Nope.  Makes perfect sense.  With the internal overhead and interlocking, do you expect the on-board port be adequate for simultaneous remote I/O mastering and HMI slave, particularly a Modbus slave?  It shouldn't be a problem bandwidth-wise, but what about indirect bandwidth limitations due to a max number of transactions per scan?  (Course blinding fast scans tend to make that issue go away too!) 

I was initially afraid of the implications of running both Ethernet remote I/O and HMI type stuff at the same time, and strongly considered making you choose one or the other. After playing with it, while simultaneously considering how hard in practice it would be to limit it, I am inclined to leave it available with the suitable caveat emptor. The truth is that some users will mess it up no matter how hard I try to prevent it, and the sharp ones that listen, understand, evaluate, and then make their own call, can easily determine whether the system is practical. So, the official line will be that if you use it for I/O, and the I/O performance is critical, then please put the I/O on an isolated network and don't use the Ethernet port for anything else. If you can tolerate a little more flexibility in I/O data delivery, bump up the retries and have at it. The default is 4 retries and 100ms timeout.

I've had the Ethernet remote master on the simulator running on my PC on the office network for several days at a time with retries but no failures. That's to two EBC100s with CTRIOs installed in both systems, one a 205 and the other Terminator. There is all manner of control killing unholiness flying around the enterprise network, so a reasonably well-limited control network should be very clean by comparison.

[Controls Guy]

Yeah, I never put processors on the main plant network.  Maybe on a multi-machine network with surrounding machines, and the HMI PC's are usually on the plant network via a second adapter, but no connection directly from the PLC network to the plant.  So yeah, much cleaner traffic-wise than your test case.

Can you do a primer in the internal mechanics of Do-More native Ethernet remote I/O, as well as a refresher on how Modbus comms are handled, particularly when the PLC is the server/slave?  So we can get some idea of potential total throughput, the impact of scan time, and we can quantify, at least roughly, when we can share between an HMI and RIO?

Could you set a polling time for the remote, like 50ms or so (I realize this is pretty close to your suggestion to set the timeout and retry values)?

Thanks!

[BobO]

I hadn't planned on putting a poll rate on the I/O, although it would be pretty easy to do. I would think that should be a standard thing in HMIs, though, given that for human interaction anything faster than about 50ms is overkill.

For planning purposes, think in terms of packets received per scan. It is completely arbitrary, but currently within one scan I'll accept 16 packets unconditionally, then the next 16 are time regulated. At 32, within a single scan, I shut off the interrupt until next scan. The time regulation I mentioned is to allow up to 16 additional packets to come in if the scan is long, but not to exceed a certain number of packets per unit of time. Packets that exceed that frequency are tossed on the floor. The whole thing sounds rather Rube Goldberg, but the goal is to handle normal packet traffic, but block out packet storms...malicious or otherwise. It works quite well.

I'd think you'd have to be pretty hard on the system for 32 inbound packets per scan to be a meaningful limitation. Of course that will affect the scan time accordingly, but fast enough is, well, fast enough. It's impossible for me to know what is fast enough for your app...so I won't pass judgement.

With most industrial protocols, it's a packet out and a packet back. TCP introduces a wrinkle in that the are additional acknowledgments at the TCP level that have nothing to do with the actual protocol...definitely not as efficient as UDP. I still think that for reasonable systems, neither bandwidth nor packet counts should be a problem. Somebody will break it though...there are folks that could break an anvil.

[Controls Guy]

So define "packet" --

Would one Modbus write with 250 or so bytes be a packet?

How do RIO comms resolve to packets?

[BobO]

A packet is the basic unit of Ethernet communications...a data frame. I believe the maximum size of a standard Ethernet packet is 1536 bytes, and normally the minimum is 64. Virtually everything that happens in Host's world happens with a single sent and received packet. A single remote I/O transaction is one outbound packet containing the output state to be written, and an ack/response with the input state just read. A Modbus comm is generally one and out back, although as I suggested previously the TCP layer will sometimes throw other junk in there. I'm not a fan of TCP. Modbus/UDP would have made far better sense, but the fine fellows at Modicon thought otherwise. We used to debate it at trade shows back when Ethernet on the factory floor was just us crazies, but they were Modicon and I was (and remain) nobody.

[Controls Guy]

So logistically you can do 16-32 bidirectional transactions per scan, where one transaction could be a Modbus request and response or one cycle of data exchange with one remote rack?

IOW, available bandwidth will be the limiting factor so long as you don't exceed 16-32 round trip transactions per scan??

If so, the app that can overwhelm that will be pretty intense indeed.

How about programming comms?  What kind of bandwidth does that usually take, and how many packets per second would be typical for a programming session with status?

And now....for something completely different....do you happen to know if Sixnet is planning to do any switches with more than one fiber port, IOW a fiber switch?  All ADC offers are media converters (one copper <--> one fiber) or copper switches with a single fiber port.  That doesn't work well if all your I/O is far enough apart to want fiber to all the racks, or if you have racks in clusters that can be done in copper, because if you have more than one remote rack or cluster, you'll still need a ring or star in fiber for the long runs.

[BobO]

So you can do 16 bidirectional transactions per scan logistically, where one transaction could be a Modbus request and response or one cycle of data exchange with one remote rack?

Actually it's up to 32. It's just that after the first 16, I start pacing them to prevent packet storms killing my logic. Of course reality is that stuff is generally slow enough that a single remote I/O cycle (per slave) is an outbound packet and the result is a couple of milliseconds out. For planning purposes you would treat it the way you are doing, but things really don't happen so tight as to be a problem.

How about programming comms?  What kind of bandwidth does that usually take, and how many packets per second would be typical for a programming session with status?

DmD is half-duplex. One comm per programming session at a time. A hundred per second would be pushing it.

And now....for something completely different....do you happen to know if Sixnet is planning to do any switches with more than one fiber port, IOW a fiber switch?  All ADC offers are media converters (one copper <--> one fiber) or copper switches with a single fiber port.  That doesn't work well if all your I/O is far enough apart to want fiber to all the racks, or if you have racks in clusters that can be done in copper, because if you have more than one remote rack or cluster, you'll still need a ring or star in fiber for the long runs.

No clue.

[Controls Guy]

Cool, that sounds like in most cases you can do both and not worry about it.

On the switches, yes Sixnet does have ones with two fiber ports, even in the same family (light duty industrial) ADC sells as Stride, but those particular ones aren't in ADC's lineup (yet).

[BobO]

I guess it is appropriate to this topic...Host won a Control Engineering 2013 Engineers' Choice Award for Do-more! Thank you to everyone who voted for us!

Here's the link for anyone interested: http://www.controleng.com/events-and-awards/engineers-choice-awards/2013/winners.html

[ccherry]

I have several of them out at this point and besides the learning curve all are performing well. Points to consider:
extensive use of tasks in my programming structure causes Comm fault when I view "all status"
(won't ever click that one again as the software locked up every time)

I must be a little harsh...why 232 port and not a 485? This puts the Do-More really behind. I don't want to stock one more interface module. Poll Question: Ask the users how many times they use the 232 port...probably 0. We can't even to a GS3 VFD without an adapter which takes up space.

Do-More to C-More Micro is extremely painful because the Timer Variables are in ms and not selectable like in a Click.

with that said, it is a great plc....Bonus BCD is dead!

[BobO]

I have several of them out at this point and besides the learning curve all are performing well. Points to consider:
extensive use of tasks in my programming structure causes Comm fault when I view "all status"
(won't ever click that one again as the software locked up every time)

I must be a little harsh...why 232 port and not a 485? This puts the Do-More really behind. I don't want to stock one more interface module. Poll Question: Ask the users how many times they use the 232 port...probably 0. We can't even to a GS3 VFD without an adapter which takes up space.

Do-More to C-More Micro is extremely painful because the Timer Variables are in ms and not selectable like in a Click.

with that said, it is a great plc....Bonus BCD is dead!

If you have a program causing status issues, we would really love to have a copy so we can fix it. That shouldn't be happening...at all. If you are willing, please PM me.

As for the 232 vs 485, at no time has ADC ever suggested that 485 should have been preferred over 232. If there is sufficient market demand for it, we are happy to build it.

[Controls Guy]

As for the 232 vs 485, at no time has ADC ever suggested that 485 should have been preferred over 232. If there is sufficient market demand for it, we are happy to build it.

Historically, 232 would have been semi-preferred for a programming port over 485, but I think anymore most people will program via Ethernet or USB, and even for serial, nobody has 232 ports anymore anyways, so they're going to need a USB-232 converter, and those are just as readily available and just as cheap in USB-485.

Where the 485 would be missed is in multidrop Modbus mastering.  I talk to drives a lot via 485 Modbus and will miss it if I don't have it.  But yeah, we can easily convert to 485 outside the PLC, and there's so many other improvements vs. the Koyo product that this is hardly more than an annoyance.

[BobO]

Do-More to C-More Micro is extremely painful because the Timer Variables are in ms and not selectable like in a Click.

Is it my understanding that ADC just released Do-more support for C-more Micro. I think it should be much easier now.