[1.1.x] Hangprinter support

[tobbelobb]

…for saving anchor locations in eeprom, and new defines.

New gcodes:

• G6
• G95 (torque mode)
• G96 (mark encoder reference point)

Adapted gcodes that still use XYZE parameters:

• G0/G1 (inverse kinematics)
• G92

Adapted gcodes that use ABCDE parameters:

• M92
• M201
• M204
• M205
• M906

Adapted gcodes with other parameters

• M665 (set Hangprinter anchor positions)
• M114 S1 (read encoder mm movement since reference point was marked)

New features that also work on non-Hangprinter machines:

• UNREGISTERED_MOVE_SUPPORT
• MECHADUINO_I2C_COMMANDS

Features that are Hangprinter specific:

• LINE_BUILDUP_COMPENSATION_FEATURE

Other changes:

• Uses NUM_AXIS[_N] and MOV_AXIS instead of XYZE[_N] and XYZ for indexing and initializing arrays that refer to kinematic axes (movement axes on physical machine) rather than the cartesian axes of incoming gcode.
• Uses E_CART instead of E_AXIS for indexing arrays that refer to cartesian axes of incoming gcode.

Discussion ahead of this PR: #9101

[tobbelobb]

Synced with upstream/bugfix-1.1.x, fixed issue found during travis check and squashed.

[thinkyhead]

Looks good! It's almost ready to merge. I just need to go through it over the next few days to absorb all the changes. I will post review questions in the code. Once it's prepped to merge for this branch, we'll put together the same for 2.0.x. I hope to get this merged relatively soon so it won't go stale.

With the addition of E_CART I'm tempted to replace appropriate instances of X_AXIS (Y,Z) with X_CART for consistency…

[tobbelobb]

Agree that X_CART, Y_CART, Z_CART for consistency would be a good thing. It's very easy to trip when listing up" X_AXIS, Y_AXIS, Z_AXIS, E_.... CART".

[thinkyhead]

I'm thinking that for now it would be cleaner to always assume X_AXIS == X_CART (and Y, Z) and keep using X_AXIS/Y_AXIS/Z_AXIS when referring to the XYZ G-code inputs, rather than immediately induce head-scratching with X_CART as if it were distinct. For our purposes it's a reasonable synonym.

On the planner side, we already have A_AXIS/B_AXIS/C_AXIS to refer to 3 post-kinematic axes, and a D is available to shunt in before E, if wanted.

[tobbelobb]

Copy/pasting in parts of my comment from the previous thread here for reference.

I don't like E_CART, but had to make a trade off. Alternatives I considered:

• Order axes like {A_AXIS, B_AXIS, C_AXIS, E_AXIS, D_AXIS}. Breaks the assumption that motors are lined up like [X/A_AXIS + i] and extruders are lined up like [E_AXIS + i]. I found this assumption in a few different places. It's would also give us trouble the day want to add a fifth motion axis, and a couple more extruders, which is not unlikely.
• Separate names of "cartesian" axes and kinematic axes, like {X_CART, Y_CART, Z_CART, E_CART}, {A_KINE, B_KINE, C_KINE, D_KINE, E_KINE}. Feels like a proper conceptual distinction, but adds work and would be a bigger change with the same practical drawbacks as only introducing E_CART.
• Make completely separate arrays/variables for extruder parameters everywhere, so E_AXIS/E_CART wouldn't ever be needed. This would allow fifth and sixth motion axes, along with additional extruders, to be easily added, but it would take some more work to implement.

I'm in favour of splitting all arrays that contain both kinematic axes and extruder axes later, maybe not in this PR. As you say, keeping X_AXIS and E_CART as they are in the PR for now is the least work intensive and least headscratch-causing option in the short run.

In the longer run, some Hangprinter users might scratch their heads if E_AXIS is used in place of E_CART, which will cause "index out of bounds" error for them. Could maybe be easily exposed by the travis-script if it runs a test compilation using example_configurations/hangprinter/Configuration.h ?

[fiveangle]

This is a brand new feature that never existed in Marlin before. Maybe it would be easier for @tobbelobb to support if only in one branch ? Otherwise, you'll have some people on 1.x and others on 2.x. Seems a bit messier with not along of benefit ? 🤷‍♂️

[tobbelobb]

How is it going with the code review? Have questions come up that I can help sort out?

[thinkyhead]

@fiveangle Likely this will only be merged to 2.0.x. But it's easier for some to develop for 1.1.x and then move it over afterward.

[teemuatlut]

What was the change to M906? I don't see any mentions to hangprinter in it.

Also don't forget to update all the other the config files too.

Will E_AXIS be a valid macro after this?

[tobbelobb]

Synced with upstream.

@teemuatlut You're right, the former M906 code would just have put D-current == E-current. Updated M906 to take ABCDE parameters and set a separate D-current.

E_AXIS will continue to exist, but change value (from 3 to 4) when the HANGPRINTER option is enabled. Arrays that refer to XYZE (coordinate system assumed in gcode) should use E_CART instead. The arrays current_position and destination are the most important such arrays. So

current_position[E_CART]
destination[E_CART]

will work. But

current_position[E_AXIS]
destination[E_AXIS]

will break Hangprinter compatibility.

@thinkyhead I'm about to implement a few more Hangprinter features. Since Hangprinter won't be merged into 1.1.x anyways, can I push new features to this branch (bugfix-1.1.x_hangprinter branch on tobbelobb/Marlin)? If yes, then commits will show up in this PR, and I will be saved from a lot of extra rebasing and branch bookkeeping whenever I sync with upstream.

I guess keeping this PR (or another thread where I can keep you up to date and answer questions about Hangprinter code) alive is a good idea.

[tobbelobb]

EDIT: The reason for Travis build fail seems to be the thing that is fixed in #9302

[thinkyhead]

@tobbelobb For an extra collaboration channel you can send me a request to connect to the Marlin project on Slack. See #9154 for details.

Don't worry about making the transition to 2.0.x while you're in the zone getting things patched up and improved here. My thinking was that once it was ready I would quickly port it over to 2.0.x — a process which is pretty quick and painless … usually — and then we would go from there. So carry on as usual.

It's true that we'll be closing some other PR's targeted to 1.1.x shortly. This one should stay open while it's underway, and just let me know when you feel it's top notch and ready to move over.

[tobbelobb]

I think maybe this should be merged now. It's very hard to get something like this top notch in the first try, so please bear with me. It works on my setup and has been used both for printing and auto-calibration.

It would be very good if you could look for mistakes that could break UX for cartesian printer users in there.

This is a tad nervous, but the PR is now so big that keeping up to date with upstream is eating into my time budget.

[ghost]

I just discover what is hangprinter ... or spiderprint or aracnea printer , it's pure madness ....
I have seen videos on youtube , and the first thing I imagine , is the size limitless ......
Are you on Youtube ?

[tobbelobb]

My Youtube channel is here: https://www.youtube.com/channel/UCw1Nz0VCw4z-dfq4WjSkFzQ

[tobbelobb]

Hey @thinkyhead, there were some more new breaking changes there, but I patched it all together again and squashed.

Testing the new patched version on hardware, with Hangprinter and all the other options enabled takes a few days. Within a few days, breaking changes are merged upstream, and I'm caught in a never ending interrupt loop. So I have to ask you to take a chance.

Can you please merge this now?

[tobbelobb]

Research is being done on adding computer vision feedback and also physically modelling to predict line flex (like this). Getting onto Marlin v2 and 32-bit controllers will boost our progress.

[ghost]

@tobbelobb Damned !!!!! ......... 😨

[thinkyhead]

you must trust that I won't break your users' experience, and that I will come back and fix the bugs

It's not that. It's just that while we're working on figuring out the stepper stuff, I don't want to break the flow for the various contributors working on the planner/stepper code by replacing XYZE_N with NUM_AXIS_N and so on. Let us get past this layer shifting and stepper timing issues with the code we have before we introduce a new axis.

Also, a long time ago in this thread I explained that this won't be going into 1.1.x but only into 2.0.x.

[thinkyhead]

I was told to use bugfix-1.1.x, and in a rather... direct tone.

Correct. I assumed this would also be easier for all concerned. And I explained that I will take care of the adaptation to 2.0.x to save you the effort of re-orienting to the new code-base, since you have been working with and are most familiar with 1.1.x. The 2.0.x codebase has also been in a lot of flux. But if you're comfortable with the 2.0.x layout, then of course you can work with that instead if you prefer.

[tobbelobb]

I can see where the anxiety comes from, but I think I'm less worried than you. Supporting Delta printers has already forced you to make the following distinction for a while:

gcode coordinates -> inverse transformation -> actuator coordinates

This means no, or very little, planner/stepper code carries the assumption that actuators are linear and laid out along Cartesian axes.

The assumption that there are exactly 3+extruders actuators is silently removed by this PR. If other programmers forget/don't care/don't know, that's not too bad. Only Hangprinter users will ever notice, and it's very easy to fix. Anyways, you've invested a lot to get ordered, sequential removal of the 3+extruders assumption, and seem eager to avoid any confusion.

When/if there comes a time for removing the assumption properly and orderly, I suggest you separate arrays with a naming convention. Arrays associated with the incoming coordinate system all start with cartesian_. Arrays carrying per-actuator associated parameters gets names starting with actuator_. So you'd get array names like cartesian_axis_codes, cartesian_destination, actuator_position, actuator_target. Going all the way with enums like CART_X, ACTU_A, CART_E, ACTU_E would also help.

If you have more programming time you could put parameters for tool head actuators in their own arrays, so parameter indexes can't ever accidentally overlap. It would also allow each tool head to be controlled with more than one parameter.

And if you're ready to go out of your way to support exotic geometries like the Hangprinter properly, all references to xyz in motor/actuator names should be replaced with generic names, like numbers, so STEP_PIN_0 instead of X_STEP_PIN etc.

I would prefer a quick, small, and stealthy assumption removal, and just absorb the small amount of resulting confusion and/or bugs. You preserved those other contributors' flow by completely destroying mine over and over, but making those decisions is of course your job as a coordinator. I'm sure they would have complained to you about the disappearing 3+extruders actuators assumption some time had you prioritized Hangprinter. Good bye and good luck.

[thinkyhead]

Alas, every project has its methodologies, rationales, and quirks. Remember that all the volunteers on this project are working in their spare time and for the joy of it, and we are dealing with dozens of ongoing issues. We don't mean to offend anyone with our foibles. I've certainly tried to be open, helpful, and accommodating during this overlong bug-hunting period. I hope that counts for something. You seem like a nice young man. I hosted Tom Sanladerer at my home recently, and he also had kind things to say about you. I hope we can all continue to work together in harmony to improve the state of the art as time goes on.

[thinkyhead]

I've rebased and updated this for the latest code in bugfix-1.1.x. I was super cautious and went over each change twice several times, so I expect it to be as good as ever. Of course, there may have been changes during the planner/stepper overhaul that still use XYZE, etc., where for Hangprinter they should use the new defines. I didn't dive into the planner/stepper to search for those.

This can be merged to the bugfix-1.1.x branch anytime if it all functions properly. We might end up doing a 1.1.10 release at some point, as there have been a number of critical fixes to the 1.1.x codebase since Aug 1.

I'll aim to port this over to bugfix-2.0.x tomorrow. Everything should port over to 2.0.x pretty much verbatim, since these codebases have been kept closely in sync.

Thanks for your patience and continued corrections. It's a privilege to be able to include support for the Hangprinter in the main Marlin project and it'll be great to have it working for 32-bit boards.

[thinkyhead]

@tobbelobb — This is one of the new changes I wasn't sure how to adapt to HANGPRINTER. UBL leveling is applied to the C axis when directly setting the position in the planner. This is only needed for UBL, and not the other leveling options, because it is unique in not being tightly-integrated in the planner. Seems to only apply to Cartesian, though, so it's probably not needed for HANGPRINTER.

[tobbelobb]

Woah UBL is quite a big feature! I'm not sure if I understand your comment, and I can't find the file with the full referenced source code.

Does UBL transform not take cartesian coordinates as both input and output? I would guess that bed leveling worked only on the Cartesian side of things, like having this in Marlin_main.cpp:

float current_position[XYZE] = { 0.0 };
float uncompensated_current_position[XYZ] = { 0.0 };
float destination[XYZE] = { 0.0 };
float compensated_destination[XYZ] = { 0.0 };
...

void gcode_get_destination() {
  ...
  LOOP_XYZE(i) {
    ...
    if(ubl_enabled){
      destination[i] = uncompensated_current_position[i];
    } else {
      destination[i] = current_position[i];
    }
  }
}

void prepare_move_to_destination(){
  ...
  if(ubl_enabled){
    line_segmentation_scheme_similar_to_prepare_kinematic_move_to(){
      ubl_transform(compensated_destination, destination); 
      prepare_move_to(compensated_destination, destination[E_CART]);
      set_uncompensated_current_from_destination();
      set_current_from_compensated_destination();
    }
  } else {
    prepare_move_to(destination, destination[E_CART]);
    set_current_from_destination();
  }
}

This way, the ubl would be independent of kinematics. You would also be free to define ubl_transform() as any [x, y, z] -> [x', y', z'] mapping. In particular, you can use on that is class C1 smooth (differentiable). The segmentation scheme could fade out at increasing Z on Cartesian machines.

The output of M114 would be a tad more complicated, like

>>> M114
Ans: This is the position set via G0/G1/G92: [..., ..., ...]
     Internal position is this: [..., ..., ...]
     The two positions might differ because bed compensation is activated.
     To force set the internal position, use the I-flag with G0/G1/G92.

This starts to sound a bit like what you've already written in the documentation here. Sorry for diving into how UBL could work instead of how it actually works right now. I'm ok with UBL being unavailable for Hangprinter for now.

If you're going to treat one Hangprinter axis differently, I recommend using the D-axis, which is placed vertically above the origin, not the C-axis.

[thinkyhead]

@tobbelobb — Since E_STEPPERS is the same as EXTRUDERS and this block begins with #if E_STEPPERS > 1 && HAS_E1_ENABLE there's no possibility for #if ENABLED(HANGPRINTER) && EXTRUDERS == 1 to evaluate as true. So disable_E1 will always be defined as E1_ENABLE_WRITE(!E_ENABLE_ON) regardless.

[thinkyhead]

Applied a correction where these are undefined / redefined just below… See the commit labeled "Assign ABCD like X2, Y2, Z2" for details.

[tobbelobb]

You're right, good catch! I think the correction commit implements the desired behavior properly.

[tobbelobb]

Thanks for rebasing, reviewing and investing your time. Getting merged into official Marlin releases would greatly benefit the Hangprinter Community.