Advanced Search

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?

How to handle this depends on the firmware, some PWM outputs have the PWM direction
pin brought out and some leave it as GPIO (later ones tend to leave it as GPIO as that is
more flexible)

If its GPIO, you setup the GPIO pin as an output and control it from either the spindle
direction pin or like you did with the ABS sign.

If the output is the actual PWM direction pin, you feed the signed velocity to the PWMgen
and the sign of the PWM value determines the direction pin state (if its backwards you negate
the PWM scale value.)
 

Thank you for advice. Changes those numbers made some difference for sure. And now when I spinning motor shaft I don't get instant error. But motor have no holding torque at all. And also when I trying to move axis from interface there is no reaction. Did you do any setting adjustments with servo? Any tuning? Maybe I missed something from the manual.
p.s. I can jog motor from servo keys so I doubt this is wiring or hardware issue.

I'm trying to sort out my lathe spindle orient and have stumbled across a problem.

Currently, orient isn't working as expected: the spindle unwinds all the way to encoder position 0, and in the same direction every time.

The spindle is working as expected in normal velocity mode... no problems changing direction.

On my mill's 0-10v control I've got an ABS component linked to the spindle/orient mux2 output.  The ABS is-negative pin is connected to the spindle direction pin.  This works well - orient picks the shortest path and does what's expected.

However, on my lathe's spindle I'm using a pwm control (7i96s/7i85s), and while there is a pwmgen.N.dir pin in the software pwm component, there doesn't appear to be a similar hal direction pin for hostmot2 hardware pwm outputs.

The Hostmot2 manual references Out0 and Out1 pins, and under the Parameters/hm2_7i96s/0/pwmgen/01 section of halshow there are categories named out0 & out1... but no pins I can connect to the ABS component.

Any suggestions on a pwm direction pin, or is there some other hal scheme I should be using to get orient behaving properly?

The docs are available via the menu under cnc.

You may have to install evince to read pdf docs.

docs are available for German, English, Spanish, French & Chinese.

linuxcnc-doc-de
linuxcnc-doc-en
linuxcnc-dos-es
linuxcnc-doc-fr
linuxcnc-doc-zh-cn

Thank You so much. I have been reading, but unsure what to read and where to find it.

Actually we are using 7.3 Periodic synchronous position mode (CSP mode)
 

Turns out Kate was not saving my file changes for some reason. Thank you for your quick help, all is working now.

Steady work is happening on it at the moment, but it will be a week or two probably before we shake out everything and merge to the development repo

Are you sure you are editing the correct file?
Check and recheck, as that is the only thing.

Got the safety circuit ready today with e-stop and reset, it sends the a ready signal to the Ek1100. 

The green and blue push bottoms are a latching start circuit that drives a relay, it shorts the power bottom on the pc and gives power to the Ek1100.

​​​​​ have a nice day all