@Leonard03 I'll ask @chrishamm to look at this.

@Tech_Sam03 that's because the state changes to busy when that macro starts, then back to idle when it completes.

@flopo76 your PID P term is clearly oscillating excessively. Try a lower P term (e.g. 20) and perhaps a small D term (0.01 to 0.05).

You may be better off using the Custom GCode field to command a 50mm Z move instead of letting the plugin generate the move command.

Also I suggest you change the data collection setting from "As fast as possible" to a lower value such as 500 or 1000 per second, that way you should be able to see the complete move.

@Leonard03 I suggest you open mesh.g in the DWC editor, then delete the G29 S0 line and re-type it. There could be a non-printing character in that line that line that causes it to malfunction, for example if the S0 is not being recognised then it will call mesh.g recursively.

What type of Z probe are you using?

@CaiJonas 2mm sounds like a very small window, I would expect more. I presume you have tried using different drive levels (M558.2). If you set the minimum drive level that doesn't give a 999999 reading with the nozzle touching the bed, how high can you raise the nozzle before you get a 999999 reading?

The RC1+2 firmware at https://www.dropbox.com/scl/fo/y03luwmbypirbxncla3rk/AAJFLPFsVdFylemyhkXsAac?rlkey=7cq4svp4rzl2ztdffpzq2ghjk&dl=0 may provide a larger window than RC1 does.

@moth4017 in RRF 3.5 and earlier, each floating point field in the object model is displayed to a set number of decimal places. This has some undesirable consequences, for example the C parameter in the thermistor configuration is reported as zero whereas in reality it has a small but very significant value. For this reason, RRF 3.6 reports very small values in scientific notation instead. What's happening here is that because of floating point rounding error, the final deviation is computed as a very small number instead of zero, which is why 3.6 reports it in scientific notation.

BTW if you use more probe points than leadscrews, the final deviation won't be zero, which is why we report it.

@genioluiz7 if the Erase jumper was definitely not in place when you ran Bossa, then sadly I think the flash memory of the main processor on the Duet as been damaged. The only other possibility I can think of is that the 3.3V rail is low, perhaps because something powered by it is drawing excessive current. If you have a multimeter, you could measure the voltage between the 3.3V and ground pins of one of the endstop connectors.

@LindsayC the reason is that the P parameter of M569 expects a driver ID, which looks like a float but is different. To make it easier to generate the P parameter in a macro, in recent versions of RRF we allow a float with a fractional part that is very close to a multiple of 0.1 to be converted to a driver ID. We can't say that it has to be exactly a multiple of 0.1 because 0.1 cannot be represented exactly as a binary float.

Expressions of any type can be converted to string.

@Chriss yes, that sounds like the reason. That bug is fixed in recent 3.6.0-rc firmware builds. The latest is rc1+2 at https://www.dropbox.com/scl/fo/y03luwmbypirbxncla3rk/AAJFLPFsVdFylemyhkXsAac?rlkey=7cq4svp4rzl2ztdffpzq2ghjk&dl=0 but if you use these, you will need to get DWC from the 3.6.0-rc.1 release.

@thomasvanderwal as RRF is reporting "Hardware error" I suggest you test the PT100 daughter board. The simplest way is to connect a 100 ohm resistor between the middle pair of terminals in the connector block (in place of the sensor wires that are currently connected there). That should give a reading close to 0C.