Advanced Search

Hello everybody!

The 3-axis machine I'm trying to retrofit has a tool setter button fixed on the bed, as well as a spindle Z probe, and I'm trying to make it work (using qtdragon, if that matters). I don't know the length of the probe, and I don't want to use a fixed value for it due to the possible spindle clamping variations, so I'd like to measure it against the tool setter before every probing routine.

In order to do that, I need to move the probe down until BOTH the probe and the tool setter contacts are closed, to compensate for the probe's action distance. In other situations - probing the stock or setting the end mill length - I need the machine to go until EITHER of the contacts is closed.

The issue is, there are no separate HAL pins to feed the tool setter and the probe signals into, just motion.probe-input. I can combine the signals with or2/and2 and it works for one of the scenarios, but obviously not for the other.

How do you folks solve that? I can't imagine I'm the first one with this question, but digging the forums did not produce anything helpful for me.

Thanks in advance!

 

Reviving this from the dead, as I once again ran into this same issue in my tool changer routine.  Clearly, my original "fix" of just not running the spindle in my M6 remap was just a workaround, not an actual solution.  In my tool changer routine, I was (of course) stopping the spindle via M5 prior to changing tools, and this was causing it to wait on the first G1 move.  I'm not willing to change that to a G0 because I don't want the machine slamming tools in and out of their pockets at full speed.

I haven't been able to easily find a crystal clear definition of this in the official docs, but numerous sources have led me to understand that after each commanded spindle speed change (including stop/start), upon encountering the next feed-rate move (e.g. G1, G2, G3 and probably others) the motion controller will wait for spindle at-speed to become true.  This wait will only occur once after each spindle speed change (i.e. subsequent G1/G2/G3's won't wait) and does not apply to rapid moves (G0).

One aspect that made this issue more insidious and appear to be more elusive during troubleshooting is that it doesn't behave the same when commanding things manually via GUI or MDI, versus when running an actual program in Auto mode which contained tool changes.  I'm guessing that whatever internal flag is associated with this one-time wait gets reset each time execution stops after a manual command.

This behavior is logical enough in the context that G1/G2/G3 are meant to be "cutting" moves whereas G0 rapids moves are not.  However in the context of a tool change or probing or similar, a controlled feed rate while NOT cutting is desired, and there is no such thing as a non-cutting controlled-feedrate g-code command in linuxcnc to my knowledge.

Fortunately, I found a way to fake it out:Thankfully, based on my testing, a zero-distance G1 move seems to be interpreted as a no-op but still consumes the one-time wait.

Adding this before the first "real" G1 move in my tool changer routine has eliminated this issue - at long last!

Other thoughts I had on alternative ways to work around this include:
1) add side-channel logic between the motion and spindle controllers that can stop the spindle without actually changing the commanded spindle speed via G-code (M3/M5 or S commands), so the one-time wait doesn't get triggered in the first place.  This could still be sensitive to this issue if the user g-code program happened to trigger the one-time wait just before triggering the remap subroutine(s).
2) add side-channel logic to fake out spindle at-speed (hold it true) for the duration of the subroutine even when the spindle is stopped.
Both of these options seem more risky to me because of the possibility of getting into a bad state in the event of an error in the subroutine and returning to the user program with the normal spindle control still bypassed in some way, but just throwing them out as food for thought...