Host Engineering Forum
General Category => CTRIO and CTRIO2 => Topic started by: BobO on February 25, 2008, 06:17:20 PM
-
Ok, since it has been brought up in a previous topic, let's formalize the discussion...
We are in the process of doing some pretty broad and significant work to enhance the DirectLogic line. We are still not willing to talk about some of what we are doing...AutomationDirect has had too many bad experiences talking about products in development too early...but perhaps we should open up some discussion on the CTRIO part.
We are desiging a new version of the Hx-CTRIO module...creatively named (at least for now) the Hx-CTRIO2. From a hardware standpoint, it is a much higher performance platform...both from a processing power and I/O standpoint. The additional performance will empower many of the improvements that folks have been asking for, and the I/O speed will allow it to talk to pretty much anything out there. The hardware design rocks. But even with great hardware, it is only as good as its firmware.
So...<deep breath>...what does the existing CTRIO do right and wrong? Need to know both, so we don't mess up what you currently like about it, while adding new stuff. One goal is to improve the motion functions...considerably. If you were trapped on a desert island, and could have 5 motion control IBox style instructions, what would they be and how would they work? Anybody have thoughts on registration? What about PLS? Anything else you'd like to talk about?
You talk, we'll listen.
-
The workbench is great and easy to use. I like having the programming access over the same link as the PLC. However, I would like to see an expanded module-Vmemory interface.
Using Vmemory for preset tables (Like 05/06). What about some type of interrupt capability? It would add flexibility for registration and complicated home moves. Perhaps, take advantage of the interrupts if the module is placed in SLOT 1 ?
Also on the current module, if the move is very small, the PLC never sees the output status go "Busy" . I would like to see that status bit have a latched status until the PLC program clears it.
-
Hey Bobo,
Trying to remember my first experience with the H2-Ctrio. I said to myself, holy crap. It almost reminded me of the days of the Optimate panel, all that mapping. But once I understood the bits, (week or so), then it all seemed easy. Hopefully this mapping stuff is done in the back ground like the C-more panel. Example, C0 in ladder is seen by the panel, not much to do but assign an button object to C0. Push the button and whola, the ladder program sees it. Instead of Loading a number into a v-memory, maybe in software you select velocity mode and somehow it is done in software. You get my drift. I suppose I would like it to work like the C-More does with the plc, just plug and go. Doesn't it make sense, the CTRIO and the PLC are both Automation Direct so they should talk to each other more easily. The mapping, the mapping, eeww.
Well that is my input.
-
When I first heard of this coming out I was hoping that it would have the functionality of the D4-HSC. It has enough inputs for encoder, limits, home and outputs for run, direction and speed. We used the D4-HSC a lot. Any possibility that the firmware could be changed to provide a different function?
-
The current plan for the CTRIO2 is to have it operate in 2 modes:
Mode 1 is a compatibility mode that will allow it to be a drop in replacement for the existing CTRIO. It will look and work the same, and provide modest performance improvements...for instance outputs will run at 64k, instead of 25k...but the scan times will be dramatically faster. The key careabout for this mode is compatibility.
The new mode 2 is the exciting part, and it is here that new stuff will happen. The feature set for this mode is pretty wide open, which is the primary motivation of this thread. PLCGuy...take heart, this new mode, in concert with some other system improvements in the pipe, will completely change the way this module works with the PLC. You will definitely like it.
As for the D4-HSC...help me understand what you like about it, and we'll see what we can do.
For the output behavior, I'm kinda thinking along the line of 5 key functions: 1) an improved Dynamic Position, 2) an improved Dynamic Velocity, 3) an improved Home Search, 4) a new Registration function, and 5) a new Primitive function. The Primitive function would be a script type IBox that would allow you to construct complex moves from fairly simple commands. For all the stuff that the canned routines doesn't do, the Primitive box would answer the call.
The big questions are: 1) What would a registration box look like, and 2) What primitives do folks need?
One thing we also can do with the new hardware...inputs and outputs can be assigned to any function. Rather than Ch1/Ch2 A/B/C/D, it will be just 8 inputs that can be assigned wherever. Outputs will be a little less flexible, but should still be better than before.
-
We used the D4-HSC in a rough positioning mode.
It controlled a DC driver card with a High/Low/Off output using two wires and with the direction indicated on a third output. Once it had been sent to a 'home' position it could be commanded to go to any position. It would determine the proper direction and drive the dc motor to the proper position using the encoder feedback. It slowed when a defined distance away from the target and stopped at the target. This seeking/slowing/stopping was performed without further commands from the CPU.
It isn't a servo as it doesn't dynamically hold position but the mechanics of the system did not demand that. The only problem was a limitation of 8 of these per D4 CPU. We had to do some tricks to get more controlled axes.
-
So a simple 2 speed DC motor controller using encoder for position with some presets for determining target and decel. That doesn't seem hard at all.
-
Something I have needed is sort of a ratio output ('Electronic gearing' is what I saw one controller company refer to it as). Basically having an encoder input that can be manipulated by the PLC to be output at a higher or lower rate (ie a 5kHz input is output at 1-10kHz). The last project I did had motors that were able to do that internally from an encoder pulse, but they didn't handle it very well.
If that function is already there, I apologize as I am only on the second project that's used the CTRIO, and the last one was way too rushed to figure out what all it could do. But it would really come in handy.
Also having the inhibit function be able to be called internally by the PLC would be nice (instead of having to dedicate an output to activate that input of the module).
-
The Primitive function would be a script type IBox that would allow you to construct complex moves from fairly simple commands.
Bob O,
First my confession: I have never used a CTRIO before.
Would this include coordinated moves? That would be where two axis of differing lengths are moved at the same time and "geared" so they end at the same time? How about If you had an X and Y axis and wanted to move angularly between them? Circular interpolation?
-
1) Adding a count parameter to the edge timer function would be helpful in increasing its resolution. The edge timer would return the time for the most recent N pulses on the given channel. Particularly helpful for determining minute differences between two speeds where the accuracy of the input device is uncertian.
2) Beyond "ratio output" mentioned earlier would be list processing or input queuing.
A list of xy coordinates would be set up in memory, or fed to the controller. As the controller worked its way through them, it would correct speed accordingly, based on dual encoder feedback.
The big issue would be how to recover after an estop.
Thanks
BD
-
- Not real sure how far we will take the pulse outputs...as related to coordination and arcs and such. I'd love to do some really cool stuff...but...one of the goals for this product is to reduce the need for setup/configuration/programming software. It is expensive to develop and expensive to support, and may only slightly increase the fit of the module for the bulk of ADC's customers. We will be tending toward operations that can be described by a box instruction, at least initially. I'd personally love to see some kind of file system appear on the controller some day, and that might provide a path to some higher end functions.
A big part of the reason for this thread is for me to understand what folks really need this beastie to do...gives me the moon to shoot for ;) ...and then we'll see what we can do in practice. I hate to admit it, but at times, the best design comes from just doing it. I find at times that what I thought was hard, wasn't...and what I though wasn't, was...and I don't know the difference until I get there. You'd think after 20 years in the biz, I'd be a little smarter than that. :o
- Electronic gearing sounds easy and interesting. Since you would have to sample the input frequency and redrive accordingly, only question becomes sample time...I guess that would need to be a parameter. I am assuming that this would be a velocity function, and not a position function.
- The current CTRIO can do the edge timer count parameter thing, but only via interval scaling. You do an interval scale and then add smoothing, which is just a moving average. The result streches the accuracy out considerably and allows you to see signal in the noise. That said, having that same ability in raw counts would be nice.
- Thanks for the input so far! Keep it coming. We are listening, and we are working, and over the next couple of years you are going to see some very cool products come out of Host!
-
Hi Bob,
Thanks for your quick response.
I currently dont have an application for the multi-edge timer, but when I did, I wanted the accuracy of an exact integer count divided by a microsecond time.
Using the interval timer (if I read the manual correctly), it appears that the accuracy would be lost because the time interval appears to be fixed, and the count measured within that interval is necessarily rounded to an integer, unless the module adjusts the time of each interval to conincide with a pulse edge.
Best Regards,
BD
P.S. You guys do good work. Keep it up.
-
The existing CTRIO, configured with 2 quadrature encoders, and two "reset values", will write the "reset values" to the "current encoder position" registers on power-up (regardless of where the encoders actually are).
Yes, I know I can have the PLC record the "current encoder position(s)" every scan; and on power-up write (WT) those values back to the CTRIO. But how about as a new feature in the CTRIO2, that it remembers the "current encoder position(s)"?
-
I would like to see a High Speed Counter that would except a true Line Driver(differential) encoder not just having to use the A,B,Z signals from it. If that could get added to the list I would jump for joy!!!
-
On the subject of value retention: It takes a battery and low-power RAM, or an NV-RAM, or some other such device to do that on-module. It would be better to implement that with direct CPU support. The CTRIO2 and the new CPU will already have a much tighter relationship which makes such things easier. We'll give that some thought.
On the subject of line drivers: We have talked about this on many occasions. The problem is screw heads...don't have enough. Would you rather have a two channel device that uses a ribbon cable (or ZipLink) instead of the existing terminal block? Or a one channel device (at slightly less money) on the current terminal block?
-
I haven't had too much trouble in using an external differential-single ended buffer. It would add a lot of board real estate to provide that for the few using differential. Regarding keeping the position a supercap (with the understanding that this would be short term memory only) might help.
-
The big issue with holding RAM state is that it requires a low-power static. Those parts work great, but tend to be slow, and when you have only one memory on board, it can be an unacceptable compromise to slow down the CPU's memory access rate to match the memory.
An interesting aside...the CTRIO's clock rate is 16Mhz, even though the CPU could handle 20Mhz. Why? Because by slowing down the CPU to the point that instruction access was 1 clock instead of 2, the overall system performance was increased by 30 or 40%. Sometimes you gotta go down to go up. Reminds me of a few life lessons.
The new CTRIO2 has only one memory...a high speed dynamic RAM. But never fear...I think we can make this happen transparently, and accumulator retention becomes a simple checkbox in the configuration.
-
I would like to see a dual channel (or more) CTRIO card that could do a rate calculation as well as return a raw or scaled count on each channel. I have tried tying both channels together and trying to drive them using an Automation Direct encoder (TRD-N100-RZWD) using a 24 VDC supply, with one channel set to do a rate calculation and the other channel set to return the pulse count, but the encoder apparently had problems driving both channels simultaneously.
-
With some of what we are kicking around, that should be simple. The current limitation is memory map...it's already pretty big. A big part of what we want to do with the CTRIO2 is to improve the CPU integration. Meaning, the PLC will have an intimate knowledge of the CTRIO2, and will be much better at exchanging data between the two. The previous discussion about accumulator retentiveness is actually similar. Stuff that has been very difficult to do previously, becomes almost simple when the PLC knows the CTRIO2 and has a cleaner way of expressing data from modules.
Without saying more...yes, another teaser...think dynamically generated structure representing the memory map of the module as configured. That's a mouthful, but it means that we can express the module's data directly in the PLC in the appropriate format. Having a counter's scaled data, raw data, captured data, etc., all present at the same time becomes simple. I think that would solve your problem nicely.
-
Reading all these posts, I remember what I would like to see. I remember doing a project and I wanted to see positioning. It has to be there. It seemed too much to map and get the data if it can be done already. If it can be done, make it simplier. I was trying to see what the counter was at and could not. I forget exactly what I was trying to do, but I think it was trying to get the position and counter data and read them.
-
That's a little ambiguous, but I get the "make it simpler" part. ;D
If you are trying to get the position from an encoder, it is already pretty easy. Configure the quad input channel, and tell me where in the PLC's memory you'd like it to go. Doesn't get much easier than that.
On the other hand, the pulse output functions are somewhat more involved. The IBox functions introduced in DSP 5 dramatically reduced the complexity...but it is still harder than we'd like it to be. Stuff like that will definitely get improved.
Even the basic quad input should get a tiny bit easier with the CTRIO2. I think that all you'll have to do is tell me you want a quad input and tell me which of the CTRIO2's physical inputs you'd like assigned to the function and <poof> it'll just show up in the PLC's memory. We'll work on the psychic mind reading configuration tool for CTRIO3. ;)
-
I would like better access of internal registers (using RD and WRT on a DL05 PLC for example).
Mainly, the scaling parameters.. It would be nice if I could create a solution, then have a setup page on my HMI screen where the user could enter the encoder PPR, smoothing, etc. parameters. This way, an end user of my solution would not neet to use CTRIO Workbench to adjust these settings, rather, it would be fully integrated in the HMI.
-
Please remember us guys that do things with the CTRIO that you never imagined. My need is very basic. I need to be able to have the CTRIO record its clock time for edge detections on two input channels. Don't process the signal, just let me get access to the CTRIO clock time and I'll do the rest, including missed events and counter overflow.
So the idea is to not think applications, but provide very fundamental access to the internal clock on the CTRIO.
Requests:
1. Be able to read the current clock time on demand. If Useconds, then even 16 bits will overflow only 15 times a second, the PLC can scan fast enough to deal with that.
2. Record the clock time when an edge event takes place, either positive, negative, or both.
3. Allow either free-running or PLC reset modes for item 2
4. Do item 2 for at least two inputs simultaneously independently, all four would be fantastic!
Bill Thomson
-
Please provide some simple elementary functionality for those of us with esoteric timing needs.
I simply need PLC access to the CTRIO current clock count, and to be able to access the edge detection time (using the same clock base) for any or all of the inputs individually. It would be desirable to be able to chose positive, negative or both transitions as is done currently.
I realize that the PLC and CTRIO will only communicate once per scan, but this functionality will still work for me. The PLC can do the rest of the processing I need. For this purpose I don't need any status flags, as the time stamp itself will supply enough information.
-
I would love a Ziplink connection if I could use line driver encoders
-
It would be nice to import discrete preset table data into Designer. The same for Memory Blocks would help too when ROM tables are needed.
-
I'm no Ctrio expert but on this project with 16 encoders & Do More PLC; I set up all the Ctrio stuff as retentive. But that didn't work ! After I lost all the data several times I had to add logic to save the position data to D mem and reload it on boot.
Seems to me the retentive alt to work, nice a simple.
bbass
-
I'm no Ctrio expert but on this project with 16 encoders & Do More PLC; I set up all the Ctrio stuff as retentive. But that didn't work ! After I lost all the data several times I had to add logic to save the position data to D mem and reload it on boot.
Seems to me the retentive alt to work, nice a simple.
bbass
What you marked as retentive was the Do-more structure, not the underlying hardware register. I realize that from the user's perspective the difference is semantics and it should just work, but the CTRIOx wasn't designed for Do-more, so sometimes we are a bit limited in what we can do.
The good news is that yes, we agree with you, and in BRX (new design!) we added retentive counter accumulators. So while it may or may not get fixed in CTRIOx, it is already fixed in BRX.
Since BRX currently doesn't have a counter expansion module (coming early next year), BRX can't yet replace 205 for apps like this, but that is coming...and better actually. The BRX replacement for the CTRIOx is still only 8 in/4 out, but will support 4 quadrature inputs per card...so your 16 encoders can be done in 4 modules (if you don't need Z pulse or other inputs).