Options for sub millisecond IO on a single processor.

[BobO]

EBC100 response delays are less than 1ms and the protocol allows for the entire I/O map of a base to be transferred in a single Tx/Rx pair. That's why I nudged back that way. Even assuming optimum Modbus/TCP performance, it was never going to be as good as one of the I/O-centric protocols.

[Controls Guy]

Right, I was assuming H2+EBC or ERM+EBC should beat Modbus.  My point was that if needed, EIP vs. native Koyo/FACTS would open additional brand/model options for physical I/O that might have better turn on/off times, without incurring the comm speed penalty of using Modbus to talk to [also plentiful] third party I/O.

Using CTRIOs, though, might make that whole discussion moot.

[plcnut]

The discussion has been great!

BobO, Can I get any speed out of ERM100 to EBC100 with the CTRIO2's? Or will It have to be DM1E on-board to EBC100?

[BobO]

BobO, Can I get any speed out of ERM100 to EBC100 with the CTRIO2's? Or will It have to be DM1E on-board to EBC100?

I'd use the onboard port. It's native and looks exactly like the local base. ERM100 is good for basic I/O, but sub-optimal for CTRIO2.

[Controls Guy]

Is the RIO protocol for the new bricks the same as H2 Do-More?  Or maybe better/faster but with compatibility on the new stuff to allow interoperability for old CPU + new I/O and vice versa?

[plcnut]

I am looking for the best instruction(s) to accomplish this application...
I am using the CTRIO2's to control 3 way pneumatic valves that are operating linear actuators. Each actuator has 2 valves. Each actuator also has 2 NO limit switches.
I want to command the CTRIO to turn on 1 output to operate a valve until limit switch 1 turns on. I then want it to immediately activate the other valve until limit switch 2 comes on. I want to use each CTRIO to control 2 of these setups. I also hope to use one of the inputs as a pulse catch, so that I can confirm that the actuator actually completed it's purpose.
I attempted to make the CTRIO do discreet control (versus a pulse train) so that I can take advantage of it's internal timing features. I thought that using a CTAXLIMT was going to be the perfect command, but I cannot figure out how to make the outputs turn steady on (instead of a pulse output). The actuator only takes ~18 milliseconds to make the limit switch in each direction, and so I thought that I could set the Maximum frequency (in the CTAXCFG) to 1, and make it work, but it does not respond like I expected.

I am able to use a couple of CTRUNVEL commands (duty cycle at 99, and Frequency at 1) to operate the 2 valve, and they work perfectly. The problem is, that they are dependent upon PLC scan time to reverse the direction.

I currently have the CTRIO outputs set to Pulse(CW/CCW).

I am a newbie to CTRIO's as anything more than reading encoders, and so I could really use some help here.

Thank you!

[Mike Nash]

I am afraid you have leapt into 20% territory here.

And yeah, this feels like a case of even if you get it working, it wasn't an intended usage so you are always at risk of firmware/software rev sudden death.

I don't seem to find an Up/Down counter in the CTRIO which would have been a first blush solution (Up on A, Down on B for the same counter.)

You might look at Input A as a leading edge counter where A is limit switch 1. Then limit switch 2 ties to C for Reset Fn1. Then 2 PLS tables with the first turning on Output 0 (set as Discrete on Ch1/Fn1) only when the count is 0. The second PLS turns on Output 1 only when the count is 1 (also set as Discrete on Ch1/Fn1). Then use Input C as Reset Fn 1 with a leading edge reset value of 2. You would set Fn 1 counter to zero in ladder to start cylinder 1 moving. Note that Out 0 is ONLY on at 0 and Out 1 is ONLY on at 1.

Kludgy, untested, and more than likely there is a better configuration (even using these functions), but it's not my project thank goodness!

[plcnut]

Thanks Mike!
I knew I was into the 20% territory (Or probably much worse than that). I opted to go with the CTRIO2 just because of the faster IO speed.
Once I had the module was in-hand, then I began to look at how I could take advantage of the internal processing power...

I will examine your suggestions to see what I can learn.

[BobO]

Is the RIO protocol for the new bricks the same as H2 Do-More?  Or maybe better/faster but with compatibility on the new stuff to allow interoperability for old CPU + new I/O and vice versa?

Protocol is the same, but it isn't the limiting factor. Backplane and processor speed are the biggest issues. We are planning a full range of brick-based remote I/O products (probably badged as DMIO) that are essentially a stripped EBC100 married to brick I/O. Any I/O on the brick is very fast, and the expansion bus is quicker than DL205, so that is a big improvement. The other thing is that the DMIO base controller will be many times faster than the existing EBC100. Turn around should drop to well less than 500us. We might look at a synchronous option if we like what we see, but that isn't a priority.

[Mike Nash]

So Mr. plcnut, it's been 5 days. Any updates on instant gratification of the I/O variety? I'm curious as to how you manage to pull this off.

I'm also curious what in the world you are doing that requires that kind of response time.

I noticed again that there are no I/O interrupts or immediate I/O instructions in the Do-more. I keep trying to figure if that is good or bad. So far I haven't missed it though. If it had it, would having to keep running off to service interrupts or immediate I/O increase the Do-more scan time so much it slowed things down too much overall?

In the past I've used both on a D2-260 job, even used the interrupt module, a CTRIO, Modbus RTU (also grabbing an extra analog input from the VFD terminals because I was I/O maxed) and was resetting the watchdog, but scan time there was way longer. I wouldn't miss never doing that again.

[plcnut]

Mike,
I tried the plan that you laid out, and it works. It is not very practical though, because I don't have enough resources to get the timing that I need for the rest of the system.
The plan that I am currently testing:
5 CTRIO2's in a single base. 1 quad encoder daisy chained to all 5 counter cards (the encoder can source 250ma per channel). Each of the 4 outputs on each card will have a table that I will populate with the encoder counts for where I want the output to fire. The CTRIO outputs will feed to a second high speed PLC (I am experimenting with a Velocio.net right now) or possiby a micro controller (Arduino maybe) that will then control each linear actuator. This same controller will also monitor another high-speed sensor for a confirmation pulse. The microcontroller will feed the data back to the Do-more rack via normal inputs that will probably be in an expansion base.
This is all part of a 20 lane high speed small-item sortation conveyor system. The line speed is engineered to run at 200fpm, with each item as close as 6" leading edge to leading edge.

Several years ago I built a 10 lane small item sortation system for the same customer, and it has done a wonderful job, but is no longer big enough to handle the volume. This system is twice as big, and a bit faster. The old system is entirely PLC based (Do-more is doing way more that a PLC is supposed to be able to do ) The new system is using a PC as the backbone, and letting the PLC handle just the IO.

This installation is not industrial, and already requires non-standard components, so I am willing to get off the beaten path a bit to get the desired result.

[Mike Nash]

I didn't expect my suggestion to fly especially because it ate up I/O you said you wanted for pulse catch.

I wondered about Arduino, etc. but considering where we are, didn't want to suggest it first. I have never used one but mostly because I don't have anything I want to use it for. I have played with AVRs in years past and even did a couple of tiny projects but nothing work related. Speed should be fine though.

Conveyors have never been a joy for me but I hope you are having fun!