Carriage crashes into back of printer after print abort?

Discussion in 'Calibration, Help, and Troubleshooting' started by wfredette, Apr 3, 2016.

  1. wfredette

    wfredette Well-Known Member

    Joined:
    Jan 11, 2016
    Messages:
    89
    Likes Received:
    25
    Has anyone else encountered this problem? If I have to stop a print from SD, even after I auto home the printer before starting the print, the hot end carriage misses the dock and crashes into the back of the printer. Is there any workaround for this other than power cycling the printer after aborting a print?
     
  2. goose117

    goose117 Member

    Joined:
    Sep 5, 2015
    Messages:
    22
    Likes Received:
    13
    does it hit the back before or after it reaches the dock? I had an issue where it would move sideways when attempting to leave the dock after a tool change. This was due to some hidden startup GCode in S3D I found.
     
  3. Falc.be

    Falc.be Well-Known Member

    Joined:
    Sep 4, 2015
    Messages:
    244
    Likes Received:
    38
    are you sure you used the right motor ? there are 0.9 and 1.8 motors, carriages need the 0.9. sounds like you may have used the wrong one
     
  4. wfredette

    wfredette Well-Known Member

    Joined:
    Jan 11, 2016
    Messages:
    89
    Likes Received:
    25
    Well, the problem occurs only in that specific circumstance - after a print from the SD card is aborted and then I try to restart. Otherwise the carriage reaches the dock, does its purging, and leaves the dock without a problem. When a print from the SD card is stopped for any reason ("print aborted" message appears), and the carriage is auto homed, it will head back toward the dock when everything is heated up and ready to print, but instead of following it's usual path (heading diagonally toward the right rear of the build plate for a while, and then changing direction to straight back to enter the dock), it just keeps heading on the diagonal, and hits the back of the printer to the right of the dock (all of these directions are described as looking from the front of the printer). If I power cycle the printer after an aborted print, it works as designed.
     
  5. Rob Heinzonly

    Rob Heinzonly Well-Known Member

    Joined:
    Sep 20, 2015
    Messages:
    362
    Likes Received:
    125
    Are you using S3D as slicer ? It at least looks like it. Is your starting script the same as mine ? The last two lines describe the movement to the dock as you described. Maybe it also could be some sort of bug in the Marlin firmware.

    ;BigBox Printer Start Script Begin
    G28

    M117 Print Starting.

    ;Dock
    G1 X70 Y200 F3000
    G1 X70 Y240 F3000
     
  6. wfredette

    wfredette Well-Known Member

    Joined:
    Jan 11, 2016
    Messages:
    89
    Likes Received:
    25
    Yep. Simplfy3D, and the script looks almost the same except for G28. So, although I am autohoming after I stop a print, maybe it's somehow confused as to where it is? I'll add that G28 and see if that helps. Thanks!
     
    Rob Heinzonly likes this.
  7. R Design

    R Design Well-Known Member

    Joined:
    Oct 7, 2015
    Messages:
    918
    Likes Received:
    183
    I have experienced plenty of "situation specific" bugs in Marlin 1.1 RC3 like this and resulting in upsetting crashes into hard parts of the machine.

    Which is why I can't wait for RC4 (released last week) to be validated by the BB team.

    I simply try to remember the sorts of things that can go wrong and to avoid the circumstances in question.

    Usually after stopping a print I do a move / y axis and send the print head back a bit (but carefully stopping short of the back wall!!) so I can clean up the print bed and start again. I find that sequence works fine, which is to say if I then do an "autohome" and a "bed level" there are no crashes and the next print starts fine (with the added advantage nozzle and bed are still hot from the previous attempt).

    So, just avoid what causes crashes and pray for RC4.
     
  8. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    I just have to say something to this.
    IMHO and from what I experienced with my dual is that crashing the head into the back or side is just a matter of what you do in your gcode and on your machine.
    RC4/5 does not change anything that could help that this does not happen!
    The problem is more related to the dual setup and how Marlin handles dual heads and XY movements with multiple hotends.
    It is all about the correct offset, offset is cleared when you auto home.
    All about which hotend is active when auto homing. Not from the LCD though, from there Marlin homes to extruder 0.
    All about which hotend is active when doing moves especially when going to the dock which is a special point because it is outside the normal printing range and that space is not available over the whole back side.

    I had problems myself and I wrote it up multiple times now that he profile provided for dual is NOT fail safe! You have to know what you have done on he machine before running code generated by that profile. You have to do things on the machine when a print ended, different things when a print failed, to bring the machine back to the state just to start the same print again and with the same gcode file. And so on.

    That's why I created the new profile and the start, the altered tool change and the end script. I intensively tested it to be fail safe. For not having to do anything on the machine before starting a print. To being able to start a print on the machine in any state, booted, finished or failed.

    Sadly it seems my posts are not being recognized as such and my profile is not being used by a lot of people. I didn't get any feedback yet so...

    I just can post it again, go to my Github profile, have a look at the S3D profile and trust me a bit. If you don't wanna dig into what's happening before and after a print then I only can recommend it.

    Cancelling a print is somehow different because it depends where you cancel.
    On the machine if you print from SD there is nothing you can do while in OctoPrint you can add a cancel script. I could post mine, it move the Z my 10mm down and the moved the head to the dock. Same I do on the end of a print.

    To emphasize: when starting a print you have to be sure that the machine is in a state the first gcode commands in your print file can handle that state. If you use the provided profiles this is not normal. You gotta do something for it. And the provided profile lacks the ability to use the drops owns because it is not properly setup. It is just as it is, if you change something on the drop down you end up in an undefined state. For example if you switch to only one extruder then back to dual the tool change script does not come back...
     
    mike01hu likes this.
  9. Henry feldman

    Henry feldman Well-Known Member

    Joined:
    Sep 5, 2015
    Messages:
    969
    Likes Received:
    389
    @Alex9779, are you talking combo of the new firmware and the S3D profile, or just the S3D profile? I am planning to update shortly to your stuff, but the S3D is trivial to do, while firmware of course is more of a serious change and I have some stuff I need to get out. Did I miss the post of your S3D profile? (if so, can you just reply with the link?)
     
  10. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
  11. Clive

    Clive Member

    Joined:
    Apr 19, 2016
    Messages:
    2
    Likes Received:
    0
    I am also having the same problem with the extruder crashing into the back of the printer.

    It seems that it needs calibrating so it knows how big the print bed is.

    Advise welcome.
     
  12. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    Please post a gcode file you trying to print...
     
  13. R Design

    R Design Well-Known Member

    Joined:
    Oct 7, 2015
    Messages:
    918
    Likes Received:
    183
    There are many situations in which Marlin loses track of where the print head is.

    After a few crashes one learns not to "trust" it any more and so, when moving the print head back with the dial control, stop well before the edge of the bed!
     
  14. Alex9779

    Alex9779 Moderator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    2,405
    Likes Received:
    731
    Yeah but that's is only because Marlin has not option to configure our special "ooze bucket position".
    For Marlin the build volume is always a cube, no exception possible, so for Marlin we have a build volume of 300x235x300 (Hybrid setup) or 260x240x300 (V1.0 Dual)...
    So for Marlin X0 Y240 is valid though we cannot move there. Actually only X~70 - X~110 is save to move beyond Y200...
    And there are several requirements that the position you tell the machine to move are at those positions.
    1. X0Y0 must be around the bed mark 0/0
    2. You must have homed with extruder 0 selected.
    3. You must have homed (!), if you moved the head the positions can be off. If you crashed into the bed the positions are off because Marlin think it reached the position!
    I can't remember RC3 anymore but in the builds I used the last two weeks the X, Y and Z letter on the LCD blink if Marlin is not sure if the position it displays are correct. When you home the letter do not blink until the steppers are powered off, then they start blinking again...
    Other reasons as told above can't Marlin detect, you gotta take care of...
     
  15. Clive

    Clive Member

    Joined:
    Apr 19, 2016
    Messages:
    2
    Likes Received:
    0
    Yes but how do you set it so it does not go out the print area for a dual extruder?

    When I try to level the bed it thinks the bed is much bigger than it is and crashes into the side and back...
     
  16. Miriam

    Miriam Active Member

    Joined:
    Mar 7, 2016
    Messages:
    28
    Likes Received:
    4
    I got to the conclusion that the issue is due to "confusion" what is the current tool head to be used.
    to resolve this I:

    1. Add T0 after almost every command in start script (And I think also at the end of tool change script)
    2. have the recommended G28, G29 sequence at the beginning of print (I think that actual #1 is enough)
    It seems to have worked for me.

    Here is the homeing section in my start script:

    ; Homeing
    T0
    G28 ; home
    T0
    G29 ; check mesh enabled
    T0
    M117 Print Starting.



    Miriam.
     

Share This Page