@PetrKroupa related github issue:
https://github.com/Duet3D/RepRapFirmware/issues/623

T3P3 created this issue in Duet3D/RepRapFirmware open MFM intermittent connection error #623

@EducatingSavvas related github issue:
https://github.com/Duet3D/RepRapFirmware/issues/537

EducatingSavvas created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Buffering Commands Safety Concerns #537

@tkln I guess, that's not doable right now, but you could try sensorless homing for one of the motors on each tower.

@Exerqtor From the looks of what you are doing, the only thing var FilamentType is being used for is an M118 message. It's not actually affecting the filament that is being loaded, because you need that input in the M701 S"filament" command. Unless you are using this variable in other places.

Your other option would be to set the variable value in your filament specific start gcode.

Also, apparently M703 does not work in load.g, from what I have been told.

@noobydp @littlehobbyshop please look at the heater power feedforward feature. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m309-set-or-report-heater-feedforward. It's not quite what you are looking for but it may allow you to use a lower print temperature.

@oliof thanks, I understand what you are asking for now.

@dc42 Well, I guess it's time to give back my diploma...I was totally sure there is a unit that divides a full turn into 100 fractions. But I forgot the 2*Pi thing.

@gloomyandy thanks! Figured out I had to install a more recent arm toolchain

You can always use the "Seconds since time started" as your timestamp in your filename. Putting a "+" in front of state.time gives you this number.

G29 S3 P{"heightmap-"^+state.time^".csv"}

This will keep your files in order.
Then you can append the human readable timestring into the heightmap file so you'll have it.

@Mikey the behaviour is intentional. If the slicer asks for 20% fan speed but the minimum your fan can do is 30%, then you will get 30% which is the available value closest to the one requested by the slicer. If the slicer requests 30% then you will also get 30%, not 51% which is what your scheme would provide.

RRF does scale the PWM according to the X parameter that you provide, because the purpose of the X parameter is to specify the maximum PWM that you ever want to use.

@T3P3Tony No I'm not aware of it.
I just had a flashback, when RRF in the beginning tried to support laser diodes via M106/M107 commands, instead of the established codes.

@T3P3Tony No worries, I figured! But I will keep my fingers crossed 🤞

@chrishamm tested and it works great. Super fast when compared to M36. Thank you again for your help

@Merlin246 ok agreed, will move this to the firmware wishlist for future considerations.

@o_lampe Good thoughts. I'll look into the "parked tools" thing. I've just looked at my slicer and it seems that I can use a custom shape rather than a fixed rectangle, by defining it as an stl and uploading it. I'll add that to my seemingly ever growing "to-do" list. 👍

@T3P3Tony @o_lampe
Yes, have ordered new gearboxes(worm) with higher ratios to mitigate this issue.
The problem with the motors de-energizing when changing assignments still remains though.
I messed around with the firmware but couldn't produce any results.
It seems to be a firmware limitation as was said before and to move forward I've ordered a 6XD with drivers so that I can control the enable and power separately; hopefully that should be enough to get the levelling logic working reliably.

@AndMaz I hope around the end of next week.

@maczar_ I have moved this to the firmware wishlist for consideration.