Advanced Search

I first found a lot of advise to use mplayer. Could not make it do anything. (LinuxCNC 2.9.4 Debian 12 Bookworm PREEMPT-RT ISO) download from 9th Feb 2025

The qtvcp lines in the *.ini made a picture with several cameras I tried.

I guess it's  expected that unless you use index during orient the unwind would happen.
As far as tuning goes are you saying it does not get close enough for the desired position?

If this was the case I would add some I term

Note that you should be able to use the PID's maxerror and maxerrori to limit
the correction velocity in the position loop. This should allow higher P  and I terms
without overshoot.

Not in velocity mode, no.

What happens is when M19 R0 is commanded, the spindle unwinds (speed/accel dependent on PID) until spindle.0.revs = 0.

If I've run the spindle for any length of time it takes that many times to unwind during orient.

If I set spindle-index signal high (using tristate bit or setsig) after running the spindle it'll reset spindle.0.revs.  Orient then moves in the opposite direction until spindle.0.revs goes back to (or near) 0.

Same behavior if I run the spindle in reverse - orient unwinds the spindle until revs = 0.

And orient never completes, even when the orient position is well within orient tolerance setting.  It'll just sit there making microscopic nudges since the PID error is so low.

Oddly, orient position error is always 0 (orient.0.poserr).

OK so that suggests it's not a direction issue.

Yes, spindle works fine in both directions.

Encoder is fine: RPS, RPM, and counts are accurate.  Encoder position connected to spindle.0.revs

Scale is set so spindle.0.revs increment up 1/turn.

EDIT - note that the tristate-bit in HAL file was an addition today that hasn't been tested yet.  Used that on my mill config to get the index-enable signal triggered before the first orient.

I guess I would first verify that you can run the spindle in both directions
and that they are the correct directions (and that the encoder count reflects
these directions)

I used the firmware you cooked up for me last year (attached), so I think it's the actual pwm hardware pin.

Yes, that's how it's currently configured - no ABS component between mux2 output and pwmgen.

So maybe the orient one-direction-only problem isn't because I don't have an ABS in the logic?