spindle velocity not returning to zero

More
8 years 3 months ago #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 to join the conversation.

More
8 years 3 months ago #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 to join the conversation.

More
8 years 3 months ago #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
Code:
# 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 to join the conversation.

More
8 years 3 months ago #114675 by PCW
Yeah, that's odd since the code does this:
Code:
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?

Please Log in to join the conversation.

More
8 years 3 months ago #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.

Attachment not found



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 to join the conversation.

Time to create page: 0.091 seconds
Powered by Kunena Forum