Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Request] Support both Marlin/Repetier and Smoothieware interpretation of G90 after M83 #1818

Closed
VBen opened this issue Mar 11, 2017 · 7 comments
Closed

[Request] Support both Marlin/Repetier and Smoothieware interpretation of G90 after M83 #1818

VBen opened this issue Mar 11, 2017 · 7 comments
Labels
done Done but not yet released request Feature request

Comments

@VBen
Copy link

VBen commented Mar 11, 2017 •
edited

What were you doing?

I'm using a printer with two seperate nozzles. The nozzles are magnatical dockabel.
Due to my preprocessing i have to use relative E distances.

What did you expect to happen?

The gcode display should work in the same was as with absolute e distances

What happened instead?

The relative E-distances are not correctly displayed in the gcode viewer.
The printing works just fine.

Branch & Commit or Version of OctoPrint

OctoPrint 1.3.2rc1 (rc/maintenance branch)

Printer model & used firmware incl. version

Homebuild , running Marlin 1.1.0-rc8 on a RAMPS board

Browser and Version of Browser, Operating System running Browser

Does not matter, I get the same result in every browser I tested

Link to octoprint.log

https://gist.github.com/VBen/e4fbe3f02b3469b0e892464e3de4a7da

Link to contents of terminal tab or serial.log

no communication errors

Link to contents of Javascript console in the browser

I think its not necessary

Screenshot(s) showing the problem:

relative e distance

Used Gcode File

See https://gist.github.com/VBen/e4fbe3f02b3469b0e892464e3de4a7da

I have read the FAQ.
@GitIssueBot
Copy link

Hi @VBen,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-03-25 12:50 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

@GitIssueBot GitIssueBot added the incomplete Issue template has not been fully filled out, no further processing until fixed label Mar 11, 2017
@VBen
Copy link
Author

VBen commented Mar 12, 2017

I did some further investigation
It seems that this behaviour is Marlin related. Marlin seems to keep the status(M83) of relative E ditances over a G91/G90 mode switch.
But the gcode parser always resets the E distances to absolute on every G90 command
https://github.com/foosel/OctoPrint/blob/master/src/octoprint/static/gcodeviewer/js/Worker.js#L366

@GitIssueBot GitIssueBot added triage This issue needs triage and removed incomplete Issue template has not been fully filled out, no further processing until fixed labels Mar 13, 2017
@foosel
Copy link
Member

foosel commented Mar 14, 2017

Hm. Fixing this would be trivial. It's one of those cases though where I wonder if it won't trigger a follow-up ticket perfectly mirroring this one. Tricky :/

@christianh17
Copy link

Suggestion: Make a switch so everyone can decide which way octoprint should "think".

@foosel
Copy link
Member

foosel commented Apr 10, 2017

The RepRap wiki's GCODE node (which is the closest thing available to a protocol definition - sadly), states this about G90:

All coordinates from now on are absolute relative to the origin of the machine.

That sounds like it also includes the E axis and the current implementation would therefore be correct (and Marlin's interpretation be wrong).

Of course, we don't have a proper standard (hooray...), so all is just guess work. And since there's absolutely no way to determine what is the correct way dynamically, I fear there really is no way around yet another one of those horrible checkboxes that the settings dialog is already drowning in.

foosel added a commit that referenced this issue May 10, 2017
@foosel
Handle G90/G91 and M82/M83 distinct by default
dba95ee 
By default G90/G91 define relativeMode, M82/M83 define relativeE. The
extruder coordinate will be viewed as relative when either
relativeMode or relativeE are set. This mirrors the implementation in
Marlin (current and legacy forks) as well as Repetier.

SmoothieWare's implementation resets the relative mode of the
extruder on a G90/G91. To still accomodate this different
implementation a new settings has been added under Settings >
Feature: "G90/G91 overrides relative extruder mode". Checking this
switches to the alternative interpretation for future gcode analysis
and visualization.

The only difference between the two of them is that the following
segment of GCODE:

    M83
    G90

will have the extruder still set to relative on Marlin and
Repetier but set to absolute on Smoothieware.

Please note that the setting in all likelihood will be moved to
the printer profile in the future, since it makes more sense to have
it on a per printer basis. It's not part of the set of features
available for auto detection since it's required for GCODE analysis
and hence needs to be known even outside of a connection to the
printer.

Implements #1818
@foosel
Copy link
Member

foosel commented May 10, 2017

image

After some reading in various firmware sources (Marlin old and new, Repetier, Smoothieware) I've now changed the behaviour to mirror Marlin and Repetier by default (= G90 doesn't disable relative extrusion mode previously enabled through M83), with an option to switch to Smoothieware style behavior (= G90 overwrites relative extrusion mode, so a new M83 is needed after each G90) under Settings > Features.

Available on the maintenance branch, soon also devel and to be released with 1.3.3.

I have to admit that I'm not too happy about having to add yet another checkbox for that, but considering that we have two approaches in popular firmware here that are exactly the opposite of each other, there's not much choice.

@foosel foosel added done Done but not yet released request Feature request and removed triage This issue needs triage labels May 10, 2017
@foosel foosel added this to the 1.3.3 milestone May 10, 2017
@foosel foosel changed the title Relative E-distances not correctly displayed in gcode preview Support both Marlin/Repetier and Smoothieware interpretation of G90 after M83 May 10, 2017
@foosel foosel changed the title Support both Marlin/Repetier and Smoothieware interpretation of G90 after M83 [Request] Support both Marlin/Repetier and Smoothieware interpretation of G90 after M83 May 10, 2017
@foosel
Copy link
Member

foosel commented May 31, 2017

1.3.3 was just released.

@foosel foosel closed this as completed May 31, 2017
@Lenbok Lenbok mentioned this issue Jan 19, 2018
Open
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
done Done but not yet released request Feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@foosel @VBen @GitIssueBot @christianh17