3.5 WIP: Hangprinter: Optionally allow up to 5 anchors/motors to be configured #601
Conversation
|
Nice!
I don't think we should add this precondition. Better to have an imperfect |
|
I don't think it's imposing restrictions on the users. on the contrary, it's allowing more configurations. Not all possible configurations yet, but more than before. Nothing that was previously allowed will be restricted, only more things will be allowed. In future PRs we can allow more configurations, but I'm afraid trying to get it right for all possible configurations in one go is going to be very hard, specially since I want to scale this to up to 8/9 anchors. Personally I'm most interested in the configurations with all anchors on top at this moment. So my plan was to focus on that and on adding more anchors. I'm not really sure there will be much interest in supporting pseudo-pyramids with not all the anchors in the same plane, to be honest. |
|
Moved this comment to #598, here: #598 (comment) |
Oh, I have been commenting on the wrong PR. This one is a ok 👌 |
|
Well, it applies to this one too since this one contains the other one, but, yeah, I guess better discuss it there if it's specific to that. |
jtimon
force-pushed
the
3.5-hangprinter-5anchors
branch
3 times, most recently
from
cc7c485
to
a2b32db
Compare
| @@ -342,32 +402,33 @@ inline float HangprinterKinematics::MotorPosToLinePos(const int32_t motorPos, si | |||
|
|
|||
| void HangprinterKinematics::flexDistances(float const machinePos[3], float const distanceA, | |||
There was a problem hiding this comment.
This function must take an array of numAnchors distances that must be looped over
|
Only had my phone available so only a brief review. Noticed that flex compensation isn't yet rolled into loops over numAnchors. Need to finish that before we can test on hw |
Otherwise it gets too deep. I think there's an option in eclipse to forbid this by project in format, one can config depness iirc.
jtimon
force-pushed
the
3.5-hangprinter-5anchors
branch
3 times, most recently
from
c626607
to
d0d4bd3
Compare
This is a clean generalization from 4 to N. Pseudo-pyramid because the vertices in the base of the pseudo-pyramid don't need to be on the same plane. There's no base of the pyramid as such. Better documented and cleaner thanks to @tobbelobb on github.
…etups - Change from bool to class and introduce None mode for custom (experimental) setups (all allowed) - refactor out IsInsidePyramidSides - refactor out IsInsidePrismSides - introduce HangprinterAnchorMode::LastOnTop for prism-like setups with all anchors on top - introduce a T parameter in M666 to configure the anchor mode
This allows to print square pyramids instead of tetrahedrons, at the cost of an extra motor. WIP: not everything is adapted after recent changes. See the newest TODOs
jtimon
force-pushed
the
3.5-hangprinter-5anchors
branch
from
d0d4bd3
to
b6dacd1
Compare
Yes, that's the kind of thing I mean by "Work In Progress" (WIP). But it's normal to have to rebase. When you were coding the flex stuff you had to focus on the flex stuff working and merging fine with the current branch at the time, which it did. But if you do a PR on top of #597 but completing it in the parts related to flex which this doesn't account for, that would be awesome. But if not I will have to understand these new flex parameter at some point anyway. In the case of the latest commit, I think yes, I think it's broken at the start part reserving memory dynamically. But when I break the wifi of my machine with the latest commit because I don't know what I'm doing with the memory...it gets me back to the times of opening the box for changing binaries in the SD or, worse, talkingto the printer by pronterface and an usb cable. Both mean opening the machine, sigh. Just please nobody run this code on their machine unless you want to see an error and want to take out the sd card to reinstall the binaries, which is a pain in the ass. Any tester interested in this PR should test the "previous" PR #603 which won't break your printer hopefully like this PR at this point. |
This is a rebase of a subset of #585 which can be seen in https://github.com/GloomyAndy/RepRapFirmware/compare/v3.4-dev...jtimon:v3.4-hangprinter-5anchors?expand=1
This is not complete yet though, because I just passed by the flex stuff. I hope it doesn't take me much to "complete" this PR in that sense.
The 5 anchor version must be the simplest to optionally support. 6 should be easy too, I think.
In 3.4, the first problems appeared with 7 anchors or more, because the config messages didn't fit. which I got some guidance for here: #585 (comment)
But I didn't do it because 3.5 was out and I needed to rebase.
Currently this shouldn't work for 5 anchors yet but it also shouldn't break 4 anchor hangprinters.
I didn't test anything yet for 3.5.
But it's ready for suggestion for changes from review or testing.
This PR contains the following PRs:
TODO: