Multiple Z probes and multiple Z axis for IDEX

fcwilt

@moe-adams9093 said in Multiple Z probes:

@fcwilt well I do have a solution for that what if I place a small stepper motor on each extruder as a completely additional axis That can lift and drop the nozzle as it needed to compensate completely separate from the Z axis. Well the firmware allows to do that.

Make a post in the firmware wish list category.

It sounds like it would be a good addition.

Frederick

moe.adams9093

@phaedrux So basically this how it should work during homing commissioning tool 0 should determine the Z min and command G32 for tilt compensation . For mesh bed leveling G29 let’s say on tool 0 there is A axis and tool 1 B axis These axis will be controlled by a stepper to do the lifting each axis should have its unique probe and it’s own SVG file for mesh bed leveling so that way it will allow accurate compensation for both extruder independently while both printing. So basically all I’m asking if the firmware can activate command g29 to be routed to additional axis or drivers. Thank you

fcwilt

@moe-adams9093

You would only need a height map for each tool if each tool exhibited significantly different Z errors from the other tools.

Hopefully that is not the case.

If the tools had little to no differences then one height map would suffice to inform the firmware about bed irregularities.

And you still would need independent Z adjustments for each tool which the firmware cannot currently do.

Please make a post into the firmware wish list category describing your goals without worrying about exactly how it could be achieved.

Frederick

moe.adams9093

@fcwilt thank you

o_lampe

@moe-adams9093
I've asked this several times before and called it "mini-Z axis". A separate motor (or servo) driving the extruder up/down.
It's easier to implement when all toolholders have their own mini-Z motor. The real z-steppers only run on level change, but z-hop and meshlevelling is separate.
Unfortunately there is no way to poll the momentary z-position (internally called newZ) from the object model. Otherwise it would be possible to simulate a gcode file, extract newZ and write a post processing script to re-map the z-correction to a different axis (individual mini-z motor)

dc42

To implement this, I think the two mini Z axes would need to be configured as new axes, for example V and W. You would need to home them in some way, then set them to mid position (probably best to make V0 and W0 the mid positions).

You could use the slicer post-processing facility to change the retraction and reprime commands to use them for Z hop. Or we could change M207 command to allow axes other than Z to be used for hop.

To use them for mesh bed compensation, we would need to implement the following:

Support using an axis other than Z to apply the compensation.
We already support using axes other than X and U to define the grid, so using U and Y for one would not be a problem.
Support applying two height maps at the same time.

I will put this on the wish list for RRF 3.5. It would almost certainly be supported on Duet 3 only (including 3 Mini), due to shortage of flash memory space on Duet 2. Support would be for stepper motors only, not servos.

o_lampe

@dc42 said in Multiple Z probes and multiple Z axis for IDEX:

Support applying two height maps at the same time.

I agree with most of the above and can't wait to test it on my hashPrinter, but it might be necessary to have 4 heightmaps.
With the new found solution to probe the bed only where the print objects are, I guess it will not be overkill.

@dc42 said in Multiple Z probes and multiple Z axis for IDEX:

Support would be for stepper motors only, not servos.

I've written code for ATTiny MCU to run dc-encoder motors with step/dir/enable signals. I think it's much easier to do the same for servos.
Only drawback would be the unflexible stepper-pin assignment on Duet3 hardware. (the STM port uses a board.txt file to define new steppers from 'any' GPIO pin)
I'm thinking of a toolboard with one onboard driver and some GPIO pins to define the extra mini-Z motor.

moe.adams9093

@dc42 awesome that’s exactly what we’re looking for this feature or implementation should solve most IDEX specially when we’re dealing with large build volume. Thank you

dc42

@o_lampe why 4 height maps?

o_lampe

@dc42 said in Multiple Z probes and multiple Z axis for IDEX:

@o_lampe why 4 height maps?

Worst case is: 4 tools working in copy mode on my hashPrinter.
Usual case: 2 tools working simultaneously, with 2 other tools idle. (switching tools and their heightmaps back and forth)

I guess, I could get away with only one heightmap, but more is better, especially with low 1st layer height.

fcwilt

@o_lampe said in Multiple Z probes and multiple Z axis for IDEX:

I guess, I could get away with only one heightmap, but more is better, especially with low 1st layer height.

So for a given XY location there is a lot of Z variation between tools which would preclude using a single height map?

Frederick

o_lampe

@fcwilt
I hope not!
But every tool runs on a different pair of V-slot extrusions, which might or might not be perfectly straight and aligned.
For now I have only one Z-probe and heightmap, but the plan is to add a probe to every tool, if only for the purpose to do a single G30 for each tool.

moe.adams9093

@dc42 said in Multiple Z probes and multiple Z axis for IDEX:

We already support using axes other than X and U to define the grid, so using U and Y for one would not be a problem.

Is it possible to add one more axis to define grid such as V because the new machine I’m designing it should be coreXYUV with double gantry where it can print completely 2 different model at the same time