Dust Collection Shoe with independent Z control

I love Marius's channel and would like to replicate his dust collection shoe . It has a "Z axis" that is independent of the tool's Z axis movement, enabling finer control of the dust collection and air nozzle placement. However, in my design the dust shoe "Z axis" isn't referenced from the gantry, but from the tool plate itself.

I have attached two views of my dust shoe (with two tubes) and spindle with collet (no tool). One with the dust shoe extended, and one with it retracted for changing tools.

I have a homing reference switch on the dust shoe axis as well as the Z axis. When the dust shoe is fully retracted and Z is fully retracted (moved up) I know the distance from the bottom of the dust shoe to the top of the workpiece. My question is, what is the best way of controlling the dust shoe axis independently? My thought has been to add another real time thread that controls the dust shoe, but this thread would also need to have constant knowledge of the “raw Z value” (which I think is Z value in machine coordinates?) as well as the state of program (eg. cutting, or changing tools).

Another idea I had was to add some extra post processing of the gcode, but I feel much less comfortable with gcode (and understanding the various caveats/intricacies) than I do with multithreaded C/C++. My worry (with this latter idea) is that I miss what coordinate system is being used and muck up the correct dust shoe height. More importantly, it feels cleaner to not have to mess with the gcode for controlling dust collection.

Thanks in advance!
Finn




 

Fantastic, that's an even cleaner solution. Thank you!

Looking at the HAL solution further, would that not fix the W axis to always be dependent on the Z axis?

I don't always want the dust shoe to be extended fully, such as when changing tools it needs to be retracted, or moving rapidly I'd want to pull it off the work piece slightly more.

Could I create something conditional in HALTCL? Also, what's a good way to "know" from LinuxCNC when the CNC is cutting? I was considering remapping M7.

Thanks
Finn

Seeing your post regarding IF statements in HAL  it seems this is not possible. I take it HALTCL is more of a parametric way of setting up HAL, not a method of adapting HAL during execution.

I did however come across MUX  which takes in two float values and assigns either to an output based on a pin input (mux2.N.sel). I'm thinking I can map an M1xx code to mux2.N.sel in HAL. That way I can use gcode to control if:

1. axis W (joint 4) is controlled based on a negative sum of axis Z (joint 2) like you mentioned, or
2. to fully retract (zero or home)

Next step is how to control that behavior. Initially I was thinking about remapping M7 and M8 but that doesn't seem possible . Maybe I'll remap O (spindle control).

A couple of questions:

1. I've read about position prediction . Does the HAL sum2 mapping solve for that? Ie. if Z decelerates in anticipation of a new gcode command, W will match that motion.
2. Are there any potential caveats with remapping the O code? I've read some about execution sequencing and modal groups but don't fully understand.

Thanks again
Finn

I have also created a shoe using  the W-Axis. I'd be interested in knowing how you implemented yours.
I have the W-Axis riding on my Z-Axis with printed parts that I created and a NEMA17 driving the shoe.
I can home the W-Axis without any problem but, I'm not certain of next steps other than what functionality has been mentioned 
in this thread.

The one thing that is different on my setup is the W-Axis is actually mounted to the Z-Axis so it will move with the Z-Axis as well as move
up and down. My intent is to simply use an offset but, like mentioned would like to have over-ride control for tool changes, etc....

Any best practices or feedback for such implementation?

Thanks Andy.

GW:
You've got pretty much the exact same setup as me re. W on Z.

I took a long break on dust collection but am back at it and only a couple weeks from testing. I'll post my results.

I haven't tried running a job yet but, what I am going to test is as follows:

I wrote a few lines of code into my POST that simply negates the position of my Z-Axis and applied that to the W-Axis.
I included the min and max positions for my W-Axis and if the setting goes beyond those parameters
I just zeroed the W-Axis. Realistically my W-Axis should never go out of the min and max.

I'm sure that I'll need to tune it or even make changes.