Marlin: I'm working on Hangprinter support

[tobbelobb]

Hello Marlin developers!

I just wanted to give you a heads up that I'm working on a pull request for getting Hangprinter into Marlin.

I've forked v1.1.x. Please tell me if I should rather fork Marlin v2 and work on that.

My work is pushed to this branch: 1.1.x_hangprinter

The changes are not tested on hardware yet.

New detailed questions constantly pops up, so I won't mention them here. See Add_Hangprinter_to_Marlin_TODO for details on my messy thoughts.

[davidelang]

since the work would need to be ported to v2, I'd guess that it's best to start
there

David Lang (nbot a marlin developer)

[Spawn32]

I actually had to google "Hangprinter" , cool :)

For anyone else wondering what it is :

https://en.wikipedia.org/wiki/Hangprinter

[teemuatlut]

I watched some of Tom's streams and remember that you had made some specific TMC2130 configurations. Anything special needed on that regard?

You definitely should use 2.0.x as your base.

[tobbelobb]

Thx!

I'll put my TMC config in my personal TMC_ADV(). It's not Hangprinter specific, and I haven't checked with a scope if it's sensible, so I probably won't push it here. (It's here if you're interested anyways).

I'll switch to building upon the bugfix-2.0.x branch right away.

Do you prefer multiple small pull requests, or do you prefer to review more finished setups in bigger blobs?

Small pull requests would look something like this:

• starting with adding 1 axis and inverse kinematics, then add features like
  
  
  
  • gcodes to tighten lines without altering current_position[], position[], and count_position[].
    
    Side note: I don't know what to call these moves. "Shadow moves"? I'd prefer to use G6 for this. Tell me if you strongly prefer G1 S3. Neither description of G6 nor G1 S2 on reprap wiki fits the Hangprinter use case perfectly.
  
  
  • line_buildup_compensation
  
  
  • eeprom storage of HP config constants
  
  
  • Mechaduino torque mode via i2x
  
  
  • forward kinematics
  
  
  • Auto anchor localization
  
  
  • Automatic homing...
  
  

[thinkyhead]

Great! Looking forward to it.

I've forked v1.1.x. Please tell me if I should rather fork Marlin v2 and work on that.

Well, you _forked_ all of Marlin's branches. So, I assume you've _made a copy of the 1.1.x branch_ for your work. That's a mistake. Make a copy of the bugfix-1.1.x branch and work on that. Then submit your PR to bugfix-1.1.x. See http://marlinfw.org/docs/development/getting_started_pull_requests.html

Once your bugfix-1.1.x patch is ready and has been refined, we can work on a bugfix-2.0.x version.

[tobbelobb]

Thanks! That's nice documentation. Sry that I missed the work branch on first read.

I'll do a series of small pull requests then.

What's a copy of a branch and why do you assume I made one?
I forked the repo and put my feature branch and my commits on top of 1.1.x. Moving them to a feature branch on top of bugfix-1.1.x instead! PR incoming as soon as I've had my changes tested on running hardware.

[thinkyhead]

What's a copy of a branch and why do you assume I made one?

I hope you did. It's a Bad Idea™ to modify the branches in your fork that correspond to the branches in the main Marlin fork. You should make a copy of bugfix-1.1.x with a descriptive name and modify that instead.

By leaving the original branches unmodified, you can always fetch the latest versions from the main fork into your fork and local working copy without running into conflicts.

[tobbelobb]

Ok then we're on the same page. Thanks for clarifying. I'm used to refering to such branches as feature branches.

I've put my bugfix-1.1.x_hangprinter branch on top of bugfix-1.1.x (which is untouched in my forked repo and will be synced with upstream). Compiles without warnings and is ready for testing on hardware.

I went with the name "unregistered moves" for G6, enabled with a UNREGISTERED_MOVE_SUPPORT define.

I included eeprom storage of Hangprinter config parameters.

[tobbelobb]

In its current form, my changes will affect other Marlin programers because another motorized axis that is not an extruder is added. Hangprinter arrays are arranged like {A_AXIS, B_AXIS, C_AXIS, D_AXIS, E_AXIS}. AxisEnum is changed so that E_AXIS = 4 (for non-Hangprinter setups it's still E_AXIS = 3), and NUM_AXIS is changed to 5 (for non-Hangprinter setups it's still 4).

Marlin will still always work on machines that have 3 movement axes. Only Hangprinter will start to misbehave if E_AXIS or NUM_AXIS are used inappropriately.

To be Hangprinter-proof then, programmers must use X_AXIS, Y_AXIS, Z_AXIS, E_CART when indexing into current_position[], destination[], and a few other arrays that will still be size XYZE on a Hangprinter setup.

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

1. 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.
2. 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.
3. 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.

(By the way: link to comparison of bugfix-1.1.x and tobbelobb/bugfix-1.1.x_hangprinter)

[tobbelobb]

Closing this thread as PR is posted: #9180 Discussion should continue there.