Matching Printer/Extruder End GCode

[randellhodges]

In my end gcode, I have (snippet)

G91             ; Relative positionning

G1 E-2 F2700        ; Retract a bit
G1 Z0.2 F2400       ; Retract and raise Z
G1 X5 Y5 F3000      ; Wipe out
G1 Z10          ; Raise Z more
G90             ; Absolute positionning

The currentHeight expression keys off those lines with Z in them and makes the display go wonky.

Need a way, maybe another comment, to signal the plugin not to process a section of code.

[OllisGit]

Hi @randellhodges

hmmm..did you already play around with the "Height-Method-Settings" ?

..and what do you mean with "wonky"? Please explain a little bit more. Or attach a GCode file so that I can reproduce your issue.

[randellhodges]

The regex for parsing out the current layer height is absolute and not relative. So if you have a gcode snippet like:

;MESH:cube.stl
G0 F9000 X102.75 Y124.75 Z10
;TYPE:WALL-OUTER
G1 F600 X102.75 Y105.25 E159.04527
G1 X122.25 Y105.25 E159.78221
G1 X122.25 Y124.75 E160.51915
G1 X102.75 Y124.75 E161.25609
;TIME_ELAPSED:414.839229
G1 F2700 E160.25609
; ================================
; Printer End - Begin
; ================================
M400            ; Wait for planner/moves

G91             ; Relative positionning
G1 E-2 F2700        ; Retract a bit
G1 Z0.2 F2400       ; Retract and raise Z
G1 X5 Y5 F3000      ; Wipe out
G1 Z10          ; Raise Z more
G90             ; Absolute positionning

M107            ; Turn-off fan
M104 S0             ; Turn-off hotend
M140 S0             ; Turn-off bed

G1 X0 Y230      ; Present Print
M84 X Y E           ; Disable all steppers but Z
; ================================
; Printer End - End
; ================================

It will parse out 10 from this line: G0 F9000 X102.75 Y124.75 Z10

But then, in the ending gcode I turn on relative positioning: G91 ; Relative positionning and then the plugin thinks the current layer height is 0.2 because of this line: G1 Z0.2 F2400 ; Retract and raise Z and then back to 10 because of this line: G1 Z10 ; Raise Z more

Technically, the current height of the print was 10. The print head itself is at 20.2.

This isn't the best example because it was pulled from a test object that ends at 10 height. But if you printing a benchy for example, the last real layer would be something like: G0 F300 X108.202 Y112.188 Z48 and you'd expect the height to be 48 (or 68.2 if it knew and factored in the relative position in the ending gcode, which I don't think it should) but it ends at 10 because of that last time I mentioned above.

Edit: A quick and dirty solution would be for the plugin to look for a comment to indicate when to stop processing. People could enter that in the ending gcode and the plugin would see it and stop processing.

[OllisGit]

Hi @randellhodges okay, now it is clear what you mean. But do you have a complete g-code file for me, so that i don't need to invest effort to create just a sample instead of a "real-gcode"?

Your suggestion with a special comment could be a good solution. Also, I was thinking about a better gcode parser: Handle absolute-relative extrusions. But both things are not done in a short term.

What slicer do you use? If you use Cura for example, Cura creates header comments:

;3dbenchy.gcode
;FLAVOR:Marlin
;TIME:9836
;Filament used: 2.70456m
;Layer height: 0.15
;MINX:73.944
;MINY:87.916
;MINZ:0.3
;MAXX:137.397
;MAXY:123.819
;MAXZ:48
;Generated with Cura_SteamEngine 4.3.0
M140 S50
M105

Then you can use the expression option in the plugin to grab 48mm: ;MAXZ:([0-9]+[.]*[0-9]*).*

Maybe your slicer also support some kind of Meta-Data/Keywords/Variables in front of the gcode. Maybe during pre-processing.

[randellhodges]

Here is an excerpt from a log file. I filtered it down so it shows your events, specifically the heightChanged. Notice the currentHeight and currentLayer for the last few.

I have also attached a sample gcode file. The snippet below is not from a test print of the attached gcode but it has the same cura/machine inserted custom gcode in it.

The max z/layers is working fine. It is the current layer that changes due to changing to relative movement in the ending gcode.

A couples ways to solve it. 1) Provide a way to look for a token that tells the plugin, your done, no need to process anything after this. It is a quick and dirty "fix" 2) Look at the gcodes for absolute vs relative motion. If absolute, read and store the current height. If you see a G91, then instead of taking the Z value you read as absolute, take that number and add to your previously saved current height. Then if you come across a G90, just track along with what you have in the file.

The 2nd option would be preferred because this it doesn't matter what positioning the user is sliced into, the plugin would work.

I am willing to give it a go and submit a pull request later if you don't beat me too it.

In retrospect, I can see how option 2 could have some issues. I can expand on them if you feel this idea is actually worth pursuing.

    Line 53779: 2019-08-06 14:19:34,918 - octoprint.plugins.excluderegion - INFO - Event received: event=DisplayLayerProgress_heightChanged payload={'feedrate': '9000', 'totalLayer': '234', 'averageLayerDuration': '0h:02m:08s', 'feedrateG1': '1200', 'feedrateG0': '9000', 'totalHeightWithExtrusion': '47.0', 'lastLayerDuration': '0h:02m:29s', 'printTimeLeftInSeconds': 57, 'fanspeed': '74%', 'progress': '99', 'currentHeight': '46.80', 'printTimeLeft': '57s', 'currentLayer': '233'}
    Line 54084: 2019-08-06 14:22:00,875 - octoprint.plugins.excluderegion - INFO - Event received: event=DisplayLayerProgress_heightChanged payload={'feedrate': '9000', 'totalLayer': '234', 'averageLayerDuration': '0h:02m:10s', 'feedrateG1': '1200', 'feedrateG0': '9000', 'totalHeightWithExtrusion': '47.0', 'lastLayerDuration': '0h:02m:25s', 'printTimeLeftInSeconds': 14, 'fanspeed': '74%', 'progress': '99', 'currentHeight': '47.00', 'printTimeLeft': '14s', 'currentLayer': '234'}
    Line 54368: 2019-08-06 14:24:29,338 - octoprint.plugins.excluderegion - INFO - Event received: event=DisplayLayerProgress_heightChanged payload={'feedrate': '2700', 'totalLayer': '234', 'averageLayerDuration': '0h:02m:10s', 'feedrateG1': '2700', 'feedrateG0': '9000', 'totalHeightWithExtrusion': '47.0', 'lastLayerDuration': '0h:02m:25s', 'printTimeLeftInSeconds': 5, 'fanspeed': 'Off', 'progress': '99', 'currentHeight': '0.20', 'printTimeLeft': '5s', 'currentLayer': '234'}
    Line 54372: 2019-08-06 14:24:29,359 - octoprint.plugins.excluderegion - INFO - Event received: event=DisplayLayerProgress_heightChanged payload={'feedrate': '3000', 'totalLayer': '234', 'averageLayerDuration': '0h:02m:10s', 'feedrateG1': '3000', 'feedrateG0': '9000', 'totalHeightWithExtrusion': '47.0', 'lastLayerDuration': '0h:02m:25s', 'printTimeLeftInSeconds': 5, 'fanspeed': 'Off', 'progress': '99', 'currentHeight': '10.00', 'printTimeLeft': '5s', 'currentLayer': '234'}

cube.zip

[OllisGit]

Hi @randellhodges, thanks for the detailed informations and the offer to create an PR.

I looked into the original OctoPrint sources and the relative movement is also not detected.

# Grab Z-Height from Octoprint
currentData = self._printer.get_current_data()
str(currentData["currentZ"]) 

Anyway, I created a new version 1.14.2 with "option 2" (was really easy). My test-gcode looks like this:

G28
;Absolute positioning
G90
G1 Z5
G1 Z10
G1 Z5
G1 Z20

;Relative positioning
G91
G1 Z5
G1 Z10
G1 Z5

At the end I had a height of 40mm.

Please test and give feedback!

[randellhodges]

Thanks for the changes. I think this works:

Current Height: 30.20 / 20.00mm Layer: 99 / 99

The object is indeed 20mm tall printing with 0.2mm layers and you can see, my end gcode does add a total of 10.2mm to the Z (to present the print).

Here is an interesting question: Should the "Current Height" reflect the position of Z (as it does now in 1.14.2) or the height of the printed object? If it is the height of the printed object, then the only way to do that is to have the ability to read a comment to tell the plugin, "done, ignore gcode after this point".

[OllisGit]

Hi @randellhodges !

It's the current height of the nozzel.

The "comment-done" idea is good, but tricky. Because if you include multiple objects in one printjob, what is the correct "object-height"? And for the user it is (maybe) not easy to include such comment into the gcode. My assumption is that the most users just use the slicer with "default" settings like slider and checkboxes and not adding special gcode (only start/stop, but not some script magic).

So, from my point I will leave it like it is and don't invest effort into this feature (I have a bunch of other cool plugin-stuff todo ;-)) But I know it is sometimes disappointing that an issues is closed without fulfilling 100% of my feature request....feel free to create a new one if you think it is a "must-have" for all users