Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Handwheel/Position Following mode
#1
Hello,

I'm currently using the Position-Following mode to implement a Jog/Increment Handwheel. I'm enabling following in normal mode (Motor[x].MasterCtrl = 1). I'm running into two issues with its behavior.

1. Whenever I reverse direction of the handwheel, I get an offset that occurs for the first move only. As an example, if I scale the MasterPosSf such that one click of the handwheel = .1mm of slave movement, as I increment away from zero I get perfect .1mm steps. As soon as I reverse direction the first move overshoots by an offset value of .0249mm. The next moves in the continued direction are again exactly .1mm, but this offset value is retained. When I return to the original zero I've over-shot by the .0249mm. If I continue in the same direction and then reverse to the original direction back to zero, then I'm exactly at zero. Where might this offset be coming from?

2. I need to use the MasterMaxAccel to get smooth behavior, and avoid amp/current faults at the higher increment settings. I also need to discard "excess" from speed limiting. Is there a way to do both?

Thanks,
Wehg
Reply
#2
It appears you have some non-zero backlash set, or possibly something funky in the servo deadband settings.

Probably the best thing to do to smooth the following but still be able to discard the "excess" from overspeed is to implement low-pass filter in the encoder conversion table entry for the master encoder. If you set EncTable[n].index2 for the entry greater than 31, it will add a 1st-order on the input data. The time constant of this filter is [256 / (256 - index2)] - 1 servo cycles. If you set index2 to the maximum value of 255, you will have a time constant of 257 servo cycles. This may provide enough smoothing. MasterMaxAccel would be set to 0 to enable the following mode that discards excess on following overspeed.
Reply
#3
Thanks Curt,

I tried using the low pass filter in the ECT but was unable to get enough filtering at the higher speeds. I have since implemented the functionality by incrementing the target position using the "jog1=(Motor[1].ProgJogPos)" type command. This seems to work well and allows me to pace the jog moves to match the acceleration time and avoid saturating the input command buffer.

I still have a problem with extra movement/position being added on a reversal though. In this case I am only reading the encoder at Gate3[2].Chan[1].ServoCapt. I have no motors pointing to this encoder at all.
The setup is:
EncTable[6].Type=1
EncTable[6].pEnc=Gate3[2].Chan[1].ServoCapt.a
.index1 & .index2 = 0
.ScaleFactor = 1/1024
.EncCtrl = x 4 quadrature decode

The encoder/handwheel is 100 lines per rev x 4.
One click on the handwheel produces 4 encoder counts. (100 clicks/rev)

If I move in a continued direction each click causes Gate3[2].Chan[1].ServoCapt to move precisely 1024 as expected. When I reverse direction 255 gets added to the first move. A sequence going negative from zero, then positive back to zero and beyond, then back to zero looks like this:

-3072 -2048 -1024 0
-1793 -769 255 1279 2303
0 1024

If the handwheel had one count of backlash, it seems the offset would be 256 not 255. Since the units for .ServoCapt are 1 count = 256, where might the 255 be coming from? (I can try another handwheel, but just doesn't seem like that's the issue.)

Thanks,
Wehg

(04-23-2012, 02:16 PM)curtwilson Wrote: It appears you have some non-zero backlash set, or possibly something funky in the servo deadband settings.

Probably the best thing to do to smooth the following but still be able to discard the "excess" from overspeed is to implement low-pass filter in the encoder conversion table entry for the master encoder. If you set EncTable[n].index2 for the entry greater than 31, it will add a 1st-order on the input data. The time constant of this filter is [256 / (256 - index2)] - 1 servo cycles. If you set index2 to the maximum value of 255, you will have a time constant of 257 servo cycles. This may provide enough smoothing. MasterMaxAccel would be set to 0 to enable the following mode that discards excess on following overspeed.

Reply
#4
It appears that the offset is from the 1/T extension being performed in the IC. It is computing a fractional count value in the direction of motion by dividing "time since last count" by "time between last two counts". When you stop, "time since last count" becomes greater than "time between last two counts", which would result in a "fractional" value greater than 1. Since this is not possible, the algorithm "saturates" the fractional value at 255/256.

While the 1/T extension is wonderful for smoothness during motion, when used as a master in this way, it has this undesirable offset characteristic for you. You should disable this function by setting Gate3[i].Chan[j].TimerMode to 1. (Remember to set Sys.WpKey to $AAAAAAAA to enable changes if you are doing this manually.)
Reply
#5
Thanks Curt. That took care of it.

(05-03-2012, 09:43 AM)curtwilson Wrote: It appears that the offset is from the 1/T extension being performed in the IC. It is computing a fractional count value in the direction of motion by dividing "time since last count" by "time between last two counts". When you stop, "time since last count" becomes greater than "time between last two counts", which would result in a "fractional" value greater than 1. Since this is not possible, the algorithm "saturates" the fractional value at 255/256.

While the 1/T extension is wonderful for smoothness during motion, when used as a master in this way, it has this undesirable offset characteristic for you. You should disable this function by setting Gate3[i].Chan[j].TimerMode to 1. (Remember to set Sys.WpKey to $AAAAAAAA to enable changes if you are doing this manually.)

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)