Z-axis height way off

Discussion in 'Calibration, Help, and Troubleshooting' started by richgain, Apr 21, 2017.

  1. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    I've just had a really frustrating and puzzling experience. The part I have just printed is one half of a puzzle cube and should be 100 x 100 x 100 mm (minus a 0.1 mm offset on each side).
    X and Y are spot on at 99.8 mm on each axis. The height however, is 114.7 mm - way off!
    Printed in PLA and Polymaker Polysupport on my E3D Big Box Dual Titan Hybrid

    IMG_4153.JPG IMG_4154.JPG

    I've checked the STL file and it's perfect. I've also checked the Simplify3D generated code file and the final layer has a Z value of 99.8, which should be right.
    My Z axis steps/mm (printed straight from the EPROM using M503) are 1600 - unchanged from default.

    Here's my only clue - the puzzle is meant to be 7 blocks high with each block being 14.08 mm tall. The bottom block layer is a bit short at 13.8 mm. The middle 5 blocks are all much too tall at 17.8 mm.
    And the top layer, the only one without support material, is pretty much dead on 14 mm tall.

    Any ideas what on earth is going on here?
     
  2. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    Nobody?!

    OK, well I've had a nice hot bath and laid there thinking for a while (which often helps, but not quite as much as the morning shower ...) and I remembered that when I was 30, I had an IQ of 157 (based on a postal Mensa application form - I didn't join). Now I'm almost double that age, and my little grey cells are undoubtedly dying off at an ever-increasing rate, but I don't think I have lost all my skills as a diagnostician yet (albeit, they are probably better at silicon-based hardware than carbon-based wetware these days) so it shouldn't be beyond me to solve this little mystery by applying some logic.

    I was leaning towards thinking that the only plausible answer was skipping motor steps due to a too low driver current (I haven't actually tested any of this yet), but I couldn't work out how that would make the object taller. Surely, skipping steps on the Z axis would mean less movement and therefore a shorter model??
    Then I realised that there is one possible explanation for the increased height of the print. The 'Oozeless Tool Change' script that I used for this dual-extrusion print includes the following line every time the print-head is changed, just before moving to the dock position:
    Code:
    G91 ; relative positioning
    G1 Z2 F360 ; move Z axis by 2 mm
    G90 ; absolute positioning
    This drops the bed by 2 mm at 6 mm/s (360 mm/min) (gravity assisted - no problem!)
    (Incidentally, Alex's original script included a 5 mm Z move, but I had already decreased this to 2 mm, simply to save time).

    Then, at the end of the purge/prime/wipe cycle, the print head moves to the correct position to recommence printing and then bed must then be raised by 2 mm to restore the correct Z height, e.g.:
    Code:
    G1 X170.140 Y51.320 F12000
    G1 Z85.600 F360
    The printer is trying to raise the bed by 2 mm at the same speed, but against gravity!
    If the current was fractionally too low, the motors would be most likely to skip at this point, and failing to restore the bed back up to the correct position would definitely result in the layer height being fractionally taller, and the whole print significantly taller as a result.
    This would also explain why the top set of blocks printed at the correct height - no support means no tool changes, so no 2 mm drop on every layer.

    I think the next step is to measure my voltage on the Z axis driver and increase it a bit before running some test prints.
    Any suggestions for a good setting?
     
  3. Ephemeris

    Ephemeris Well-Known Member

    Joined:
    Nov 25, 2015
    Messages:
    388
    Likes Received:
    241
    Stock steppers and Rumba with GeeTech stepper drivers? The stock Wantai 42BYGHW609 steppers are rated at 1.7 amps/phase. You could try running them at 1.5 amps as a test of your theory.
     
    richgain likes this.
  4. Stian Indal Haugseth

    Stian Indal Haugseth Well-Known Member

    Joined:
    Sep 11, 2015
    Messages:
    589
    Likes Received:
    100
    Following this thread. Defiantly something to watch when doing dual printing.

    My initial thought that this could have something to do with microstepping. Every now and then you pause and adjust Z when the motor is in not fortunate positions it would be easier for the motor to jump back to the whole step. But then not sure how they can add up over time.

    What's your layer height?
     
  5. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    @Ephemeris - I increased my Z stepper voltage from 0.56 to 0.8 volts. I don't think it has made any difference.

    @Stian Indal Haugseth - I've been using various layer heights between 0.1 and 0.2 mm. All cause problems when I am dual extruding.

    I tried printing an alternating tower of cylinders 50 mm tall. This printed accurately but there were only four filament swaps, so not really a good test.
    Then I tried printing a dual-colour tree frog. He looks great but the eyes are oval instead of round. The feet are also much taller than they should be. I printed a single extruder copy of the same model for comparison and put them side by side. Both were printed at 0.1 mm resolution at 30 mm/s.
    You can clearly see that when a layer uses both extruders, the layer height is higher than it is supposed to be. This is most noticeable in the last picture.

    IMG_4192.JPG

    IMG_4195.JPG

    IMG_4199.JPG

    IMG_4197.JPG

    There are a number of variables I can try eliminating, one by one:
    • Z hop
    • Filament change script
    • Mesh Bed Levelling
    • Micro-stepping
    Any other suggestions?
     
  6. Stian Indal Haugseth

    Stian Indal Haugseth Well-Known Member

    Joined:
    Sep 11, 2015
    Messages:
    589
    Likes Received:
    100
    Maybe open a issue in GitHub for Marlin? If no one here can help.
     
  7. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    To quantify the problem, I printed two cubes 20 x 20 x 20 mm, using a different extruder for each cube.
    I will attach the STL and the Gcode file here in case anyone cares to try and inspect them.
    Please bear in mind that this was sliced for my printer configuration (BigBox Hybrid Dual Mirrored) and probably won't work on anything else.
    Here are the results:
    X = 19.93 mm
    Y = 19.93 mm
    Z = 23.44 mm
    So when I dual extrude the Z axis dimension is coming out 17% taller than it should.
    All the layers seems to be a very consistent height - just consistently wrong!

    IMG_0869.JPG
     

    Attached Files:

  8. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    Done a bit more thinking. Current best guess is that it may be a bug in the MBL code that is interacting with the 5 mm Z lift in Relative mode during the tool change script.
    Here is a macro-photo of the layers on the support cube after drawing a line across the surface. You can see that the normal layers and fat layers alternate absolutely regularly.
    I think this means we can rule out skipping steps which would be be much more irregular.

    layers2.JPG
     
    #8 richgain, May 6, 2017
    Last edited: May 6, 2017
  9. Paul Winter

    Paul Winter Well-Known Member

    Joined:
    Jun 11, 2016
    Messages:
    50
    Likes Received:
    9
    Different size nozzles on the two extruders?
     
  10. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    Not that simple, I'm afraid, @Paul Winter. Both nozzles are 0.4 mm.

    Well, I did another trial of dual extrusion after removing the Z-lift from the Tool Change Script in Simplify 3D, and got exactly the same result - my 20 mm cube has a height of 23.44 mm - the one on the right in the picture below.

    Then I decided to print the same models with the same 'Both Extruders Oozeless/Ram purge' extruder setting, but opted to print both cubes using extruder 0. This time I got two perfect cubes, accurate to within 0.02 mm.

    perfect.JPG

    What is going on here?!
     
    Paul Winter likes this.
  11. Paul Winter

    Paul Winter Well-Known Member

    Joined:
    Jun 11, 2016
    Messages:
    50
    Likes Received:
    9
    I thought I had 2 x 0.4mm nozzles on my hotends........
    Nope, one of them (one of my newest nozzles) is considerably narrower than the older 0.4mm nozzle.
    Unfortunately the only way I have to check the nozzle size is using a piece of steel guitar string and poking it up through the nozzle, as if I was unblocking it. Eyeballing the nozzles shows me they have different size apertures, but they are identically coded on the hex flats.

    Those are some awesome sharp cubes :)
     
  12. Paul Winter

    Paul Winter Well-Known Member

    Joined:
    Jun 11, 2016
    Messages:
    50
    Likes Received:
    9
    I thought I had 2 x 0.4mm nozzles on my dual hotends.....
    Nope, turned out that one of my newest nozzles (Tool 1), specified as a 0.4mm is significantly narrower than it should be. Not sure why, as it is coded as 0.44 using the dots on the hex flats, the same as the coding on my older nozzle (Tool 0).
    The only way I can measure the aperture is by trying to push a length of steel guitar string up the nozzle, as if I was trying to unblock it.
    Caused me no end of grief so far.
     
  13. Paul Winter

    Paul Winter Well-Known Member

    Joined:
    Jun 11, 2016
    Messages:
    50
    Likes Received:
    9
    I could be wrong, but I think the clues are in the tree frog's orange feet. The top surfaces are badly finished, possibly indicating a layer height to extruded filament height mismatch.
    Check that the extruder feed rates and step sizes are identical.
    If layer height, nozzle diameter, extrusion multiplier, and extrusion width are all identical, then all that's left to cause differences between the green and orange parts of the model would be the material characteristics.
    I would take the extrusion width off auto (set a manual value for both hotends), load up both extruders with the same material (choose the green, as it showed the best results on the frog), and reprint the frog as a dual extrusion, with the same temperature on both hotends (after checking that they are both measuring the same ambient temp before starting).

    Did you also do this for extruder 1?

    I'm so dying to find out what the answer is!
     
  14. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    Good idea, @Paul Winter.
    I have just repeated the previous test using extruder 1 (instead of 0) and the results are quite conclusive.
    Another perfect pair of cubes - the light blue ones in the photo.

    IMG_0055.JPG

    The next test is going to be another pair of cubes printed using Both Extruders, instead of Both Extruders Oozeless/Ram purge, to see if that makes a difference.
     
  15. Stefan

    Stefan Well-Known Member

    Joined:
    Feb 17, 2016
    Messages:
    324
    Likes Received:
    43
    hmm.... I do not think it's an extruder issue as @Paul Winter suggested. Under extrude would make holes, over extrude... more plastic than height so the nozzles would scretch in the part.
    it might be this extruderRetractionZLift,0.25,0.25 with the tool change script.
    This is a z hop on retract.

    But I have no ex with Dual, since I never was able to align the nozzles :(
    One day I may go IDEX but with other hotend mounts :) I do not like the default mount design.
     
  16. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    From left to right:
    Original pair of cubes printed with [Both Extruders Oozeless/Ram purge]; height = 23.44 mm
    Cubes printed with [Both Extruders] profile; height = 22.82 mm
    After manually adjust the bed and then repeating the Mesh bed Levelling, (all other settings the same)
    two more cubes printed with [Both Extruders] profile; height = 22.38 mm
    Two cubes printed from Extruder 0; height = 20.00 mm
    Two cubes printed from Extruder 1; height = 20.00 mm

    IMG_0897.JPG

    So here are my conclusions.
    1. It's not the filament - almost identical results with different filaments.
    2. It's not the nozzles - cleaned and checked the nozzles and got the same results.
    3. It's probably not the Z-hop, because this works fine with a single extruder and removing it doesn't help.
    4. It only happens when printing with Both Extruders
    5. Adjusting the MBL setting does affect the results
    6. I think the regularity of the increase in layer height on every other layer makes missed steps very unlikely
    7. I've been reviewing the Marlin issues list since the recent release of 1.1.0 firmware and a great many MBL issues appear to have been fixed. I'm still on 1.1.0 RC6 (@Alex9779 's Marlin-BigBox-Dual-RC build)
    In summary, I still think it's a bug in the firmware and I'm very tempted to try the new release and see if the problem goes away.
    I've now got a stack of orders waiting, that I would have used soluble support material for, but I can no longer trust the accuracy of the parts until I get this fixed.
     
  17. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    I've spent the weekend reviewing the Marlin issues and looking for possible reports of this type of problem. I haven't found the exact issue reported by anyone else, but even if I did, I suspect it would not be worth fixing because the firmware has moved on so much since RC6, the version I am still using. I did find several reports of Mesh Bed Levelling interacting with Tool switching. For reference, these are the kinds of problems that sound somewhat similar to mine and make me think that a newer version of the firmware might already contain the solution to my 'Stretched Z height' issue:
    Tool offset not working (RCBugFix) #4182
    Fix position shift with MBL #4310
    Issues when switching tools (RCBugFix) #4266

    I'm now in the process of trying to adapt the new 1.1.0 release to my printer's configuration and once I've got everything working again I hope to be able to repeat my cube test using both extruders to see if the Z height is correct.
    I'm dealing with the Head Crashing when Docked problem using @Alex9779 's reverse tool head move logic on tool change code change, rather than @Greg Holloway 's 'S1 disables the auto-move' slicing method.
     
  18. richgain

    richgain Well-Known Member

    Joined:
    Dec 18, 2015
    Messages:
    73
    Likes Received:
    35
    Hi @Alex9779 . I copied all the changes in your 'reverse tool head move logic on tool change' code change but when I tried to print some gcode which started with
    Code:
    G90
    M83
    M106 S0
    ;BigBox Hybrid-Dual Mirrored Start Script Begin
    ;relies on M83 (use relative extrusion distances)
    ;home
    T0 ; select extruder 0
    G28
    M420 S1
    M117 Preparing
    I got an unhandled communication error
    The only clue I could find was one additional reference to 'no_move' in the 1.1.0 release version of Marlin_main.cpp:
    Code:
    // Only when auto-parking are carriages safe to move
    if (dual_x_carriage_mode != DXC_AUTO_PARK_MODE) no_move = true;
    Could that be important?
    If not, do you know what else might be causing this?
    Thanks.
     
  19. Greg_The_Maker

    Greg_The_Maker Administrator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    1,035
    Likes Received:
    633
    This is an interesting thread @richgain . I have had similar issues with the machines here and I was putting it down to bad stepper drivers and missed steps.

    I have found that the issue has stopped when I shifted to the dual idex system running on RC6.

    I have since tried to swap to 1.1 but ran into a problem where MBL fails to finish. I've not had the time to investigate more just yet.
     
  20. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,411
    Likes Received:
    735
    @richgain sorry no idea... I didn't work with the Marlin code a long time so...
     

Share This Page