[SOLVED] Mesa/Hostmot2 - PWM direction pin?

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?

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.)
 

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?

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)

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.

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

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).

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.

It's not overshooting; PID tuning isn't the issue, at least right now.

On my mill, I have to set index-enable once before the first orient.  From then on orient never rotates the spindle more than 1/2 turn one direction or the other for the remainder of the LCNC session without having to reset the index.

The problems on the lathe are

• I have to set index-enable every time I orient, otherwise it unwinds all the way until spindle revs = 0, and
• It only goes one direction: whichever direction takes spindle revs back to 0

My understanding of orient, based on my mill's behavior and reading the MAN file (and forum posts), is that something should be doing some math so that orient knows which way to turn, and that it only needs to move until spindle revs equals a whole number (ie. at the encoder z-position) plus however many degrees are programmed in the R-value.

Side note - I also found that ORIENT_OFFSET in the INI file doesn't take in to account multiple spindles.  There's no way to have separate offsets for my main and sub... not important right now but may become annoying down the road.

It appears based on the orient man page that index should not be needed
since orient effectively does a mod(turns) operation on the rising edge of orient enable.
That does not seem to be working, so probably the first thing to investigate.

also

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

Shows some logical error somewhere

Need to look and the encoder position and orient.command before and after the
orient enable rising edge.

Note that using index at the wrong time here could cause the problem you see:
That is, clearing the position with index after orient has latched its offset would
cause similar issues to the ones you are having so I would disable index operations to do the
"check encoder position and orient.command before and after the orient enable rising edge"
test