spindle velocity not returning to zero

21 Jul 2018 19:22 #114639 by jbraun
Running linuxcnc 2.7.2
Encoder is amt103 (capacitive type) powered from computer psu with inputs direct to parallel port.
Using channel A plus index.
Resolution has been tried 48ppr and 100ppr.
Used stepconf.

what's happening:
When the spindle stops the velocity drops to low number like 0.005 (0.3 in pyvcp) and sticks there. I believe it's related to using software interpolation where velocity estimates are no longer updating when the spindle stops. If I set the encoder.0.min-speed-estimate to 12 @ 48ppr or 24@100ppr the interpolation stops and velocity goes to zero though not very rapidly. The higher min-speed-estimate is set the snappier the pyvcp readout responds but the ability to interpolate may be lost-- I'm not sure how the math works on that.

Looking through posts here it doesn't look like others are running into this situation leading me to think there's something basic wrong with the way I've set this up.

Please Log in or Create an account to join the conversation.

21 Jul 2018 20:37 #114642 by PCW
Is the spindle encoder scaled properly? (spindle position should advance 1.00 per turn)

The encoder manual page says the velocity should be set to 0 when the measured velocity is less than the encoder.N.min-speed-estimate (so 720 or 1440 RPM with your 12/24 RPS numbers) so I would expect the velocity to return to 0 even before the spindle stops, _unless_ the spindle encoder scaling is way off...

Please Log in or Create an account to join the conversation.

22 Jul 2018 05:12 #114655 by jbraun
The GUI readout matches a photo tachometer and is 60x the encoder.0.velocity in hal meter.
motion.spindle-revs increases 1 with 1 spindle rotation.
Even with larger value min-speed-estimate the read out goes to zero a second or 3 after spindle stops.
Using default value of 1 for min-speed-estimate has interpolation bouncing between the current A channel position to the next anticipated position perpetually with spindle stopped. This must be the source of the phantom velocity ?

The spindle rpm is manual. I have no way to test threading as the drives have lost their smoke. It could be the lathe will work fine as is (?)

The hal was done by stepconf but here it is anyway
# Generated by stepconf 1.1 at Wed Jul 11 00:03:56 2018
# If you make changes to this file, they will be
# overwritten when you run stepconf again
loadrt trivkins
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
loadrt hal_parport cfg="0x378 out"
setp parport.0.reset-time 2000
loadrt stepgen step_type=0,0
loadrt encoder num_chan=1
loadrt abs count=1
loadrt scale count=1
loadrt lowpass count=1
loadrt near

addf parport.0.read base-thread
addf stepgen.make-pulses base-thread
addf encoder.update-counters base-thread
addf parport.0.write base-thread
addf parport.0.reset base-thread

addf stepgen.capture-position servo-thread
addf encoder.capture-position servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf stepgen.update-freq servo-thread
addf abs.0 servo-thread
addf scale.0 servo-thread
addf lowpass.0 servo-thread
addf near.0 servo-thread
net spindle-cmd-rpm     <= motion.spindle-speed-out
net spindle-cmd-rpm-abs <= motion.spindle-speed-out-abs
net spindle-cmd-rps     <= motion.spindle-speed-out-rps
net spindle-cmd-rps-abs <= motion.spindle-speed-out-rps-abs
net spindle-at-speed    => motion.spindle-at-speed

#setp encoder.0.min-speed-estimate 12
setp encoder.0.position-scale 48.000000
setp encoder.0.counter-mode 1
net spindle-position encoder.0.position => motion.spindle-revs
net spindle-velocity-feedback-rps encoder.0.velocity => motion.spindle-speed-in
net spindle-index-enable encoder.0.index-enable <=> motion.spindle-index-enable
net spindle-phase-a encoder.0.phase-A
net spindle-phase-b encoder.0.phase-B
net spindle-index encoder.0.phase-Z

net spindle-phase-a <= parport.0.pin-11-in
net spindle-index   <= parport.0.pin-13-in

Please Log in or Create an account to join the conversation.

22 Jul 2018 16:46 #114675 by PCW
Yeah, that's odd since the code does this:
		if ( delta_time < 1e9 / ( *(cntr->min_speed) * cntr->scale )) {
		    /* not to long, estimate vel if a count arrived now */

               	} else {
		    /* its been a long time, stop estimating */
		    cntr->counts_since_timeout = 0;
		    *(cntr->vel) = 0;

This suggests that the time-out at 100 CPR and 24 RPS minimum velocity would result in a timeout of ~0.4 ms! so clearly
something funny is going on. Is it possible you have a noise issue with the encoder?
The following user(s) said Thank You: jbraun

Please Log in or Create an account to join the conversation.

22 Jul 2018 23:05 #114680 by jbraun
The physical connections have now been stripped to the bare minimum. Another encoder of the same model is being used and a different computer as well. The results are the same.

It's to look for a different encoder and save this one for a different application.
Thanks for your time, it's appreciated.

Please Log in or Create an account to join the conversation.

Moderators: piasdom
Time to create page: 0.089 seconds
Powered by Kunena Forum