Simulate file to extract heightmap correction?

T3P3Tony

@o_lampe https://duet3d.dozuki.com/Wiki/M37

fcwilt

@o_lampe said in Simulate file to extract heightmap correction?:

Hi gents,
for my multi nozzle printer I have to write a postprocessing script to apply heightmap corrections to all nozzles.

I'm confused.

Why doesn't the existing height map apply to the currently active tool?

Thanks.

Frederick

o_lampe

@fcwilt
It does. But there are two toolheads/nozzles busy at the same time at (very) different places. (and another two, when I switch tool)
I could either print without mesh leveling and hope the best or do it right and allow each toolhead to adjust it's own (mini) z-axis.
Therefor nozzle "B" needs to know where nozzle "A" is ( at least it's current z-height) and add this delta-Z to the z-height of it's own position.
That's only possible with a post processing script for now. Hence the question about the gcode simulator: it doesn't make sense to run gcode for nozzle "A" in realtime, just to extract the z-height. In fact, I'd like to use a much faster CPU for that. (SBC for instance)

o_lampe

@t3p3tony said in Simulate file to extract heightmap correction?:

@o_lampe https://duet3d.dozuki.com/Wiki/M37

Thanks a lot Tony! Now I need to figure out, if daemon.g still runs while simulation mode is ON.
That will also be helpful for collision detection between two toolheads.

fcwilt

@o_lampe said in Simulate file to extract heightmap correction?:

@fcwilt
Therefor nozzle "B" needs to know where nozzle "A" is ( at least it's current z-height) and add this delta-Z to the z-height of it's own position.

What does the Z position of A have to do with the Z position of B?

Doesn't the needed Z adjustment for each depend on the height map and the XY position of each?

Thanks.

Frederick

engikeneer

@fcwilt he has a main z axis which will be moving either the heightmap for tool A, then a second mini z axis for B. So B needs to dona heightmap correction that is the difference between the two for the two tool positions

fcwilt

@engikeneer said in Simulate file to extract heightmap correction?:

@fcwilt he has a main z axis which will be moving either the heightmap for tool A, then a second mini z axis for B. So B needs to dona heightmap correction that is the difference between the two for the two tool positions

So the Z position of B depends on both the main Z axis and the "mini" Z axis?

Thanks.

Frederick

zapta

@o_lampe said in Simulate file to extract heightmap correction?:

Then add these values to the heightmap correction of tool 2. ( which is on a different position)

Do you plan to use the two tools at the same time?
Do you have motors to adjust the Z heights independently for the two tools?

If you use one tool at the time, can you load on tool change a different height map with x, y shifted with the tool offset?

o_lampe

@zapta It's in the stars when we'll have multi-stream gcode, but I'm already preparing for it.
The hashPrinter has two pairs of toolheads able to work independently and simultaneously. Until independence day , I can still use them the classic IDEX/toolchanger-way: one tool at a time; each one has fixed offsets => no problem with mesh leveling

My IDEX printer has a toolholder with a dovetail slider, which has proven to work. Based on that, I want to add a small motor or servo to each slider to adjust it's z-height.
On the hashPrinter I'm already running out of stepper-drivers (11 steppers so far), so I'd prefer to use something else to drive the mini-Z
I've posted a pic here

@engikeneer said in Simulate file to extract heightmap correction?:

@fcwilt he has a main z axis which will be moving either the heightmap for tool A, then a second mini z axis for B. So B needs to dona heightmap correction that is the difference between the two for the two tool positions

That describes it well, but it might be easier to implement mini-Z axes, when all tools have one and the main Z-motors are used for layer change only.
The firmware would then split z-motion:

No Z-coordinates in a gcode line = mesh leveling or Z-hop (retraction)
A gcode line contains Z coords = layer change

engikeneer

@o_lampe if that's the case, it it should be pretty 'easy' to split up your sliced files into 5mm max segments and apply mesh comp as an extra 'C' axis etc for each head? Granted its all gonna need post proccessing, but it removes any interdependence between the nozzles. Might also allow you to use different maps for the different heads (e.g. if the gantries sag differently etc)

There's a few python libraries that do 3d spline interpolation pretty well (I've used then in my day job). You can usually switch between the interpolation method too (linear, spline etc)

o_lampe

@engikeneer said in Simulate file to extract heightmap correction?:

split up your sliced files into 5mm max segments and apply mesh comp as an extra 'C' axis etc for each head?

You're right, I haven't thought about the consequences, when they all have their own mini-Z: they don't need to know from each others Z-height! But the main problem stays the same...
I still need to extract z-height for every segment and rewrite it either as ABCD stepper command or use Hobby-servos. (remotely with pull-pull application)

Would be cool if it already came segmented from the slicer.