M6 shuts off spindle, but no UI confirmation, and program doesn't pause

I broke a brand new (happily inexpensive!) bit today.  Right after program start, the spindle shut down, and the work kept going.  I hit E-stop, but not in time.

The culprit was code generated by kirimoto, which contained an M6 for an initial tool change.  I missed it when configuring kirimoto -- that M6 shouldn't have been there -- but even so, it should have paused.

It's reproducible -- M6 shuts down the spindle, but the program keeps going.

I use hal_manualtoolchange, set up pretty much by the book:
The only mention of tools in the .ini is "TOOL_TABLE = tool.tbl" in EMCIO.

I ran halshow, watching the hal_manualtoolchange pins, and the ioctrontrol tool-* pins.  The iocontrol.0.tool-prepare/prepared loopback flashes on briefly when I hit M6, but that's the only change I can see.  (I didn't use halscope.)

Any ideas?  Am I missing some config?
 

Oh! (replying to myself)

Reading the source for hal_manualtoolchange, I see that it's also his window is part of the AXIS manual toolchanger.the program responsible for the "This window is part of the AXIS manual toolchanger." window that shows up when I start Axis. I hadn't made the connection before. Lately that window has been appearing mostly off-screen, in a way that I can't read it. Since I always ignore it, I didn't worry about it. But now I wonder if whatever is causing that is also messing with the confirmation dialog somehow.

Clearly something to investigate.

paul

Okay, well I don't _completely_ understand, but...

There's a competition going on between the M6 command, and the M3 that happens just before it. If I reverse the order, to "M6 M3", then all is fine.

And the answer probably lies in my quirky handling of M3.

I run my machine from an RPi. As I've written elsewhere, spindle_enable is connected to a Pi GPIO output pin. That output pin is connected directly to a Pi input pin. I have a script in which gpiomon watches that pin, and starts and stops the spindle based on its transitions. It handles stop pretty directly. But when starting, it first drops the atspeed signal, then puts up a dialog asking me if it's okay to start the spindle. If I cancel, it runs "halcmd setp halui.machine.off false" to shut things off. If I hit okay, it activates the smart plug, and a couple of seconds later enables at-speed, using "halcmd sets spindle-at-speed true". I know that all sounds like a lot of chewing gum and string, but I like being explicitly asked whether I want the spindle that's about a foot away from my face to start up. (I also like it turning off automatically at the end of the job.)

Anyway... somewhere in there, if the M6 follows the M3, the spindle goes off after being turned on. It's complicated further because at-speed doesn't fully pause the program -- it will keep running until it hits a G1. So the M6 happens while at-speed is low.

It's now making my brain hurt a little. I'll just be sure there are no M6 commands in my g-code from now on.

I'm not an expert at this, but I've seen some of things you noted, and here's my take on them:
I think it makes sense that a tool change would want the spindle to stop.  I mean, unless your system can change a tool at 24,000 RPM.  My custom ATC code halts the spindle too, and waits for it to stop.  So, after M6 (tool change) you should always M3/M4 if you want that tool to turn.  To be paranoid, you should M5 before M6 too, as needed.  Remember that M6 is the tool change; the T command tells the changer which tool to prepare.
As for the at-speed signal, beware - if there's a delay in setting it, the system might not wait when it should.  I used an at-speed signal with a VFD and it didn't respond fast enough, I ended up reading the VFD's RPM and comparing that to what motion wanted.  At least a delayed "0" is still not the same as the desired 24,000.
I think it's normal for the system to allow rapid moves before the spindle comes up to speed, because rapid moves aren't intended for actual cutting.  It's only when the first G1/G2/G3/etc is seen that it knows the spindle must be ready.

Hi DJ -- nice to see you here.

Yeah, it's clear the code was wrong, for a couple of reasons. Someday I'll add proper tool-changing code, but until then I'll be more careful vetting configurations and preambles.

As for at-speed -- I'm using it because it's the only means of delaying the code during my confirmation step. It's documented as basically allowing anything to run, up to the first feed move. It's a little disconcerting watching the spindle move around and get ready before I've had a chance to hit okay. I'm surprised that there's no other positive acknowledgement signal that would delay completion of the M3 itself.