Host Engineering Forum
General Category => General Discussion => Topic started by: plcnut on January 14, 2017, 01:51:42 PM
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
Here is the result of a CTRIO2 output wired directly back to an input:
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fi761.photobucket.com%2Falbums%2Fxx256%2Fplcnut%2FPLCs%2FCTRIO2_Timer_zps9e7ghevv.png&hash=a197216eaa2976c27cb3e10ec99621179ba51bac)
I believe that I can work with this :)
-
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?
-
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.
-
Is that a people-month or an ADC-month? ;D
-
Is that a people-month or an ADC-month? ;D
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. :'(
-
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
-
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.
-
@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!
-
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.
-
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.
-
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.
-
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, 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.
-
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?
-
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!
-
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!
-
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.
-
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.
-
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.
-
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 ;D) 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.
-
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!