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?
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.
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
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.
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
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!
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.
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...
@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?)
RC3 is fine with the profile EXCEPT that extruder 2 is turning the wrong way initially after a startup of the machine. You gotta take of that yourself by extruding at least some negative amount. -1mm or -0.1mm does not matter. This should be done before any other extruder action on the second extruder. http://forum.e3d-online.com/index.p...ings-and-hacked-firmwares-for-the-bigbox.815/
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.
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!
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. X0Y0 must be around the bed mark 0/0 You must have homed with extruder 0 selected. 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...
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...
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: Add T0 after almost every command in start script (And I think also at the end of tool change script) 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.
