Host Engineering Forum
General Category => CTRIO and CTRIO2 => Topic started by: Mike Nash on October 17, 2014, 12:18:07 PM
-
I am looking for a way to have a servo follow another servo, but with a dynamic ratio adjust AND the ability to have the following servo reverse direction. It is a traverse for a winder. The ratio allows adjusting how the material lays on the roll and the reversing is for left to right. Currently the traverse is via a reversing clutch fed by a mechanical ratio mechanism from the winder motor. The winding motor is running in torque mode so speed varies quite a bit.
I would like to do this with a Do-more, CTRIO2 and Cmore. I have looked at the CTDYNPOS command but am unclear as to whether it would allow following realtime like this, along with reversal of direction.
-
You'd stand a better chance with CTAXDYNP. The target position can be updated on the fly, including reversal, and the module will get you there...or keep trying while you continually move his cheese.
I worry a little bit about jitter when you use a position target instead of velocity. I've done follower type behaviors before where I generated a SIN wave in math and had a stepper follow it. It works, but it wasn't as smooth as I wanted. The next logical step would have been to use a PID and control velocity (CTAXDYNV) instead of position, but I never followed through with that. The looser you can tolerate the uptake being, the better chance you can make it smooth.
I'm sure it can be done, but with caveats.
-
How does the position target get loaded with CTAXDYNP? Is it only updated during the PLC scan as opposed to getting a master encoder value directly from the quadrature input? I have to admit that finding something I saw a second time is a little difficult in Help.
CTRUNPOS looks like it can follow a quad encoder directly with Trapezoid Plus or Trapezoid with Limits, but... I need to be able to adjust the scale on the fly and I don't think that can happen.
A little deeper look. If I set the CTAXDYNP Target Position to a Quad Input that should also follow. Pointing to a scaled CTRIO2 input should also work. But neither of these is going to allow changing the ratio on the fly, much less reversing.
So I am going to need to massage the encoder input in ladder and set the target position each scan, correct?
The servo we are looking to use allows smoothing the pulse train input without losing pulse counts and this being a traverse that should be acceptable. The servo is also not going to lose track of the rotor due to any jitter like a stepper might.
If this would work, it might be feasible to add the servo traverse with the single H2-CTRIO2 we will already be using anyway.
With all that said, I don't want or need any surprises. I wish I had a CTRIO2 on hand to experiment with. :( Then again, I don't have a servo to hand either. ::)
When are we going to see the CTRIO/2 simulator module? ;D ;D
-
How does the position target get loaded with CTAXDYNP? Is it only updated during the PLC scan as opposed to getting a master encoder value directly from the quadrature input? I have to admit that finding something I saw a second time is a little difficult in Help.
Specify a variable for the target position in CTAXDYNP, enable the CTAXDYNP instruction, set the .GotoPosition bit in the associated structure from code. With CYAXDYNP, you can feed it a new position every other scan or so.
CTRUNPOS looks like it can follow a quad encoder directly with Trapezoid Plus or Trapezoid with Limits, but... I need to be able to adjust the scale on the fly and I don't think that can happen.
A little deeper look. If I set the CTAXDYNP Target Position to a Quad Input that should also follow. Pointing to a scaled CTRIO2 input should also work. But neither of these is going to allow changing the ratio on the fly, much less reversing.
The profiles that have encoder inputs are not followers in the sense that you are wanting, they are simply using the encoder as the position instead of the accumulated stepper pulse count, and the specified move is performed in encoder units instead of stepper units. The stepper is still the driving element, and the scale factor there is the ratio between encoder and the stepper.
In your case, you would be creating your own linkage between the two different axis mathematically, therefore the scale ratio between the two is up to the math that you choose.
In dynamic position mode, the axis reverses automatically when you specify a position behind the current position. There is nothing for you to do.
So I am going to need to massage the encoder input in ladder and set the target position each scan, correct?
The servo we are looking to use allows smoothing the pulse train input without losing pulse counts and this being a traverse that should be acceptable. The servo is also not going to lose track of the rotor due to any jitter like a stepper might.
Precisely. The question is just what is the best way to do that. When you specify a target position, the module is going to constantly accel/decel as it sees fit. This is the jitter I was referring to. If the slaved side is far enough behind that effect will be mitigated to a great degree, and if the servo has some filtering that will help too. An alternative would be to control the slaved servo with velocity control and use PID. I'm reasonably certain that could work, depending on how much slop you can handle between the master and slave, but that would require a bit more math and/or tuning.
If this would work, it might be feasible to add the servo traverse with the single H2-CTRIO2 we will already be using anyway.
With all that said, I don't want or need any surprises. I wish I had a CTRIO2 on hand to experiment with. :( Then again, I don't have a servo to hand either. ::)
And that is my only concern. I *think* it could be made to work, but that depends on a large number of variables that I don't have answers for. We'd like to add a follower mode to a future product, just aren't quite there yet.
When are we going to see the CTRIO/2 simulator module? ;D ;D
That'd certainly be nice, and you're not the first to ask. Right this moment we are peddling the bike as fast as we can on the development of the new Do-more platform...
-
Thanks BobO. I am really thinking this could work just fine for this app. The existing traverse system is on its last legs and it would be good to be able to change it over. I don't think it is all that critical as to precise positioning, but it does need to follow the winder wherever it leads.
I could always PID it if it proved necessary.
Keep up the good work!
-
I might throw a PID routine in for chuckles and see how tight it is. Might be easier than I think, and once tuned, I'm pretty sure it would do a great job.
-
Done. Wasn't hard. Depending on aggressiveness of the tuning, it tracks quite close, but the stepper sounds like a theremin. More relaxed it doesn't sound quite so warbled, but doesn't track as closely. With filtering in the servo and a reasonably stable frequency, I'm sure it would work great. Oh yeah...I was tracking a SIN wave with a period of about 15 seconds, so my frequency was never stable. I would expect yours to be far more so.
-
Results...
-
Bob, Mike...very interesting thread. I need to do something very similar. I have an encoder (E1) and wheel in contact with a process material. The material is a continuous strip. The material is threaded through the first stage of the machine. The material is driven by a dc servo at a continuous velocity say 40 ft/min. E1 is a 600ppi encoder.
The second stage of the machine is an indexing head (IH). It consists of a punch and a shear. The punch and shear move together on linear rails driven by an AC servo drive and motor. Motor has built in encoder with 2500 line count (10k ppr). The IH must accelerate and match velocity of the process material long enough to punch, shear or both, decelerate reverse to home or reverse far enough to match the next register position of E1 (0, 600, 2400, 4200,...etc.).
Mike, how did your project work out.
Bob, have you done anything like this with the H2-DM1E, H2-CTRIO2, D2-08CDR (to provide dc servo speed reference)?
-
The traverse got the thumbs down for the time being. I have been programming on (translating really) the rest of program today as a matter of fact.
I never thought I would miss having BCD and double registers, etc., but this would have been an easier translation into a D2-260 since it was coming from an old Omron. OTOH, I did get to create my own data types (HR, DM and IR) so it was easier to type it in without having to have a map. I'm not really fond of having to use the colon for the bits (HR200:1 for HR 200.01), but oh well.
I still have to get the conversion from the grody Omron Hi Speed Counter nailed down. Hi Speed Counter cards have historically been a cryptic royal pain for some reason I shall probably never know.
Good luck with that flying punch/shear - never one of my favorites.
-
I know how you feel about changing delimiters once they're ingrained. In Logix 5K, I still try to separate the bit with a PLC/SLC style slash once in a while, even though the CLX has been around for 15 years!
-
In Do-Mores case, I'm sure it's the price we pay for being able to enter FP contacts without an "R" like in DL. I have no idea what AB's excuse for losing the slash is, though. They changed a bunch of stuff from the PLC & SLC that seemed unnecessary.
-
I never thought I would miss having BCD and double registers, etc.
There are BCD conversions and double registers in Do-more. What specifically are you missing?
-
Bob, have you done anything like this with the H2-DM1E, H2-CTRIO2, D2-08CDR (to provide dc servo speed reference)?
Me personally? No. I've made, serviced, and supported PLC products, but have never really used them. Crazy, huh?
-
I never thought I would miss having BCD and double registers, etc.
There are BCD conversions and double registers in Do-more. What specifically are you missing?
I thought about it (for about 2 minutes) but it's not the same really as the math is BCD also. And they were playing games with using only the Most Significant Word and stuff. I did have to do some hoop-jumping with some of it, but I'll convert the counter stuff anyway so it's not a big deal. It's really, really hard to remember to type MATH instead of MUL or SUB, etc. Working with the Accumulator got to be second nature after enough of it. I sure do like having negative numbers though. But there again, they can sometimes cause problems too when the old PLC didn't have them.
-
I'm poised to buy $2,000 worth of electronics and I can't find any examples of how one would use the second channel of the CTRIO2. I am making an expensive assumption that I can use them together to accomplish my task. Can you think of an approach?
-
I'm sorry omprodesign. I can think of a couple of ways I could approach this, with a CTRIO/2 or CTRIO/2 and Analog Output card. But I haven't done this application without using dedicated flying cutoff controllers. I did see an attempt - by others - years ago to replace a computer with a SLC500, which didn't work as it was too slow. We attempted using a Contrex M-Shuttle, which could have worked except the pieces were odd lot and the an off-the-shelf M-Shuttle didn't handle that well at all. We found the old computer finally and reinstalled it. But that was years ago and older hardware without any servos either.
Either way, I don't think you'll find an example of a Do-more doing this yet as it is still too new. You go first. ;)
For me, I think the logic or math to figure where to be when would be the biggest challenge, just conceptually.
-
How is the IH servo controlled?
-
I don't have a project still, but had reason to stumble over this thread. So "It's alive!"
Since I have the hardware I did not have back when, I decided to try this out. It does seem to work but...
I am seeing an odd jerkiness in the forward direction. I can get it in both directions, but it's very pronounced over a wider range in forward.
CTAXCFG
Min Freq 0
Max Freq 10,000
Accel Rate is 35,000
Decel Rate is 35,000
CTAXDYNP
D1100 is the Position Setpoint.
This is created by a LERP profiling an incrementing count so there is no difference in rate of change of setpoint.
The increment is just a MATH box adding a fixed amount when Timer T0 reaches 2mS.
The different slopes represent different increment adders to the value feeding the LERP.
If I put in larger increments (say 20 every 2 mS before LERP) the erratic velocity improves. Above a certain amount though I have to increase the Accel Rate or get excessive lag.
If I lower the Accel Rate, I can run smoothly at much lower increment amounts.
The question here is why is the velocity so jerky for increasing setpoints when it is not for decreasing?
This is an H2-DM1E and CTRIO2. I do have a servo running from the CTRIO2 but am not looking at it in anyway in the program or hardware. I can definitely hear and feel the jerkiness.
-
CTAXDYNP
D1100 is the Position Setpoint.
This is created by a LERP profiling an incrementing count so there is no difference in rate of change of setpoint.
Turns out I was wrong, math error on my part so the positive slope was 11% steeper.
It's still true that for a given slope, the positive direction tends to be more prone to actually inverting polarity of the velocity.
I have found the most stable response is had by lowering the Accel and Decel Rates with slower setpoint ramps. (Enough of an increase in Accel Rate without equivalent Decel gives a pronounced sawtooth.) With the CTAXDYNP enabled constantly and the .GotoPosition bit SET whenever it is not set, I don't get a response to the CTAXCFG changing the Accel and Decel Rates. Using the CTAXCFG Success bit to momentarily open the enable line on the CTAXDYNP makes it see the new rates, but puts a little bump in the pulse string out. Is there an "on the fly" way to change the rates without dropping the Enable input for a scan?
-
It's really not designed to do what you are attempting.
-
It's really not designed to do what you are attempting.
But, I NEED it to! :'(
or alternatively:
WELL? We're W-A-I-T-I-N-G. :P
So OK, I don't actually have an urgent need for it at the moment, but that's only by the grace of fickletude. It really can be frustrating to have exactly what you need, but for one or two minor-seeming yet not-to-be-overcome gotchas.
I was kind of hoping for a more magic bullet kind of answer though. Oh well.
What does it mean fickletude is not a word? Have I got to do everything myself?
-
Very distracted with the new hardware (working on motion, coincidentally), but in the simplest terms what are you wanting to do?
-
In this particular case I am looking at the feasibility of adding a stepper or servo to replace a gearbox driven traverse function. The follower must track a spindle encoder on the winder. This needs to be profiled to allow variable dwell times, programmed turnaround points, variable "lay" angle (traverse travel per spindle rev.) and of course constantly changing (sometimes unpredictably) spindle speeds.
So far just playing around, CTAXDYNP looks better than PID/CTAXDYNV except for the need to change Accel/Decel for stability as the spindle speed changes. This seems to require disabling the CTAXDYNP to recognize the new values and that causes a blip that I am unsure a stepper would accomodate. Can't wait for the dwell unfortunately.
And the "W-A-I-T-I-N-G" is for what you are working on in hopes it will help in some of my applications. At this point I can't even promise I will ever actually need to implement this, but it has come up a few times and got close. So please don't let me impede your progress.
-
Don't know if the new stuff will accommodate you or not. We have an electronic gearing mode with variable gear ratio. We also have a position following mode with a fixed ratio. Neither of those modes allow for dynamic accel/decel, and terminating any mode decels the axis to zero. We initially were going down the road of having instructions interact with a fully dynamic axis (facilitating the stuff you are trying) but we felt that was not in keeping with the needs of our target market.
There is a decent chance that the follower function will do exactly what you need though.
-
:o <- >:( target
This day and age, I have no desire to be anyone's target, market or otherwise. ;)
Considering I never really knew for sure what was being considered, I have no real room for disappointment. I hope to find nice surprises.
I am finding CTAXDYNV to be a little unpredictable. If I set it up and simply change the value for the Frequency (D mem) it does pretty much what I expect. If I have the program changing that value then things get much more problematic. As long as I do not cross zero into the other direction, no issues. If I cross zero frequency, then somewhere between -100 Hz and 100 Hz it tends to just freeze the output frequency at some value 20 to 100 positive or negative. Yes, I see the 20 Hz min.
If I increase the reference update rate to something more than 10 times per second it is likely to hang. At 60 mS intervals it may run for a few cycles before hanging, at 5 mS guaranteed (perhaps). The interesting thing is that anything that "disrupts" the ref update may unhang it. Suspend will and so will causing the ref freq to momentarily sit still.
So now I am wondering if CTAXDYNP isn't doing something similar.
-
Are you turning on CTAXDYNV and leaving it on and then changing the target velocity?
-
Are you turning on CTAXDYNV and leaving it on and then changing the target velocity?
Yes.
I was able to mostly prevent the freezing output if I do not allow a Frequency setpoint anywhere in the -200 to 200 Hz range. It can be less if I have much longer periods of a non-changing setpoint. I have not tried to do this with the PID yet. Maybe deadband might help prevent issues when I do since that will be a no-fly zone.
Higher overall frequency ranges seem to do much better since +/- 200 Hz out of +/- 50-100 kHz is a less huge chunk, but being able to specify that is not guaranteed based on a given stepper drive/gearbox/screw. Servos tend to allow more flexible scaling.
I know ya'll are busy, but if you do find yourself twiddling thumbs at some point, I'd love to know if there might be a workaround for either method. I like the DYNP, but the too sluggish at speed or too hyper down low looks like more than I can find a compromise on.