Simulate file to extract heightmap correction?

o_lampe

Hi gents,
for my multi nozzle printer I have to write a postprocessing script to apply heightmap corrections to all nozzles.
The idea is to simulate the original gcode and extract the correction values of the maintool . Then add these values to the heightmap correction of tool 2. ( which is on a different position)

The point is, if I'd add data logging commands to eg. daemon.g will they work in simulation mode, too?
Or is there a better way to calculate momentary heightmap correction values?
How difficult is it to find the heightmap-formula in the source code? (and write my own python script around it)
Any pointers?

o_lampe

@dc42 said in Query actual bed compensation from Object Model:

@carlosr you can get the mean and average deviation of the height map from the OM, but not the full details of the height map.

That's a pity, because it would make postprocessing based on z-height correction so much easier.

In the sourcecode/.../movement/heightcontrol.cpp I found newZ as the variable in question.
How could I make it visible in OM?

CarlosR

@o_lampe That would be amazing, it is what are we looking for.

T3P3Tony

@o_lampe so the issue is that you can't use the points in heightmap.csv because you need the interpolated z height at every XY position? Am I right in thinking you are printing with multiple tools, with their own Z motors, concurrently?

zapta

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

How difficult is it to find the heightmap-formula in the source code? (and write my own python script around it)

You could poke the function with a stepper motor analyzer Moving to X,Y and observing the actual Z stepper position. Also, not that in general, the function has 3 arguments, x, y, z, in case you enable the mesh compensation tapering.

Until you find the actual function, you can try interpolate the grid you find in the spreadsheet with whatever interpolation function you can find in python. I doubt if it will be that different from the Duet's function.

E.g. https://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html#d-spline-representation-procedural-bisplrep

Edit: it's possible that DWC code also has an interpolation function for display purposes but I don't know if it's the same as RRF.

o_lampe

I figured out, how to write/append OM-values to a file: (from RRF3.4.bx onwards)

echo >><filename> <expression>, <expression>, ...

where <expression> could be the momentary Z-height. With a given poll-interval, I create a heightmap over time file
Now I have to figure out, how to do that while simulating the gcode file.
Any pointers?
How does DWC tell Duet to simulate the file?

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.