Layer Heights different between tools.

Discussion in 'Getting Started' started by Andy Cohen, Feb 21, 2020.

  1. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    I readded the bed leveling to start.g only
    And filmed the shift in the UI and using a measurement device for the physical Z.

    [​IMG]
    The only change was:
    upload_2020-4-8_23-14-14.png

    Like I said ...
     
  2. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    Well I've never used start.g before - so that's interesting. I put the start GCODE in the slicer section for starting GCODE. I've never used M561 either.

    But it seems that something about you bed leveling is causing the issue. What version of RRF are you running?

    Next I'm thinking that your error is, we think, generated as a result of tool changes and bed levelling. Why not create a script which just hammers this issue repeatedly.

    So the script will look something like this

    ;G29 ; uncomment depending on test
    ;M561 ; uncomment depending on test
    T0
    G1 X150 Y100 F12000
    T1
    G1 X150 Y100 F12000
    T0
    G1 X150 Y100 F12000
    etc..

    The only question is whether you have G29 at the start or not. I tend to run that ever time.
    Things that could generate the issues that spring to mind in this test.
    * Possibly the mesh setup in M557
    * tpre0.g & tpre1.g
    * tpost0.g & tpost1.g
    * tfree0.g & tfree1.g

    For you, there's also start.g, which maybe can be emptied, commented, or renamed while focusing on this issue using this GCODE.

    10 tool changes according to previous video should generate a movement of 2mm with G29 enabled and 0mm movement with it disabled. Then you need to go through all these pre,post, and free files with a fine toothcomb to ensure they are not to blame.
     
  3. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    Also, you are using pause and resume here ... so have a look in pause.g and resume.g
     
  4. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    Thx for your responses.
    I think I need to rearrange my own thoughts for once:

    Versions I had searching the solution

    The Firmware was 3.01-RC3 when I actively started testing to remove this bug.
    I switched to every new release (except RC5.) Now I use RC6.

    My very first idea of the problem:

    Prior to that I was sure that the problems are hunting me because of the toolchanger is not built stiff enough:
    https://forum.e3d-online.com/threads/spare-rear-panel.3282/page-7#post-35937
    (But I still stay at this point! It was not stiff enough plus I have a software problem on the Duet.)

    About my tests with the mesh bed leveling / auto bed leveling:
    About pause.g

    Greg Holloway uses no resume.g only pause.g
    https://github.com/e3donline/RepRap...401f52ef2ce195ba32f2efddb383be/sys/pause.g#L1
    https://github.com/Duet3D/RRF-machi...dc42-wifi-centreZero-quadTitan/sys/pause.g#L1
    https://github.com/Nibbels/e3d-tool...23c741f9d271c63f8245f8b000332f/sys/pause.g#L1
    (Why did I switch G1 Sx to G1 Hx: Because it is in the upgrade notice for RRF2.x to RRF3.x)

    About resume.g:

    https://github.com/Duet3D/RRF-machi...c42-wifi-centreZero-quadTitan/sys/resume.g#L1
    https://github.com/Nibbels/e3d-tool...3c741f9d271c63f8245f8b000332f/sys/resume.g#L1
    (I copied alot of code from DC42)
     
    #24 Nibbels, Apr 9, 2020
    Last edited: Apr 9, 2020
  5. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
  6. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    So, this could be an issue that result specifically from the repeated use of resume and pause. Is there a reason you are using these specific tools to target your problem. I thought maybe you would be toolchanging rather than switching filament with pause/resume. In any case, that also gives me something to test. I did do a multi-tool print today on RC6 and it did work out fine. Before I try a bunch of pausing and resuming, here's my current setup

    pause.g
    Code:
    M83            ; relative extrusion
    G10            ; fw retract
    G91            ; relative motion
    G1 Z5 F1200    ; up 5mm
    G90            ; absolute motion
    
    ; swap spot
    G1 X150 Y-30 F50000   
    
    ; eject
    if state.currentTool=3
        M98 P"eject-hemera.g"
    else
        M98 P"eject.g"
    
    M18 E0            ; disable extruder motors to permit refeeding with wheel
    M18 E1            ; disable extruder motors to permit refeeding with wheel
    M18 E2            ; disable extruder motors to permit refeeding with wheel
    M18 E3            ; disable extruder motors to permit refeeding with wheel
    resume.g

    Code:
    ; Resume macro - executed manually from the web interface or control panel to resume printing following a pause for a filament change.
    
    ;prime nozzle
    if state.currentTool=3
        M98 P"prime-hemera.g"
    else
        M98 P"prime.g"
    
    
    G10
    G1 R1 Z5 F99999
    G1 R1 F500
    
    M83            ; relative extruder moves
    G11            ; fw un-retract
    Config.g tool offsets

    Code:
    G10 P0 X-9 Y40 Z-4.9575                        ; T0 - V6
    G10 P1 X-8.55 Y39.7 Z-5.0125                ; T1 - V6
    G10 P2 X-8.85 Y39.625 Z-5.0125                ; T2 - V6
    G10 P3 X20.05 Y45.19 Z-5.725                ; T3 - Hemera
    I'm pretty sure this I haven't used pause, resume for some time, as I think my G1 R1 in resume.g is not going to work properly with X and Y coords given. I vaguely remember reading about that change, so it likely needs an X0 Y0 in order to see those axis get engaged.
     
  7. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    OK. Have duplicated your results. I created a simple GCODE file to slowly move back and forth from left to right, and hit resume and repeat. I start at Z=3 and each and every time I pause, the console reports that the pause occurred at some X, Y and Z=3.0. However, each time it resumes, Z reports on screen an ever decreasing number. Despite the screen reported Z value, each pause report has Z as 3.0. This looks like a bug (maybe a rounding error somewhere). I had never noticed before that resurrect.g is generate every time you pause. I have no control over this (though I have considered flipping the read/write flag on the file or the SD card to see if I can just prevent it writing to it). I don't know why we need a resurrect.g this complex if all that's happening is the tool is being carried to a safe spot, for a reel change, and then to resume the print. I assume it's catering to far more complex situations and a potential machine shutdown. At this stage, we're out of options, but maybe @dc42 will already know about this issue, as the comments you found clearly indicate it's something being worked on. I also see an error printed at the moment I hit pause, complaining about a macro and a Q0 parameter. I notice also that resurrect.g references resurrect-prologue.g, which isn't present.

    The gcode I used:
    Code:
    M98 P"homeall.g"
    G29
    
    T0
    
    G1 X0 Y100 F99999
    G1 X300 F500
    G1 X0 F500
    G1 X300 F500
    G1 X0 F500
    G1 X300 F500
    G1 X0 F500
    G1 X300 F500
    G1 X0 F500
    G1 X300 F500
    G1 X0 F500
    
    T-1
    
    G1 X150 Y-35 F99999
    pause.g
    Code:
    M83           ; relative extrusion
    G10           ; fw retract
    G91           ; relative motion
    G1 Z5 F1200   ; up 5mm
    G90           ; absolute motion
    
    ; swap spot
    G1 X150 Y-30 F50000
    
    ; eject
    if if sensors.analog[state.currentTool+1].lastReading > 30
       if state.currentTool=3
           M98 P"eject-hemera.g"
       else
           M98 P"eject.g"
    
    M18 E0           ; disable extruder motors to permit refeeding with wheel
    M18 E1           ; disable extruder motors to permit refeeding with wheel
    M18 E2           ; disable extruder motors to permit refeeding with wheel
    M18 E3           ; disable extruder motors to permit refeeding with wheel
    resume.g

    Code:
    ; Resume macro - executed manually from the web interface or control panel to resume printing following a pause for a filament change.
    
    ;prime nozzle
    if sensors.analog[state.currentTool+1].lastReading > 40
        if state.currentTool=3
            M98 P"prime-hemera.g"
        else
            M98 P"prime.g"
    
    G10
    G1 R1 X0 Y0 Z5 F99999
    G1 R1 Z0 F500
    
    M83            ; relative extruder moves
    
    if sensors.analog[state.currentTool+1].lastReading > 40
        G11            ; fw un-retract
     
    Nibbels likes this.
  8. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    I did use the pause/resume because it seems to cause the same type of issue as tool changes.

    The toolchange from the first tool to the second tool after the previous G1 Zx rightnow causes some rounded dZ = -0.2 offset
    The toolchange from the second to the third tool then only causes some rounded dZ <= -0.1 offset.
    .. with the current height map.

    I once sent M409 K"move" within a print where the coordinates were wrong.
    That looks like the amount of compensation (mesh z offset) got added to the userPosition. ??
     
    #28 Nibbels, Apr 9, 2020
    Last edited: Apr 9, 2020
  9. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    Thank you so much! I feel not (so much) crazy after all :)
     
    Spoon Unit likes this.
  10. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    OK. I didn't test pure tool changes. Will give that a whirl tomorrow.
     
    Nibbels likes this.
  11. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    OK. I did test pure tool changes yesterday and they seemed to be fine. That said, I was not running a job, just executing GCODE in the console. I started with

    T0
    G1 X150 Y100 Z10

    As expected, this reported correctly in the status. Then I used

    T1
    G1 R2 X0 Y0 Z0

    This gave the same results in the browser as before. So Z was returned to 10 even though the tool offset causes differences when collected.

    I then repeated this process of selecting a tool and returning to R2 X0 Y0 Z0 for T0,T1,T0,T2,T0. In all cases it returned to the right place. I suppose ideally this should also be run as part of a job, just to rule out this being something that goes wrong when the printer is in 'job' mode. In this case, I will try this later:

    M98 P"homeall.g"
    T0
    G1 X150 Y100 Z10
    G4 S5
    T1
    G1 R2 X0 Y0 Z0 F12000
    G4 S5
    T2
    G1 R2 X0 Y0 Z0 F12000
    G4 S5
    T3
    G1 R2 X0 Y0 Z0 F12000
    G4 S5
    T0
    G1 R2 X0 Y0 Z0 F12000
    G4 S5
    T1
    G1 R2 X0 Y0 Z0 F12000
    G4 S5
    T2
    G1 R2 X0 Y0 Z0 F12000
    G4 S5
    T3
    G1 R2 X0 Y0 Z0 F12000
    G4 S5
    T-1
    G1 X150 Y-35 F12000
     
  12. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    G1 R2 X0 Y0 Z0 F12000

    That Z0 after the Toolchange returns Z to the value we expect.
    What if you set Z once.
    Then change tools and only use Y and X als coordinates?

    That is a scheme what simplify compiles for me:

    G1 Z0.2
    T0
    ...
    T1 ---> shift+
    ....
    T2---> shift++
    ...
    G1 Z0.4
    T0
    ...
    T1---> shift+
    ....
    T2---> shift++
    ...
    G1 Z0.6
    T0
    ...
    T1---> shift+
    ....
    T2---> shift++
    ...
    G1 Z0.8


    If I could convice simplify to add the active layer height after each Tn, that would totally solve my problem. But It is not correct that I let the firmware shift Z, because I did not demand those shifts by the slicers GCode.
     
  13. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    Ok, after I thought that you might have had some Idea to fix Z after each toolchange using G1 R2 Z0:
    I already tried this. (in tpostN.g)
    upload_2020-4-11_14-40-39.png
    And I did test to put a M400 at the end of tpostN.g which did not seem to help.

    When I arrive at the printing location after a Toolchange and then add G1 Z0.4 as example: Then the position gets fixed.
     
  14. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    I don't seem to be seeing the issue on Toolchange though. Only on pause/resume.
     
  15. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    To show this difference at any time

    echo "difference : " ^ (move.axes[2].machinePosition-move.axes[2].userPosition)

    When I reset the machine, this shows 0.00. After homing, I'm still at 0.00. After G29 I show a different figure every time, which is perhaps understandable. Anyway, just wanted to give you a simple way to report this in case you were still hunting.

    Ideally we could enable logging and the echo content would go to the log, but sadly the echo only makes it the console, and doesn't seem to report consistently.
     
    Nibbels likes this.
  16. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    Thank you :)

    I have to print more face shields rightnow. But after the next face-shield I will try to do another test.

    I edited my height map. First I added a copy of the measured values around my height maps borders.
    Then I inserted a 0.00mm "fence" around the height map. So there are two more columns left and right, two more rows at top and bottom.
    fence.jpg
    Screenshot_1.jpg
    G29 S1 P"heightmap_fenced.csv"
    But that did not work.

    So I prepared a double 0.0-fence height map.

    doublefence.jpg
    upload_2020-4-13_20-16-26.png
    I was not able to test this until know.
    I will do this after the next print.
     
  17. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    No... Tested it. Still an offset when changing tools. And I did not see any change.
    Else the print head is still on the hills of the height map when changing - and causing this.

    Or the Idea was just not working.

    I thought there could be a link to the tool change offsets: upload_2020-4-13_21-19-13.png
    (Yes I wrote T3 instead of T2, T4 instead of T3)

    T0 to T1 adds rounded(!) Z=-0.02
    T1 to T2 adds rounded(!) Z=-0.01 but it is less

    The actual height of the map does not fit, it is 10x the amount I have as an error.

    Maybe I am testing next if a fully negative or a fully positive map does not produce the error.
     
    #37 Nibbels, Apr 13, 2020
    Last edited: Apr 13, 2020
  18. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    164
    Likes Received:
    31
    Hello again.

    I am still searching my shitty problem :D
    But I can report back some things I did.

    0) I printed ~300 Faceshields until now. I guess about 70 to 80 on the Toolchanger. If I do not alter the process and only print with one toolhead. (T0, T1, ..) then this printer has a pretty good repeatability when it comes to Z height (and printing in general).

    About my bug:

    1) I installed Release 3.01-RC9 https://github.com/dc42/RepRapFirmware/releases
    Result: No change. Just a try ...

    2) When I rescan the bed (which is the exact same as before) and move the X/Y-point where I did home Z. Then the whole height map changes its offset. That is because I have another reference point. Everyone knows.
    So my process was:
    - Changing the homeZ XY-coordinate to the most high point which I did spot on my old height map.
    - home Z
    - Rescan a new height map.
    The result was a height map which was shifted down. (However There was a bit of a difference in homeZ-Reference and the same point on the new map.) So all the points on the map have been negative numbers. Except ~10 in one corner which were slightly positive.
    Result: Printing the same piece again produced the (~)same changing offsets between tools as before.

    3) I completely zeroed all the entries within the heigtht map. Even the header ones.
    Then I load the new height map.
    Home Z (with the trick that I press the Z probe early to have alot of space while printing).
    Result: The Bug was not visible anymore asif the auto bed leveling was not switched on. But It was.

    4) I did overwrite the leftover positive entries within the height map to 0.000. But not the header information.
    - Loaded the new height map.
    - Home Z
    Result: Printing the same piece again produced the (~)same changing offsets between tools as before.

    5) I read some closed issue on github where someone was complaining about the z offset of different tools did only work when the first one had the heighest offset. This issue was from 2018 but It looked so nice.
    https://github.com/dc42/RepRapFirmware/issues/118#event-3261164154

    "Z tool offset only considered when positiv (1.19beta6) #118"
    I dont have positive offsets ...

    But I changed my configuration so that I had the same offsets on the first two tools:
    Restart

    G10 P0 X14.1‬0 Y59.75 Z-7.88 ; T0 TitanAero 3mm .67
    G10 P1 X13.64 Y59.52 Z-7.88 ; T1 TitanAero 3mm
    G10 P2 X19.20 Y44.36 Z-5.43 ; T2 Hemera 1.75mm
    G10 P3 X-9 Y39 Z-7.88 ; T3 *NOT INSTALLED*
    The length of the first two tools was set to the same length.
    Result: Printing the same piece again produced the (~)same changing offsets between tools as before.

    The new offset was clearly visible. I will redo this test later and then testing the exact same offset on all the tools.

    6) I found this:

    https://github.com/dc42/RepRapFirmw...e5ceda427af5ba288b/src/GCodes/GCodes.cpp#L689
    But cannot look closer into this rightnow.
    If I really wanted to look into the code I have to be able to compile binarys and that seems to be some work until I can do something good.

    7)
    I am pretty sure that the coordinates which are shown to me are rounded to 2 digits which is bad for me rightnow.
    I forked and checked out the https://github.com/chrishamm/DuetWebControl/ from github.
    Did the configurations in PHPStorm, installed all the packages using NPM. Did a testbuild. I as well was able to do live changes to the UI. Learned some about the Vue-Structure.
    My plan is now to change the UI to show more digits before I continue half blind...
     
  19. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    429
    Likes Received:
    201
    Please can one of you test whether this issue (which I believe is now that the Z=0 position changes when you do a pause and resume) still occurs after you upgrade to firmware 3.01-RC10.
     
  20. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,546
    Likes Received:
    481
    Just upgrading ... will report.
     

Share This Page