1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

Answered R1+ printer sometimes ejecting filament before print

Discussion in 'Troubleshooting' started by Rod Smith, Nov 12, 2017.

Thread Status:
Not open for further replies.
  1. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    I received my Robo 3D R1+ on Friday, did a couple of test prints from macOS using MatterControl, and then hooked up a Raspberry Pi and began printing with a combination of MatterControl and IdeaMaker from Linux. Since that time, I've had sporadic problems with the printer retracting filament before beginning a print. The printer will home, go through its bed-leveling routine, and then retract filament. Sometimes this just causes a delay to extrusion, which is tolerable if I'm printing a big enough object with a skirt; however, sometimes the printer never grabs ahold of the filament and extrusion never begins, or it retracts far enough that the filament pops out of the head entirely. In either of the latter two cases, I've got to re-load the filament into the print head.

    Note that this problem is sporadic; it happens on some prints but not on others. At first I thought that the problem was related to configuration files on one of the two computers I've been using to slice my prints, since re-slicing on the other computer usually cleared the problem; but then I discovered that the same pre-sliced .gcode file will work fine on one print but cause the filament-ejection problem on the next run.

    Here are the first few lines from the latest file I tried printing that's exhibiting this problem:

    Code:
    ;Dimension: 222.000 245.000 200.000 0.400
    ;Extruder Offset #1: 0.000 0.000
    ;Extruder Offset #2: 0.000 0.000
    ;Extruder Offset #3: 0.000 0.000
    ;Filament Diameter #1: 1.750
    ;Filament Diameter #2: 2.930
    ;Filament Compensation #1: 94.00
    ;Filament Compensation #2: 100.00
    ;Filament Density #1: 1240.00
    ;Filament Density #2: 1300.00
    ;Model Gap: 0.000
    M221 T0 S94.00
    M140 S60.00
    M104 T0 S210.00
    M109 T0 S210.00
    T0
    M190 S60.00
    G28 X0 Y0 Z0
    G1 Z5 F5000
    G28 X0 Y0 Z0
    G29
    M1001
    ;LAYER:0
    ;HEIGHT:0.300
    M106 S0
    G1 F1200 E-1.0000
    G0 F3600 X86.120 Y79.698
    G0 F3600 Z0.800
    ;TYPE:SKIRT
    ;WIDTH:0.400
    G1 F1200 E0.0000
    G1 X135.879 Y79.698 E2.4825
    In IdeaMaker, the start g-code ends up in the above output, from the first G28 to G29. (I took this from the default MatterControl configuration, minus an M109 line that I saw was redundant.) I can easily edit the IdeaMaker g-code, if something in it is incorrect; or I can transfer that to OctoPrint or add something there.

    The only thing I notice here that's suspicious is the "G1 F1200 E-1.0000" line, which if I'm reading it correctly, says to extrude -1.0000 amount of filament, but I don't know what's generating that line. The fact that the problem is sporadic is very weird if this is the cause, though, since this same file both did and did not produce the problem for me a few minutes ago.

    I haven't noticed this problem when I prepare a print using MatterControl, but it's crash-prone in Linux, not to mention slower and less capable, so I prefer to keep using IdeaMaker. Also, since I use IdeaMaker much more than MatterControl, I can't promise that the problem would not occur with MatterControl. I'm willing to consider some other slicer software.

    So, any suggestions on how to fix this?
     
  2. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    That is all generated by the slicer so ... another slicer would be the first thing to try.
    That the is needed in the startup block is the twp you have:

    G28 X0 Y0 Z0
    G29

    plus a Z offset for the slicer:

    G28 X0 Y0 Z0;
    M565 Z-1.0; you will off course need to tweak this for your printer.
    G29;
     
    Geof likes this.
  3. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    FWIW, I tried hand-editing the "G1 F1200 E-1.0000" to ""G1 F1200 E0.0000" on a print last night and it printed OK -- but given the sporadic nature of the problem, that may just be coincidence.

    I'll try examining all my settings to see if there's something there that's causing the problem. If not, I'll report it as a bug to the developers, and look into alternative slicers. (I picked IdeaMaker because it's fast, reasonably full-featured, and seemed stable on Linux. Some popular ones have serious problems; Cura takes forever to launch and is a tad unstable thereafter, Slic3r has a primitive user interface, and MatterControl crashes if you look at it wrong, for instance.)

    As to M565, I tried that, but it didn't seem to have any effect -- but maybe I did something wrong. Instead, I've been setting the Z-axis offset in the slicer's configuration (which of course is set differently for each one).
     
  4. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    The global Z axis offset is not the same as the M565 (sadly)
    One is a global offset and the other is applied only to the autoleveling calculations.

    M565 must be after the last G28, before the G29 and all uppercase of course.
     
  5. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    Could you elaborate on this? The distinction you're making is largely lost on me. Thanks.
     
  6. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    A global Z offset is applied to all the points calculated for the 1st layer. Period. If a point is supposed to be (pulling a number outta my pocket) 0.124 and you have a global Z offset of 0.02 then that point becomes 0.144 and so on for ALL points on the 1st layer. It is a simple + Z offset to whatever the slicer generates.

    When you use the M565 it sets a Z offset for the autolveling calculations and in that case the math which calculates the level plane for the Z includes a Z offset as a factor into the math. This does not mean that the number calculated is (for example) -.02mm higher... does that make sense. The output from the algebra is not then bumped 0.02mm rather the 0.02 is factored in as a part of the calculations -- but not the ultimate factoring, rather one of the first stages of factoring. Marlin ABL uses math to calculate a level plane that intersects all of the sensed points and a part of the equation takes into account the Z offset for the sensed positions. So then when later commanded to go to a Z height as part of the GCode it assumes the calculated Z position (in that X/Y coord) for home
     
    #6 mark tomlinson, Nov 13, 2017
    Last edited: Nov 13, 2017
  7. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    The slicer is a math machine... all it does is a ton of math :)
    In this case the firmware is getting involved.
     
  8. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    OK, so if I understand correctly, by using the Z offset rather than M565, I've basically been wiping out the Z-axis auto-leveling of my machine? That might explain some of the problems I've been having (but not the one that spurred this thread), and I'll have to poke around again with M565. Is there a documented procedure somewhere for how to determine the correct M565 value? I've seen lots of posts that reference it, but none that explains how to figure out what number to plug in, and when I tried using the negative version of the Z offset I determined through trial and error, it didn't seem to work, so I don't think simply copying that number will do the trick.

    FWIW, and related to the thread's subject, I tried CraftWare this evening. It included a "G1 F1200 E-1.0000" line (it might have been another F value, though), and partially retracted the filament, to the point that it wasn't printing, so I aborted and started over with MatterControl. Maybe I'll bite the bullet and try to decipher Slic3r's UI next....
     
  9. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    I'll document it for you here :)
    1) start with -1.0
    2) print a 1 layer test print (like the attached one -- size it to fit bed)
    3) if the first layer looks like this: https://printedsolid.com/blogs/news/37035715-get-your-prints-to-stick-check-your-skirt You are done
    4) otherwise tweak that offset and go to #2

    More negative (i.e. -1.1) is further from the bed, less negative (i.e. -0.9) is closer to the bed

    :)
     

    Attached Files:

    Geof likes this.
  10. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    Thanks for the pointer! I'll look into that ASAP (which at this point will be tomorrow, since I've got a print going now with an estimated finish time past midnight).

    FWIW, I also discovered a retraction setting in the IdeaMaker "Advanced" template setting dialog box, on the "Ooze" tab. Unchecking the retraction option caused the "G1 F1200 E-1.0000" line to disappear from generated g-code, so maybe that'll fix the problem. I'll have to wait until tomorrow to test that, though.
     
  11. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    23,912
    Likes Received:
    7,338
    Oooze is handled by retraction (in the normal course of events*) so that makes sense


    *things like flexible filaments add a new layer of confusion to this, but in general there you go.
     
  12. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    I've created a new thread concerning the Z-axis issues.

    Back to the main question, in doing my Z-axis tests, the printer did its filament retraction thing a couple of times (twice in about a dozen test runs), despite the fact that I'd disabled filament retraction in IdeaMaker. Thus, I don't think that "G1 F1200 E-1.0000" was really the source of the problem. Given that the same g-code file can produce the problem on one run but not on the next, I'm starting to think this may be the printer's firmware trying to compensate for a filament feed problem that either doesn't exist or that's not apparent to me. Does anybody have suggestions for how to investigate this further?
     
  13. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    FWIW, I think that this filament-retraction problem occurs only, or at least more frequently, after canceling a print. Perhaps this is a firmware bug, or maybe OctoPrint is doing something wrong in the way it cancels prints. (Since my last post in this thread, I've upgraded to Marlin 1.1.6, and that has not fixed the problem.)

    Once the problem occurs, or as a precaution after canceling a print, disconnecting from OctoPrint and/or power-cycling the printer prevents the problem from recurring/occurring.
     
  14. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,905
    Likes Received:
    3,593
    Rod, OctoPrint by default has some scripts built in Settings >> GCode Scripts, there is one that runs when you cancel a print. If you don't want anything to happen when you cancel then empty out that script edit box and resave the settings.
     
  15. Rod Smith

    Rod Smith Member

    Joined:
    Nov 7, 2017
    Messages:
    87
    Likes Received:
    33
    Yes, I know about the OctoPrint-specific scripts. I just haven't had a chance to investigate them yet with respect to this problem.
     
  16. Nate Lowrie

    Nate Lowrie New Member

    Joined:
    Nov 1, 2016
    Messages:
    20
    Likes Received:
    2
    So, I had the same problem you did and it was driving me nuts. I finally figured it out. In my startup script I had some code at the beginning to prime the extruder and wipe the nozzle. The was a G1 F200 E3 command in there.

    Well, dummy me didn’t realize everything was in absolute coordinates. So, what was happening was whenever I would cancel a print in OctoPrint OR manually extrude, the counter is no longer 0. It’s some other number. So, if you manually extruded say 50mm, your Z counter would be 50 and then during the pump prime I am moving to 3mm absolute, so the software retracts 47mm instead.

    the reason disconnecting and power cycling was working for you was it reset the Z counter.

    You can reset the absolute positioning by doing a G92 E0 and simplify does do that before starting a print but that was AFTER the wipe command processed. So, if I did any manual extrusion it messed up the Z location and it would retract.

    So, I did 2 things to put in place as a stop gap

    1) Changed the extruder prime code to:

    G92 E0
    G1 F200 E3
    G92 E0

    this resets the absolute position counter to zero before the primer code extrudes 3mm and resets the counter to zero afterward.

    2) in the OctoPrint gcode scripts, I set the “Before Print Job Starts” script to:

    M82
    G92 E0

    The M92 sets the extruder to absolute coordinates and the G92 command resets the Z counter.
     
Thread Status:
Not open for further replies.

Share This Page