New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.1.x] Hangprinter support #9180

Merged
merged 15 commits into from Sep 9, 2018

Conversation

Projects
None yet
7 participants
@tobbelobb
Contributor

tobbelobb commented Jan 14, 2018

…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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jan 15, 2018

Contributor

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

Contributor

tobbelobb commented Jan 15, 2018

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

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jan 15, 2018

Member

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…

Member

thinkyhead commented Jan 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jan 15, 2018

Contributor

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".

Contributor

tobbelobb commented Jan 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jan 15, 2018

Member

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.

Member

thinkyhead commented Jan 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jan 15, 2018

Contributor

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 ?

Contributor

tobbelobb commented Jan 15, 2018

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 comment has been minimized.

Show comment
Hide comment
@fiveangle

fiveangle Jan 15, 2018

Contributor

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 ? 🤷‍♂️

Contributor

fiveangle commented Jan 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jan 19, 2018

Contributor

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

Contributor

tobbelobb commented Jan 19, 2018

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

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jan 20, 2018

Member

@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.

Member

thinkyhead commented Jan 20, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@teemuatlut

teemuatlut Jan 21, 2018

Member

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?

Member

teemuatlut commented Jan 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jan 22, 2018

Contributor

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.

Contributor

tobbelobb commented Jan 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jan 22, 2018

Contributor

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

Contributor

tobbelobb commented Jan 22, 2018

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

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jan 24, 2018

Member

@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.

Member

thinkyhead commented Jan 24, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Feb 14, 2018

Contributor

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.

Contributor

tobbelobb commented Feb 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 2, 2018

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 ?

ghost commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb
Contributor

tobbelobb commented Mar 2, 2018

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Mar 2, 2018

Contributor

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?

Contributor

tobbelobb commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Mar 2, 2018

Contributor

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.

Contributor

tobbelobb commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 2, 2018

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

ghost commented Mar 2, 2018

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

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Apr 11, 2018

Contributor

Any new estimates about when this will be merged?

Please tell me if you're interested in adding Hangprinter, or I will just go on using my own fork. Fixing new conflicts for 3 months is no fun.

Contributor

tobbelobb commented Apr 11, 2018

Any new estimates about when this will be merged?

Please tell me if you're interested in adding Hangprinter, or I will just go on using my own fork. Fixing new conflicts for 3 months is no fun.

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Apr 20, 2018

Member

We're focused on the final 1.1.x release right now — fixing outstanding bugs — and won't be merging any new features into that branch. With all that work underway I have not personally had time to convert this to the bugfix-2.0.x branch. When I have more free cycles, I hope to get on that project. This is here and open still so that it's prominently displayed and I won't forget when that time comes.

Member

thinkyhead commented Apr 20, 2018

We're focused on the final 1.1.x release right now — fixing outstanding bugs — and won't be merging any new features into that branch. With all that work underway I have not personally had time to convert this to the bugfix-2.0.x branch. When I have more free cycles, I hope to get on that project. This is here and open still so that it's prominently displayed and I won't forget when that time comes.

@fredrudolf

This comment has been minimized.

Show comment
Hide comment
@fredrudolf

fredrudolf May 4, 2018

Looking forward!

fredrudolf commented May 4, 2018

Looking forward!

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jun 1, 2018

Member

I've just squashed and rebased this onto the latest bugfix-1.1.x code to keep it up to date. But, since there was a huge refactor of the planner/stepper code recently, there are bound to be things that didn't get altered which should be to fit the new code, and this will undoubtedly need to be patched up further.

To help with that, I've made a backup of the previous contents of your branch at https://github.com/thinkyhead/Marlin/commits/bf1_hangprinter_backup for reference.

@tobbelobb — Be sure to get the latest code from here into your working copy before making any further changes:

git fetch origin
git checkout bugfix-1.1.x_hangprinter
git reset --hard origin/bugfix-1.1.x_hangprinter

To retain a copy of your previous code, you can make a copy of your local branch before doing the above…

git checkout bugfix-1.1.x_hangprinter -b previous_hangprinter_work

…or grab a copy from my fork…

git remote add thinkyhead git@github.com:thinkyhead/Marlin.git
git fetch thinkyhead
git checkout thinkyhead/bf1_hangprinter_backup -b previous_hangprinter_work
git push --set-upstream origin previous_hangprinter_work
Member

thinkyhead commented Jun 1, 2018

I've just squashed and rebased this onto the latest bugfix-1.1.x code to keep it up to date. But, since there was a huge refactor of the planner/stepper code recently, there are bound to be things that didn't get altered which should be to fit the new code, and this will undoubtedly need to be patched up further.

To help with that, I've made a backup of the previous contents of your branch at https://github.com/thinkyhead/Marlin/commits/bf1_hangprinter_backup for reference.

@tobbelobb — Be sure to get the latest code from here into your working copy before making any further changes:

git fetch origin
git checkout bugfix-1.1.x_hangprinter
git reset --hard origin/bugfix-1.1.x_hangprinter

To retain a copy of your previous code, you can make a copy of your local branch before doing the above…

git checkout bugfix-1.1.x_hangprinter -b previous_hangprinter_work

…or grab a copy from my fork…

git remote add thinkyhead git@github.com:thinkyhead/Marlin.git
git fetch thinkyhead
git checkout thinkyhead/bf1_hangprinter_backup -b previous_hangprinter_work
git push --set-upstream origin previous_hangprinter_work

@thinkyhead thinkyhead changed the title from Adds Hangprinter: The kinematics, the fourth kinematic axis, support … to [1.1.x] Hangprinter support Jun 1, 2018

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 3, 2018

Contributor

Thanks for saving the reference branch.

So I basically need to step through all functions in stepper.cpp and planner.cpp again? I suspect this has something to do with your recent S-curve work? Nice work by the way.

I'm getting tired of integrating Hangprinter into stepper.cpp and planner.cpp again and again. Will you do the merge now if I get it up to date once more?

Contributor

tobbelobb commented Jun 3, 2018

Thanks for saving the reference branch.

So I basically need to step through all functions in stepper.cpp and planner.cpp again? I suspect this has something to do with your recent S-curve work? Nice work by the way.

I'm getting tired of integrating Hangprinter into stepper.cpp and planner.cpp again and again. Will you do the merge now if I get it up to date once more?

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 4, 2018

Contributor

Did another attempt to bring Hangprinter code up to speed. I added some new forward kinematics code as well.

Contributor

tobbelobb commented Jun 4, 2018

Did another attempt to bring Hangprinter code up to speed. I added some new forward kinematics code as well.

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jun 8, 2018

Member

Will you do the merge now if I get it up to date once more?

No. Unfortunately we are still (even after many months) in the final stretch to get the 1.1.9 release out, and are only merging patches that fix bugs or improve existing features. This feature is just too massive and disruptive to the existing paradigm to merge at this critical junction.

I'm keeping this code fresh so it will be easier / possible to bring it over to the 2.0.x branch as soon as 1.1.9 is out of the way. I hope that will be very soon, but the recent refactor of the planner/stepper/endstops code has introduced some new issues that we need to debug first. I hope that we will be able to put 1.1.x behind us and move forward by the end of this month!

Member

thinkyhead commented Jun 8, 2018

Will you do the merge now if I get it up to date once more?

No. Unfortunately we are still (even after many months) in the final stretch to get the 1.1.9 release out, and are only merging patches that fix bugs or improve existing features. This feature is just too massive and disruptive to the existing paradigm to merge at this critical junction.

I'm keeping this code fresh so it will be easier / possible to bring it over to the 2.0.x branch as soon as 1.1.9 is out of the way. I hope that will be very soon, but the recent refactor of the planner/stepper/endstops code has introduced some new issues that we need to debug first. I hope that we will be able to put 1.1.x behind us and move forward by the end of this month!

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jun 15, 2018

Member

Squashed and rebased this onto the latest bugfix-1.1.x code again. The handling of count_it changed slightly because we no longer have counter_X (etc.). And the handling of pulse timing has also changed. So you'll need to review the planner/stepper code to make sure everything is proper.

git fetch origin
git checkout bugfix-1.1.x_hangprinter
git reset --hard origin/bugfix-1.1.x_hangprinter

I noticed that M205 B is broken by HANGPRINTER. Using M205 B will set both planner.min_segment_time_us and planner.max_jerk[B_AXIS] to the given B value. You'll need to use a different parameter for setting planner.min_segment_time_us or to set planner.max_jerk[B_AXIS].

Member

thinkyhead commented Jun 15, 2018

Squashed and rebased this onto the latest bugfix-1.1.x code again. The handling of count_it changed slightly because we no longer have counter_X (etc.). And the handling of pulse timing has also changed. So you'll need to review the planner/stepper code to make sure everything is proper.

git fetch origin
git checkout bugfix-1.1.x_hangprinter
git reset --hard origin/bugfix-1.1.x_hangprinter

I noticed that M205 B is broken by HANGPRINTER. Using M205 B will set both planner.min_segment_time_us and planner.max_jerk[B_AXIS] to the given B value. You'll need to use a different parameter for setting planner.min_segment_time_us or to set planner.max_jerk[B_AXIS].

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 16, 2018

Contributor

Sorry dude. The PR in January was already designed to not break UX for anyone (except the few HP users, if you forgot E_AXIS/E_CART some time). I do not agree that this PR is massive or disruptive.

From my perspective, your extreme postponing of this merge is without reason, and it eats my work hours. Changing counter_X etc before merging in count_it is not efficient. I will go back to pushing bugfixes onto my own fork and redirect my firmware coding efforts to RepRapFirmware.

Do you want me to leave this PR open, or should I close it?

Contributor

tobbelobb commented Jun 16, 2018

Sorry dude. The PR in January was already designed to not break UX for anyone (except the few HP users, if you forgot E_AXIS/E_CART some time). I do not agree that this PR is massive or disruptive.

From my perspective, your extreme postponing of this merge is without reason, and it eats my work hours. Changing counter_X etc before merging in count_it is not efficient. I will go back to pushing bugfixes onto my own fork and redirect my firmware coding efforts to RepRapFirmware.

Do you want me to leave this PR open, or should I close it?

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 16, 2018

Contributor

I looked through stepper.cpp, planner.cpp and your recent commits. Found one typo and fixed M205.

Contributor

tobbelobb commented Jun 16, 2018

I looked through stepper.cpp, planner.cpp and your recent commits. Found one typo and fixed M205.

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jun 19, 2018

Member

From my perspective, your extreme postponing of this merge is without reason

Well, you may not agree with our reasons, and naturally every contributor very much wants their work to be loved, appreciated, and integrated as soon as possible. You're not alone, and I can only apologize for the continued delay.

We put an embargo on new features months ago so that we could focus exclusively on figuring out bugs and getting the 1.1.9 release out, and we expected to get that release done pretty quickly. But we hit a big snag with a "layer-shifting" issue, and we have postponed the release much more than anyone wanted. At the same time the maintainers have been much busier than usual with their work, families, and so on.

I'm sorry that this PR and many others have been put off for so long, and that I haven't had more time to spend on it. We share your frustration, and beg your forgiveness for the timing of the embargo.

Member

thinkyhead commented Jun 19, 2018

From my perspective, your extreme postponing of this merge is without reason

Well, you may not agree with our reasons, and naturally every contributor very much wants their work to be loved, appreciated, and integrated as soon as possible. You're not alone, and I can only apologize for the continued delay.

We put an embargo on new features months ago so that we could focus exclusively on figuring out bugs and getting the 1.1.9 release out, and we expected to get that release done pretty quickly. But we hit a big snag with a "layer-shifting" issue, and we have postponed the release much more than anyone wanted. At the same time the maintainers have been much busier than usual with their work, families, and so on.

I'm sorry that this PR and many others have been put off for so long, and that I haven't had more time to spend on it. We share your frustration, and beg your forgiveness for the timing of the embargo.

@fiveangle

This comment has been minimized.

Show comment
Hide comment
@fiveangle

fiveangle Jun 20, 2018

Contributor

Couldn't priority of integrating Torbjörn's code into 2.0 be boosted up a little bit so that Marlin proper can become the source home for what is somewhat one of the more innovative approaches to large 3D printing to come along in a very long time ?

Granted, the bulk of Marlin users would not directly benefit from the addition of hangprinter kinematics, but it seems a shame to turn it away as I would think getting the more innovative projects integrated into Marlin can serve only to improve the core more by growing the net to cover the more innovative and adventurous of the community rather than segmenting it.

Contributor

fiveangle commented Jun 20, 2018

Couldn't priority of integrating Torbjörn's code into 2.0 be boosted up a little bit so that Marlin proper can become the source home for what is somewhat one of the more innovative approaches to large 3D printing to come along in a very long time ?

Granted, the bulk of Marlin users would not directly benefit from the addition of hangprinter kinematics, but it seems a shame to turn it away as I would think getting the more innovative projects integrated into Marlin can serve only to improve the core more by growing the net to cover the more innovative and adventurous of the community rather than segmenting it.

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 20, 2018

Contributor

@fiveangle Yes, thank you. Getting onto 32-bit controllers asap is a big deal for the Hangprinter Community. I made the UNREGISTERED_MOVE_SUPPORT, and Mechaduino stuff independent of the Hangprinter kinematics, since the bulk of Marlin users might benefit. I also made the line buildup compensation independent of Hangprinter kinematics, so that any design who uses line-on-spool will benefit.

@thinkyhead Thanks for your response. I understand that you can't spend lots of time on each PR. When your time becomes the bottleneck of your project's progress, then you have to start trusting other programmers instead of trying to review everything yourself. Or you can choose to say no to PRs, and let some fork volunteer as the new bleeding edge, that's totally fair game. I announced the PR a week ahead, and you didn't say no, so I went ahead.

I then asked you to press merge and trust me. For HP to be part of Marlin, you must trust that I won't break your users' experience, and that I will come back and fix the bugs. If you don't trust me that's fair, but I would like to know why.

Embargo says "we trust no one but the inaugurated". Maintaining an embargo for more than a few days turns your project into a closed bubble, and ultimately harms your project. It disturbs the smooth workflow that commits and branches normally enable for all but the inaugurated. This makes contributors walk away.

I'm surprised you've let the embargo situation go on for so long, particularly when you hit something like unexpected layer shifting. Version control gives you the flexibility to branch off, roll back, cherry-pick the waiting PRs, and do a new (time limited) embargo at a later time.

I'm a programmer doing Hangprinter full time, no other work, no family or so on. Waiting outside your embargo bubble for six months, and re-implementing my work onto a moving branch six times, made me conclude that your project lacks either trust, management, or both. I understand that you're trying your best and of course I forgive you. But I have to get myself, my patreons and the rest of HP community onto 32-bit asap. I think that means having to move on from this PR.

Contributor

tobbelobb commented Jun 20, 2018

@fiveangle Yes, thank you. Getting onto 32-bit controllers asap is a big deal for the Hangprinter Community. I made the UNREGISTERED_MOVE_SUPPORT, and Mechaduino stuff independent of the Hangprinter kinematics, since the bulk of Marlin users might benefit. I also made the line buildup compensation independent of Hangprinter kinematics, so that any design who uses line-on-spool will benefit.

@thinkyhead Thanks for your response. I understand that you can't spend lots of time on each PR. When your time becomes the bottleneck of your project's progress, then you have to start trusting other programmers instead of trying to review everything yourself. Or you can choose to say no to PRs, and let some fork volunteer as the new bleeding edge, that's totally fair game. I announced the PR a week ahead, and you didn't say no, so I went ahead.

I then asked you to press merge and trust me. For HP to be part of Marlin, you must trust that I won't break your users' experience, and that I will come back and fix the bugs. If you don't trust me that's fair, but I would like to know why.

Embargo says "we trust no one but the inaugurated". Maintaining an embargo for more than a few days turns your project into a closed bubble, and ultimately harms your project. It disturbs the smooth workflow that commits and branches normally enable for all but the inaugurated. This makes contributors walk away.

I'm surprised you've let the embargo situation go on for so long, particularly when you hit something like unexpected layer shifting. Version control gives you the flexibility to branch off, roll back, cherry-pick the waiting PRs, and do a new (time limited) embargo at a later time.

I'm a programmer doing Hangprinter full time, no other work, no family or so on. Waiting outside your embargo bubble for six months, and re-implementing my work onto a moving branch six times, made me conclude that your project lacks either trust, management, or both. I understand that you're trying your best and of course I forgive you. But I have to get myself, my patreons and the rest of HP community onto 32-bit asap. I think that means having to move on from this PR.

@Bostwickenator

This comment has been minimized.

Show comment
Hide comment
@Bostwickenator

Bostwickenator Jun 20, 2018

"At the same time the maintainers have been much busier than usual with their work, families, and so on." sounds like you really need outside help in this situation not to lose support from contributors who would be extremely motivated to help you if code was integrated. You seem to have a good handle on the revisions where the layer shifting was introduced so working forward from that point and then merging in whatever fix is discovered shouldn't be a problem.

Bostwickenator commented Jun 20, 2018

"At the same time the maintainers have been much busier than usual with their work, families, and so on." sounds like you really need outside help in this situation not to lose support from contributors who would be extremely motivated to help you if code was integrated. You seem to have a good handle on the revisions where the layer shifting was introduced so working forward from that point and then merging in whatever fix is discovered shouldn't be a problem.

@p3p

This comment has been minimized.

Show comment
Hide comment
@p3p

p3p Jun 20, 2018

Member

When your time becomes the bottleneck of your project's progress, then you have to start trusting other programmers instead of trying to review everything yourself

I'm sorry but having anyone other than the core team merge PRs is asking for problems and coding standards deterioration, this is a community of volunteers but there always has to be a coordinator.

Maintaining an embargo for more than a few days turns your project into a closed bubble

This PR just came in at a bad time, we are trying to close the 1.1.x branch out with 1.1.9 so bugfix-1.1.x was permanently feature frozen a long.. long time ago (okay thinkyhead hasn't quite followed his own rule on that one ), once the blocking issues are sorted with 1.1.x and we can work on one bugfix branch (2.0.x) again life will be easier for everyone.

The issue with synchronous bugfix branches is that at this point any PR to bugfix-1.1.x needs a matching PR for bugfix-2.0.x, if you don't supply one thinkyhead has to spend time first understanding and then replicating the change-set over to bugfix-2.0.x.

Member

p3p commented Jun 20, 2018

When your time becomes the bottleneck of your project's progress, then you have to start trusting other programmers instead of trying to review everything yourself

I'm sorry but having anyone other than the core team merge PRs is asking for problems and coding standards deterioration, this is a community of volunteers but there always has to be a coordinator.

Maintaining an embargo for more than a few days turns your project into a closed bubble

This PR just came in at a bad time, we are trying to close the 1.1.x branch out with 1.1.9 so bugfix-1.1.x was permanently feature frozen a long.. long time ago (okay thinkyhead hasn't quite followed his own rule on that one ), once the blocking issues are sorted with 1.1.x and we can work on one bugfix branch (2.0.x) again life will be easier for everyone.

The issue with synchronous bugfix branches is that at this point any PR to bugfix-1.1.x needs a matching PR for bugfix-2.0.x, if you don't supply one thinkyhead has to spend time first understanding and then replicating the change-set over to bugfix-2.0.x.

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 20, 2018

Contributor

Hello @p3p!

Yes, coordination is needed. I announced I was working on this in advance, I asked for where to push (and was pointed to a feature-frozen branch by you guys?), I read the coding standards and followed them, I wrapped all new code in new defines so that nothing breaks for other users, and tinkyhead said he would merge this onto 2.0.x quick and painless, I was told I should not worry about 2.0.x migration.

Feature-freeze harms your project, and that is probably why tinkyhead breaks his own rule. Marlin core team could have merged this on Jan 15, with no UX breaking and no standards deteriorating. Tinkyhead wanted to absorb the changes first, but clearly didn't have the time to do so. He could have delegated the deep review to somebody else in core team, or he could have done a 5 min read-through and trusted me on the rest. Instead he let me wade through re-implementations on top of a changing code base. If a bad time lasts for 6 months, then you have bad management.

Contributor

tobbelobb commented Jun 20, 2018

Hello @p3p!

Yes, coordination is needed. I announced I was working on this in advance, I asked for where to push (and was pointed to a feature-frozen branch by you guys?), I read the coding standards and followed them, I wrapped all new code in new defines so that nothing breaks for other users, and tinkyhead said he would merge this onto 2.0.x quick and painless, I was told I should not worry about 2.0.x migration.

Feature-freeze harms your project, and that is probably why tinkyhead breaks his own rule. Marlin core team could have merged this on Jan 15, with no UX breaking and no standards deteriorating. Tinkyhead wanted to absorb the changes first, but clearly didn't have the time to do so. He could have delegated the deep review to somebody else in core team, or he could have done a 5 min read-through and trusted me on the rest. Instead he let me wade through re-implementations on top of a changing code base. If a bad time lasts for 6 months, then you have bad management.

@p3p

This comment has been minimized.

Show comment
Hide comment
@p3p

p3p Jun 20, 2018

Member

During the 2.0 transition phase the 2 branches have been in lockstep, meaning we cannot merge into one without having the same fix (or feature if we throw the rule out the window) merged in the other, this applies even stronger to bugfix-1.1.x as it can not get ahead of bugfix-2.0.x, while it wouldn't be bad for 2.0.x to have a feature that 1.1.x does not.

We all want to move past this point and release 1.1.9 but new features were merged into bugfix-1.1.x to fix a step loss issue, they didn't, but now we have invasive project wide new features in testing and the original issues still open, in the last few months practically entire motion core of marlin has been replaced in a feature frozen branch .. so really I've no idea whats going on.

Anyway, having said a lot about nothing.. in my opinion if you want to be in the best position to get Hangprinter support into Marlin you need to have a PR based on bugfix-2.0.x.

Member

p3p commented Jun 20, 2018

During the 2.0 transition phase the 2 branches have been in lockstep, meaning we cannot merge into one without having the same fix (or feature if we throw the rule out the window) merged in the other, this applies even stronger to bugfix-1.1.x as it can not get ahead of bugfix-2.0.x, while it wouldn't be bad for 2.0.x to have a feature that 1.1.x does not.

We all want to move past this point and release 1.1.9 but new features were merged into bugfix-1.1.x to fix a step loss issue, they didn't, but now we have invasive project wide new features in testing and the original issues still open, in the last few months practically entire motion core of marlin has been replaced in a feature frozen branch .. so really I've no idea whats going on.

Anyway, having said a lot about nothing.. in my opinion if you want to be in the best position to get Hangprinter support into Marlin you need to have a PR based on bugfix-2.0.x.

@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 20, 2018

Contributor

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

Contributor

tobbelobb commented Jun 20, 2018

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

@p3p

This comment has been minimized.

Show comment
Hide comment
@p3p

p3p Jun 20, 2018

Member

I'm sure thinkyhead had his reasons, though considering that (as stated above by thinkyhead) it was unlikely this would merge with bugfix-1.1.x I don't understand them, and would have agreed with the others that stated bugfix-2.0.x.

Anyway, I was just trying to clear up the murky waters of the bugfix-1.1.x branch that just will not die, and what ever happens this will need a bugfix-2.0.x counterpart PR.

Member

p3p commented Jun 20, 2018

I'm sure thinkyhead had his reasons, though considering that (as stated above by thinkyhead) it was unlikely this would merge with bugfix-1.1.x I don't understand them, and would have agreed with the others that stated bugfix-2.0.x.

Anyway, I was just trying to clear up the murky waters of the bugfix-1.1.x branch that just will not die, and what ever happens this will need a bugfix-2.0.x counterpart PR.

@thinkyhead

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jun 22, 2018

Member

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.

Member

thinkyhead commented Jun 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jun 22, 2018

Member

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.

Member

thinkyhead commented Jun 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Jun 22, 2018

Contributor

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.

Contributor

tobbelobb commented Jun 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Jun 28, 2018

Member

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.

Member

thinkyhead commented Jun 28, 2018

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

This comment has been minimized.

Show comment
Hide comment
@thinkyhead

thinkyhead Sep 8, 2018

Member

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.

Member

thinkyhead commented Sep 8, 2018

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.

leveling_active ? ubl.get_z_correction(a, b) :
#endif
0)
));

This comment has been minimized.

@thinkyhead

thinkyhead Sep 8, 2018

Member

@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.

@thinkyhead

thinkyhead Sep 8, 2018

Member

@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.

This comment has been minimized.

@tobbelobb

tobbelobb Sep 8, 2018

Contributor

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.

@tobbelobb

tobbelobb Sep 8, 2018

Contributor

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.

Show outdated Hide outdated Marlin/Marlin.h
@tobbelobb

This comment has been minimized.

Show comment
Hide comment
@tobbelobb

tobbelobb Sep 8, 2018

Contributor

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

Contributor

tobbelobb commented Sep 8, 2018

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

@thinkyhead thinkyhead merged commit 330c4bc into MarlinFirmware:bugfix-1.1.x Sep 9, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment