Options for sub millisecond IO on a single processor.

[plcnut]

I have a project where I have a single incremental encoder that will feed into a PLC that will have 60 discreet inputs and 40 discreet outputs that all require sub millisecond control. I was happy-go-lucky to use Do-more because the processor has everything I need for the job (including the speed I need), but the response times for the IO cards are way too slow. The total discreet IO count for the system will be 160+ inputs, and 120+ outputs. All are DC (Sinking in, and sourcing out).
Does anybody have any ideas for me?

I have considered using AD's Protos IO for the project. The IO cards have really good response times. Anybody have any real-world experience with the speed between the Protos and a DM1E processor (serial or TCP)?
I also looked at using 10 CTRIO2 cards spread over a couple of EBC100 racks, but I am not sure that I can get the discreet control that I need.

One other important tidbit: The project requires the use of the on-board TCP port for TCP comms between the PLC and a PC. This limits my remote IO options. I also have a couple of EDRV100's that will be connected using a ERM100.

[BobO]

I'm pretty sure CTRIO2 raw inputs are published in the module's structure, and the outputs can be controlled raw, so that might still be an option. Can't remember what the module access overhead is, but that will also be a consideration if you fill racks with them.

Protos might be fast enough, but with Modbus/TCP you will be running at least two comm transactions to service each rack. Not sure how that will affect latency.

Sounds challenging.

[plcnut]

If I use Protos I can get all of my IO in one remote rack, with the CTRIO2 in my 205 base. Would Modbus/RTU over an H2-SERIO4 be as fast as Modbus/TCP?
It would require moving 22 Input bytes, and 20 Output bytes as fast as possible.

[Garyhlucas]

Much as I like plcs, this sounds like a task for something a bit different. Maybe a DeltaTau motion controller? They have been around forever.

[Controls Guy]

As far as you're I/O bound, you'd be better off with Ethernet/IP than Modbus.  When I was testing with a Cognex camera, response latency was like 30 microseconds.  I haven't seen better than 10-20 milliseconds for Modbus.  Now Do-More native I/O might be that fast as well, but EIP opens up quite a few more options, and it sounds as if the I/O channel response time was also a concern, so that might help.

I'm sure Do-More can do the sub 1ms scan time, especially if you have some tasks that can be time sliced over multiple scans.  I'm intrigued by BobO's idea of using the onboard CTRIO I/O for your general purpose I/O, and you know it's going to be fast.

[BobO]

The CTRIO2s on DL205 would probably do it. Longer term, we'll have a great answer on that new...um...brick-based platform we're developing, but the required pieces won't be there at launch. The joys of engineering compromise...

[plcnut]

Here is the result of a CTRIO2 output wired directly back to an input:

I believe that I can work with this

[DLTimmons]

The CTRIO2s on DL205 would probably do it. Longer term, we'll have a great answer on that new...um...brick-based platform we're developing, but the required pieces won't be there at launch. The joys of engineering compromise...

Talk about a teaser Any projected release date?

[BobO]

The CTRIO2s on DL205 would probably do it. Longer term, we'll have a great answer on that new...um...brick-based platform we're developing, but the required pieces won't be there at launch. The joys of engineering compromise...

Talk about a teaser Any projected release date?

Barring a slip, late next month. As with all such pieces of info, please accept with appropriate caution.

[Controls Guy]

Is that a people-month or an ADC-month?   

[BobO]

Is that a people-month or an ADC-month?   

ADC does a remarkably good job of launching products on time, once they have assigned an *official* release date. What tripped me up several times during this process is the assigning of *preliminary* release dates. I apparently missed hearing the word *preliminary*.

We now have an official release date and everything looks good to hit it.

I was gonna suggest that anyone interested could get some screen caps of the new stuff from the youtube videos accidentally posted publicly, but apparently those have been removed.

[franji1]

I was gonna suggest that anyone interested could get some screen caps of the new stuff from the youtube videos accidentally posted publicly, but apparently those have been removed.

They are still on youtube (unless my page is cached):
https://www.youtube.com/user/automationdirect/videos

[BobO]

I was gonna suggest that anyone interested could get some screen caps of the new stuff from the youtube videos accidentally posted publicly, but apparently those have been removed.

They are still on youtube (unless my page is cached):
https://www.youtube.com/user/automationdirect/videos

Ah...I had found them at the top of the search list, but they've wandered off.

[plcnut]

@Controls Guy,
You were right on about the Modbus/TCP latency.

I hooked up a Protos X Modbus/TCP remote I/O to the H2-DM1E on-board port and am getting 20 milliseconds minimum, from the time I set an output, until I can see it come back on an input. Many times it is 35-50 ms.
This is with an 8PT sourcing output module (PX-248) with one output tied directly to an input on a 16pt sourcing input module (PX-149).

I think I can put 10 CTRIO2's in (2) bases using an H2-EBC100 in the second and get by. I will use an ECOM100 to talk Modbus/TCP with my PC on a separate network.

I have lots more testing to do...

Thank you to all for your thoughts and advice!

[Controls Guy]

No, what I was talking about was worse than that.  I meant just the Tx/Rx response time was on the order of 10-20ms for many slave/servers, before even allowing for turn-on times for the input and output.  EIP and Profinet (especially Profinet) on the other hand, the Tx/Rx delay was measured in microseconds.

Now, since DM only supports EIP explicit messaging, rather than running the I/O asynchronously like in a CLX, you're still scan time dependent, but there are several boxes you'll have to check (scan time, physical I/O response, data transfer time) and quick comms at least helps check one of those.