News:

  • March 29, 2024, 12:43:36 AM

Login with username, password and session length

Author Topic: Feature input wanted!!  (Read 55274 times)

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Feature input wanted!!
« 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.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2121
  • YKPAIHA
    • ATU, Inc.
Re: Feature input wanted!!
« Reply #1 on: February 26, 2008, 10:46:54 PM »
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.

PLCGuy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 677
Re: Feature input wanted!!
« Reply #2 on: March 01, 2008, 07:46:08 PM »
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.

b_carlton

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 606
    • thePLCguy
Re: Feature input wanted!!
« Reply #3 on: March 01, 2008, 07:57:38 PM »
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?
An output is a PLC's way of getting its inputs to change.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: Feature input wanted!!
« Reply #4 on: March 01, 2008, 08:34:08 PM »
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.

"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

b_carlton

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 606
    • thePLCguy
Re: Feature input wanted!!
« Reply #5 on: March 02, 2008, 12:24:31 AM »
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.
An output is a PLC's way of getting its inputs to change.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: Feature input wanted!!
« Reply #6 on: March 02, 2008, 02:18:26 AM »
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.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

MichaelL65

  • Jr. Member
  • **
  • Posts: 19
Re: Feature input wanted!!
« Reply #7 on: March 05, 2008, 10:30:24 AM »
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).

milldrone

  • Full Member
  • ***
  • Posts: 48
  • I'm changing my attitude to thumbs up
Re: Feature input wanted!!
« Reply #8 on: March 06, 2008, 10:44:02 AM »
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? 
Vaughn

bd

  • Newbie
  • *
  • Posts: 5
Re: Feature input wanted!!
« Reply #9 on: March 09, 2008, 07:21:18 PM »
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

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: Feature input wanted!!
« Reply #10 on: March 09, 2008, 08:00:47 PM »
  • 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!
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

bd

  • Newbie
  • *
  • Posts: 5
Re: Feature input wanted!!
« Reply #11 on: March 11, 2008, 08:18:10 PM »
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.

JimHoward

  • Newbie
  • *
  • Posts: 1
Re: Feature input wanted!!
« Reply #12 on: April 07, 2008, 01:41:30 PM »
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)"?

sf93

  • Newbie
  • *
  • Posts: 1
Re: Feature input wanted!!
« Reply #13 on: April 15, 2008, 10:42:15 AM »
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!!!
« Last Edit: April 15, 2008, 10:47:15 AM by sf93 »

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 5975
  • Yes Pinky, Do-more will control the world!
Re: Feature input wanted!!
« Reply #14 on: April 15, 2008, 12:02:01 PM »
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?
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO