Recent versions of Prusa Slicer (I'm using version 2.2.0) insert the estimated print time in the form of a comment that looks like this:

; estimated printing time (normal mode) = 38m 31s

dsf 2.1.0 contains the following regular expression:

"estimated printing time = ((?<h>(\d+))h\s*)?((?<m>(\d+))m\s*)?((?<s>(\d+))s)?"

but this does not work with recent versions of PS (because of the extra "(normal mode)", not inserted in earlier versions). A modified version that does match (and that should still match older strings) is:

"estimated printing time .*= ((?<h>(\d+))h\s*)?((?<m>(\d+))m\s*)?((?<s>(\d+))s)?"

Note the additional ".*" just before "="

In addition it is common for the start up gcode used with this version of PS to contain the following line:

M221 S{if layer_height<0.075}100{else}95{endif}

This line gets included in the gcode file (as a comment) by PS, but it causes a false match against the DSF layer height matching regular expression:

"\slayer_height\D+(?<mm>(\d+\.?\d*))"

and results in the layer height being shown as 0.07mm rather than the correct 0.20mm. The following modified version seems to avoid the false positive and returns the correct layer height:

";\slayer_height\D+(?<mm>(\d+\.?\d*))"

Note the extra ";" at the start of the string.

I've tested the above modified expressions with a number of versions of PS (going back a year or so) and it seems to match values correctly in generated files.

A few thoughts that you may or may not be aware of....

You might want to run multiple iterations of your auto tram code rather than just one (check the adjustment made each time it should converge to very small changes). I typically run three iterations. One thing to check is that the two points you are using in your auto tram should have pretty much the same height in the height map, it is hard to be sure but that does not look to be the case in your map. Also it is important to follow the same steps when creating the height map as when applying it, so if you auto tram, home z, apply map, you must do auto tram, home z, build map. Doing auto tram build map (no home Z) may give you different results. Oh and the same applies to heating the bed, make sure you give it long enough to come up to full temperature all over the bed before you auto tram and generate the mesh, then do the same when you print. In your test print case if you just printed from cold (using the default code to heat the bed and wait for it to come up to temp), it may not have heated through by the time start to print, so if you generated the map after the bed had been heating for some time, the bed and map may not match.

Thanks, let me know if you need any more information. @jay_s_uk has reproduced this with a Duet3 so it looks like it is not LPC1768 specific.

Is there any chance that the case is pressing on the glass screen? I managed to damage a 5" screen when I put it in case. There are tracks that in effect are on the glass and very close to the edge, it is easy to damage them. Perhaps the temperature change is increasing/decreasing pressure on parts of the screen?

Ouch, setting hard sounds bad! I'd hate you to ruin the thermocouple or the nozzles! I was thinking more of the heatsink compound used on PC heatsinks, which I don't think sets hard (but I have no idea if that can be used at the temperatures we are talking about here!).

I wonder if filling the nozzle with thermal paste might help in both cases and also act as a filament substitute? Obviously it will not be flowing like molten plastic, but it might improve the thermal contact and will also prevent any airflow?

Interesting test. A couple of questions/thoughts. Did you take any steps to ensure that the sensor made good thermal contact with the material of the nozzle and that the same thermal contact was maintained for the different nozzles? Is the nozzle open to the air at the tip (and if it is what happens if you block it)? If the nozzle is open it could be that there is airflow through the nozzle (or even just inside the tip of the nozzle) that may be cooling the sensor/inner walls of the nozzle tip. If any direct air cooling like this is taking place it could be that it varies depending upon exact nozzle shape and/or the position of the sensor and wiring withing the nozzle.

Your gcode has some very long comments in it. See: https://forum.duet3d.com/topic/16221/dsf-2-2-0-long-comments-in-gcode-causes-an-exception/7

You may be able to work around it by editing the gcode files and deleting the long comment lines.

For now I'd just run it multiple times and look at the output to see if it is converging (you should see the corrections getting smaller each time). If it isn't converging then there is probably something wrong (either with the configuration or some sort of mechanical issue).

What happens if you run G32 multiple times, do the corrections converge? It is usual to have to run more than one iteration to get a good result.

Ah that makes sense! Thanks for the info Chris.

@chrishamm Thanks makes sense to me. May I also ask what the thought is behind sensing comments to the firmware? I assume there must be some situations in which the firmware interprets them in some way?

Thanks, let me know if you need any more information. @jay_s_uk has reproduced this with a Duet3 so it looks like it is not LPC1768 specific.