Odd G-code behavior from Prusaslicer
Hello, I am new to the forum and am here because I have been trying to troubleshoot this problem for literal months now with no progress and have decided that now is the time to get some outside help!
I have an Ender 3 Pro 1.5 (32 bit board) with many upgrades such as dual z lead screw kit, an off brand BLTouch, and other cosmetic mods. Since I've done the hardware upgrades myself, I also had to learn how to achieve the correct software configurations of marlin in order for the printer to work correctly. Every once in a while there are some hiccups with the auto bed leveling feature, but I'm able to get past them with minimal effort.
The problem that I am encountering with PrusaSlicer has been a problem for 6+ months and has ultimately resulted in me using Cura (which is not ideal, Id rather learn and use PrusaSlicer). Whenever I generate and upload a G-code file from Prusa to the printer via the microSD card and begin the print, the printer will run through most of the custom start g-code just fine, but thats as far as it gets.
After heating the nozzle and homing the printer, nothing happens, the nozzle and carriage just sit still, not moving at all. Meanwhile, on the LCD, the screen indicates that the print is ongoing, however, the progress bar and time elapsed are waaaayyyy shorter than the print should be taking (the printer says the 11 hour job is complete after only 3 minutes of no movement).
Now, the printer never got to the "prime nozzle" section of the start gcode, so i suspected that of causing the problem, but when I remove that portion, the printer still does the same thing-- stops after homing.
For reference, here is the start gcode I dumbed down to hopefully find where its going wrong:
G90 ; use absolute coordinates
M83 ; extruder relative mode
M140 S55 ; heat bed in background
M109 R210 ; heat nozzle and wait for temp to stabilize
G4 S10 ; dwell for 10 seconds
G28 ; home all axis
**THIS IS WHERE THE PRINTER STOPS MOVING, BUT THE "JOB/PRINT" SUPPOSEDLY BEGINS**
G1 X2 Y10 Z0.28 F240
G92 E0
G1 Y140 E10 F1500 ; prime the nozzle
G1 X2.3 F5000
G92 E0
G1 Y10 E10 F1200 ; prime the nozzle
G92 E0
Based on where it stops every time, it seems the problem is with the home all axis function, but if thats the case, then why does the printer "think" its moved onto the actual print (when in reality, its doing nothing)?
Any help would be much appreciated, I'd like to be able to use the superior slicer, IF ONLY IT WOULD WORK!
RE:
A few points. M140 does not wait for temp to be reached. The G4 S10 should be removed. Unless RESTORE_LEVELING_AFTER_G28 is set in Marlin firmware bed leveling will be disabled by G28. I suggest you put G28 as the first line and M420 S1 (may not be necessary but will do no harm). Add M117 not hung (will display this message on LCD) as the next line.
Hope that helps.
RE: Odd G-code behavior from Prusaslicer
M140 does not wait for temp to be reached.
Yep, I know, I chose for it to be like that (as evident by the comment I added after the M104 command "; heat bed in background") because I don't want to have to wait for the bed to heat up completely before the hotend will even begin to heat up. With M140 the bed and hotend will heat up at the same time (because of M109 as the next command); since the hotend takes longer to heat up to full temp than the bed, I'm not worried about the printer moving on without heating the bed fully.
The G4 S10 should be removed.
How come? I have this command there because my printer often heats up so fast that it overshoots the defined hotend temp by ~2 degrees and needs a few seconds to equalize back down to the desired temp. In the 10 seconds that this command allows the printer to dwell, the temp has stabilized and wont give any problems when priming the nozzle. I dont see how it could be a problem, however if you have any evidence as to why it shouldnt be there or how it could be causing problems, then I'm definitely willing to listen and follow suit. In the meantime, ill exclude it for a few test to see if the printer will begin to work normally without it (I hope its as easy as removing a single line lol).
Unless RESTORE_LEVELING_AFTER_G28 is set in Marlin firmware bed leveling will be disabled by G28.
I know that I do have RESTORE_LEVELING_AFTER_G28 enabled in the firmware, I remember uncommenting it myself. Ill probably be reflashing another modified firmware again sometime soon, so when I do that ill just double check and be sure that RESTORE_LEVELING_AFTER_G28 is enabled.
I suggest you put G28 as the first line and M420 S1 (may not be necessary but will do no harm).
Ill try putting G28 as the first line and see if anything changes, but as for M420 S1, Id rather not add any additional, non-critical commands in fear that the problem becomes more complicated. IMO a simpler gcode leads to less problems and/or easier troubleshooting. I do remember having the ENABLE_LEVELING_FADE_HEIGHT enabled in the firmware, and since I have RESTORE_LEVELING_AFTER_G28 enabled, as stated above, M420 should be set as enabled anyways. I suppose a lack of an M420 command upon a print start when the firmware has ENABLE_LEVELING_FADE_HEIGHT enabled in firmware could possibly be a problem (but shouldnt be because the firmware does have initial conditions for the fade height), so ill try adding M420 S1 Z10 and see if anything changes.
Add M117 not hung (will display this message on LCD) as the next line.
Good idea, I will definitely do this! Thanks for the suggestion. Hopefully it'll help with diagnosing where exactly the problem is.
Thanks for all your suggestions, ill definitely be giving each one a try and ill update whether there are any changes or not!
RE: Odd G-code behavior from Prusaslicer
Hey, so I did all the suggestions that were mentioned, and now the printer works enough to get started; YAY! I'm not sure as to which suggestion lead to the success, as even when I tried changing only an individual suggestion at a time, it worked regardless of which was changed, so technically, theres still no definitive answer on what was causing the problem in the first place, but I'm okay with that.
However, getting started was about as far as it got before I ran into an even larger problem 🙁 ughhhhh
Once the print actually starts and gets the first layer down, there are now increases in layer height. By that I mean that once its time to move up by 0.2 mm and start laying the next layer of plastic, the printer just doesn't move up.
This leads to the extruder stepper skipping as filament is trying to be pushed directly into the layer that was just put down. I have no idea what could be causing this issue now! It seems like the 3dPrinter gods just really dont want me to use Prusaslicer, which is unfortunate.
To rule out the obvious, no its not the z axis steppers (of which there are two, and both wont move), and its not a burnt out stepper driver (Cura still produces perfectly printable gcode). It has to be some sort of software/gcode issue, my guess is with the custom 'before' or 'after layer change gcode' setting within prusaslicer, but I never even touched that preset code, so I dont know why it would cause problems.
If anyone could please help, I would be so grateful!
RE: Odd G-code behavior from Prusaslicer
Can you save a project from Prusa slicer, any model that’s having an issue, just use file>save project as. Take the resulting 3mf and then ZIP it up and attach it to a reply here. Must be zipped for the forum to accept the file.
With a project we can see all the settings you are using and get a a complete picture. It’s the most efficient way to get help as it won’t mean a game of 20 questions.
Also if you could include in the zip file a sample of gcode produced by Cura that does work please as that way we have something to compare.
RE:
Thanks for letting me know how to share my files in the forums. Im sure it will come in handy later, unfortunately though I'll have to close this thread. For some reason, after a 100% clean install of prusaslicer (making sure to get rid of all supporting files and such before reinstalling), I re-made the profile I had been using before from scratch, and it seemed to solve the problems I had encountered and explained in this thread. In that time though I also began running into problems rooted in the firmware of my printer (latest marlin bugfix 2.1.X) and have been trying to troublshoot that with no luck. Seeing as this is a Prusa forum, I wont bother asking for help with my ender machine running Marlin. Thanks for your guyses help, It means a lot to me since I have literally nobody else to ask for help : ) I attached my file that ended up working just in case you wanted a peek, but you definitely don't need to.
RE: Odd G-code behavior from Prusaslicer
FWIW Word to the wise best avoid bugfix versions of Marlin.
RE: Odd G-code behavior from Prusaslicer
Thanks for this info; would you mind sharing why that is? I'm interested to hear the reasoning because from what I've heard, people often say to use the big fix version instead because it includes patches for known bugs in the latest main release of marlin. I just want to know both sides of the argument for which build of the firmware to use.
For now I'll go back to the main build like you said, as I've had a few problems with the bug fix version that I don't think I had with the 2.1.1 release.
Thanks for not just your help, but also your comment and advise : )
RE: Odd G-code behavior from Prusaslicer
Nothing empirical, on a number of occasions I've seen reports of issues created by the bugfix version. The only time I would use the bug fix version is if it fixed a bug that I was experiencing, but that just me.
RE: Odd G-code behavior from Prusaslicer
Understandable, its best to stick with what works. Ive switched to marlin 2.1.1 since the last reply and installed a genuine BLTouch instead of the cheap knockoff I had before. That seemed to solve all the problems I've been having. Thanks for the help you've given, I appreciate it.