Updates Hangprinter support

[tobbelobb]

Hi, I just rebased my code that I run in the simulator onto 3.7-dev. In this PR I've extracted HangprinterKinematics.{h,cpp} from my RRF fork and made it compile nicely with your upstream 3.7-dev branch in the various involved repos.

It includes

 - Adds the missing Hangprinter registration so M669 K6 maps to a real kinematics.
 - Implements new flex compensation for Hangprinter
 - Hangprinter: new quadratic forward transform
 - Hangprinter: all anchors drives control of all moves
 - Hangprinter: Removes the M669 K-anchor to avoid name clash
 - Hangprinter: allow board address up to 49.0

See it running in the simulator at https://tobbelobb.github.io/hp-sim5/hp-sim-3d/

[tobbelobb]

Added the commit that allows one force for each motor, like M569.4 P40.0:41.0:42.0:43.0 T1.0:2.2:0:11.

I have two other features that I've ommitted here. Tell me if you want them.

• The RRF_HOST_BUILD for a x86 version of ReprapFirmware.
• Caching driver directions that gets sent to remote drivers upon M569 S.... Without this (or a way to ask the remote driver) we need to hard-code motor directions in HangprinterKinematics.cpp. I included a small hard-coding patch in this PR's HangprinterKinematics.cpp, so we can avoid the direction caching if you don't want it now.

[dc42]

Thanks for your PR.

1. Please can you explain why you added the zero initialisations in MovementProfile.cpp. They are not needed because those variable are only read after foundSolution has been set to true. gcc is normally very good at warning about reading of possibly-uninitialised variables (some of which are often false positives) but it doesn't for this file. We are using gcc 15.2.
2. Please explain why you need to know the motor direction settings. Is this something to do with using ODrive?
3. I am interested in RRF_HOST_BUILD. I suggest that when I have agreed and merged this PR and perhaps added the driver direction caching, you update your branch from 3.7-dev, then we find a good time for you to submit a PR (when we are not making other changes to 3.7-dev).

[dc42]

PS - if we are going to cache the direction setting for remote drivers then the way I would like to do this is to add the direction setting to class DriverData (see src/Movement/StepperDrivers/DriverData.h) so that we can include it in the object model. Is that the way you have implemented it?

[tobbelobb]

1. Ah, it seems like I used gcc 12.2.1. I just initialized those variables because the compiler was emitting a warning and all warnings were being treated as errors. I installed gcc 15.2, reverted "Initializes some variables for clean compile" and the build was indeed clean without those new initializations.
2. Motor directions are used when setting torque mode with M569.4 and when reading encoder values with M569.3. For now it's only implemented for ODrive, but I expect to implement M569.3 and M569.4 support for one more external driver board soon.

The Caching: I had put it in ExpansionBoardData. I changed that now to cache them in DriverData instead. I also added a commit that exposes driver directions in the object model.

[tobbelobb]

Oh I should have fetched first. It seems you already implementet the caching in DriverData?

[tobbelobb]

There was a lot to untangle there but I think I've got it all corrected now. It builds and runs cleanly in the RRF_HOST_BUILD + simulator, both the gcode terminal (http server mode) and the full gcode execution path. It also builds cleanly for the Duet3_MB6HC target in Eclipse.

[tobbelobb]

I'm looking forward to assist in getting RRF_HOST_BUILD into upstream. It's been a real game changer for my RRF related workflows

[dc42]

Hi, please review my suggested changes.

[tobbelobb]

Done. 👌 Just let me know if you find more things to fix before merge

[tobbelobb]

@dc42 Any news on this PR's status?