Spindle orient PID tuning [re-solved, yay]

Finally figured out why the spindle was orienting in different positions every time I started LCNC.

spindle.0.index-enable, encoder.00.index-enable, and pid.s.index-enable are all connected together in HAL for the orient component.  What this meant was that the index position wasn't resetting after the index pulse went past the pickup.  So every time I started LCNC it thought that the random starting position of the spindle was 'home' and then applied any orient_offset.  Orient position was repeatable during a session, but not between sessions.

Couldn't set any of the index-enable pins high in halshow - they're all connected.  But setting the encoder.00.index-enable pin high in HAL before making the hal connections worked (i.e. earlier in the file)

At LCNC startup the index-enable pins are now high.  Which means that running the spindle for at least one revolution sets the index pulse position properly, and from there I was able to adjust ORIENT_OFFSET in INI until everything lined up with the shot-pin and ATC drive dogs.

It's now behaving properly; I can close LCNC and reopen it and M19 R0 winds up at the same place every session.  Yay.

But... this means I have to run the spindle for at least one revolution before invoking an M19 orient command.  If I start it and don't run the spindle before M19, the spindle will orient based on the start-up position: index-enable hasn't triggered yet.

I could remember to run the spindle before M19 every time.  Or I could have a program that loads on startup to 'home' the spindle.  But those both feel kinda of hacky.

So my question is this: do I have the HAL connections wrong?  Should one of the 'index-enable' pins not be connected to the others?  Or is there some other way to force an index-triggering move?

Maybe remap M19 so it includes an M3 S500 for a second before moving on to the orient process?

You have actually found the issue that ended up with me making the multi-spindle patch, but which I have still not got round to.
The idea is that spindles should be included in the home sequence. And to do that they neede to act more like joints, and then there might as well be support for more than one and...

Anyway, sorry I didn't think of this earlier when we were discussing the problem. It should have been obvious to me.

You should be able to "sets" the _signal" that links all the index-enable pins. But once they are in a net you cant "setp" the individual pins.

It should be possible in HAL to arrange for the spindle to run at constant speed if orient-enable is true and index-enable is true. (and you would need to "sets" that signal true in HAL just as you do now)

One way would be to switch-in an FF0 input on the orient PID (of you are not already using that) switched in and out by a mux2 in turn controlled by index_enable AND orient_enable.

This is already looking complicated enough for a custom component...

andypugh wrote:

You have actually found the issue that ended up with me making the multi-spindle patch, but which I have still not got round to.
The idea is that spindles should be included in the home sequence. And to do that they neede to act more like joints, and then there might as well be support for more than one and...

Anyway, sorry I didn't think of this earlier when we were discussing the problem. It should have been obvious to me.

You should be able to "sets" the _signal" that links all the index-enable pins. But once they are in a net you cant "setp" the individual pins.

It should be possible in HAL to arrange for the spindle to run at constant speed if orient-enable is true and index-enable is true. (and you would need to "sets" that signal true in HAL just as you do now)

One way would be to switch-in an FF0 input on the orient PID (of you are not already using that) switched in and out by a mux2 in turn controlled by index_enable AND orient_enable.

This is already looking complicated enough for a custom component...

 

I'll change HAL to setS rather than setP for now, seems a bit more tidy.  And I'll plan on 'homing' the spindle at startup with the other axes with the little orient testing gcode I wrote.  I've already lowered the initial M3 speed so I don't make my spindle probe angry if I leave it in the spindle and spin it up to 1kRPM.

I'm not using FF0 for the orient PID.  I'm still using the lincurve to P-term you set me up with, D=160, no I-term, and no FF0/1/2.  It's working quite well now.

Oh, dear.  Can open, worms everywhere.  I think I've seen posts of your going back a number of years describing the intended spindle homing function, followed by "I've have still not got round to..."

Wouldn't it be easier to just get the spindle homing function off your plate?image missing /media/kunena/emoticons/wink.png

It's always something...
Tonight's snag: orient.

I'm finally ready to start testing my ATC/M6 remaps with the new carousel component the the Probe Basic GUI buttons.

I've got sets spindle-index-enable true in hal, so when the machine starts up it's ready to home the spindle.

Problem is that if I turn on the spindle and turn it off (i.e. a warmup), that clears spindle-index-enable to false and then orient goes to the wrong location.

I'd like some way to positively set spindle-index-enable TRUE inside my remap files, so whenever I do an M19 it forces it to use the index pin.

Connecting spindle-index-enable to motion.0.digital-out-nn didn't work: error at startup (signal already has a writer).

Someone have an idea how to force a signal (or any of the pid/spindle/encoder index-enable pins) to go high in gcode?
 
EDIT - connecting motion.digital-out-nn through an or2 to one of the index-enable pins doesn't work.  spindle.n.index-enable and encoder.n.index-enable are in/out and don't like being connected to an out signal.  And pid.n.index-enable is an in-pin, but it too doesn't like being connected to an or2 component.

You can connect to bit in/out pins using the tristate_bit component

That was magic.  Thank, PCW

net spindle-index-trigger-in     <= motion.digital-in-07
net spindle-index-trigger-in     => tristate-bit.0.enable
setp tristate-bit.0.in               1
net spindle-index-enable        <=> tristate-bit.0.out

Add an M64 P7 and M65 P7 to the start of the orient process and it works every time, from any starting point.

Can I remap M19 to incorporate the tristate function, or would it be better to create an "M119.ngc" that is my spindle orient function used inside the various ATC remapped M-codes?