Following Another Encoder

[omprodesign]

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?

[Mike Nash]

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.

[BobO]

How is the IH servo controlled?

[Mike Nash]

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.

[Mike Nash]

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?

[BobO]

It's really not designed to do what you are attempting.

[Mike Nash]

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. 


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?}

[BobO]

Very distracted with the new hardware (working on motion, coincidentally), but in the simplest terms what are you wanting to do?

[Mike Nash]

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.

[BobO]

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.

[Mike Nash]

  <- 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.

[BobO]

Are you turning on CTAXDYNV and leaving it on and then changing the target velocity?

[Mike Nash]

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.