Z height offsets for random layer - prints mid air then resumes at expected layer
I'm a week new to printing, and have been tracking down tuning issues with my MK3S+ kit. I finally got a Benchy print completed from the stock SD card, but with an unexpected twist:
What's happening is that mid-print the extruder will move up the z-axis (somewhere between 114 - 140 from what I've seen), and finish out that layer mid air. Once a new layer starts, it resumes the print at the expected layer height dragging the mid-air extrusion with it. In this case I got lucky and the mid-air extrusions both landed outside of the remaining print path, and the layers that are missing were not required for the subsequent layer to adhere. The LCD shows the z height change, so its not the motors skipping or getting noisy signals.
This happens with all my prints at random layers/frequency, stock SD GCODE or personally sliced gcode. For very small prints (<1 hr) I might not see the issue, but again it's random from what I can tell. It's very pronounced when printing the whistle from the stock SD card. For prints with multiple objects or larger complex shapes, the midair extrusion often falls in the print path causing various failures up to spaghetti mess.
I can save some prints if I catch this happening by removing the mid-air extrusion just before it returns to the expected layer height thanks to the z-axis being a slower travel. But depending on what layer is missing, this may or may not actually save the print, and it is certainly noticeable on perimeters of a final print.
Any ideas where I should start my troubleshooting on this one?
Printer: i3 MK3S+ kit
FW: 3.9.3.3556 (had to roll this back from 3.10 from previous tuning issues with IR sensor. planning to upgrade back to 3.10 but want to see if I can resolve this issue first)
Best Answer by paradoxForged:
It turns out I have access to a second printer of the same model, and more importantly same EINSY RAMBo controller. To figure out if the issue was with the peripheral sensors/cabling I planned to swap the controllers of the printers. Before that the other printer owner and I verified that their printer could print the Benchy without issues. Their printer appeared to be reasonably well tuned as well. For reference I'll call this printer B.
We swapped the boards and calibrated the printer. We then ran some test prints on printer B. This included Benchy and a couple of other previously successful prints the owner had done. Within minutes we observed the same odd behavior when mid layer the z-axis would change (and change would be reflected on the LCD screen) and it would continue to print out that layer mid-air until the next z command.
We ran the Benchy print a few times to validate the behavior was consistent on printer B, and got time-lapse video with the behavior:
Back on my printer (printer A), I installed the controller from printer B. I ran some calibration and set off to printing a Benchy. 0 issues completing the print, and not too bad of quality for not getting to tune the printer. I repeat the test again and got the printer more dialed in. I then tried a few other prints that had been failing previously and most were successful (the failures were due to new filament that I hadn't really tested yet). Further more, I was given permission to upgrade the board to fw Rev 3.10, and at that firmware I had no issues with the filament sensor which I previously had with my original controller.
It's very unlikely to have an issue / fault on the controller out of the box, but I think we have demonstrated that is the case here. Prusa support is working with me on the issue, but I wanted to update this thread. I have been given permission to borrow the controller from printer B for a couple of weeks to tune my printer setup and get some experience printing. My prints are remarkably better now, and I can print longer than 2 hours without having to babysit it.
images
Can you take some more pictures from other angles?
--------------------
Chuck H
3D Printer Review Blog
1st Print Hubris & video of z offset at random layer for stock whistle print
After addressing some some assembly issues all week, I was overly proud of getting to this Benchy result a few days ago and trimmed it for my daughter... 🙂
The issue is reproducible with a little bit of patience however, so I setup to capture the behavior in video on the stock SD whistle file (no usb connections / octoprint in case that’s not obvious in the video). I am using the Silver PLA that came with the printer. Its a fast print, and easy to spot the failed in the final print. I have the entire print recorded, but I'm only uploading the relevant bit. If there's any value to seeing another portion of the print video let me know. In this particular print I only had a single failure about 10 min into the print.
I use this one because it is likely that I'll end up with a complete print since the print time is short enough I only usually see 1-2 instances of this behavior, and I wanted to show the missing layer up close this time. whistle_layer_offset
EXTRUSION
Do you think you have some under extrusion? Does it click when this happens?
--------------------
Chuck H
3D Printer Review Blog
No clicking, don’t think there’s under extrusion
No clicking. Hard to say if there’s any under extrusion going on at the time of the issue; but in general it doesn’t seem like it in the final print (excluding the bit that was printed mid air). You can see in the video that the controller is setting the new Z value; I am not yet familiar with any logic aside from a collision that would change Z value from the gcode. But that’s really just a lack of knowledge on my part. No collisions/failure were reported in the stats either.
In my other prints as well as the whistle here, I can usually account for any missing layer / apparent under extrusion with a piece of extrusion resting to the side of the print and connected to the beginning of the missing portion.(indicating the mid-air issue for that section).
I can try another cold pull tonight and check the nozzle, but I’m curious what would trigger the controller to change the z value in the first place, or if I should be chasing down some failure in loading the file (though I would expect various other phantom issues if that were the case…)
Same mid-air print issue with new Benchy print for more data
While that whistle print/video showcases a single occurrence of the issue, the comment about under extruding got me thinking that I'm really only a week into this and probably not the best judge yet on print issues.
But I think sharing a Benchy print was more useful, so I recorded another Benchy print last night and here are two of the failed layers during that print:
Not a lot of new info, but probably more consistent with the original post and will highlight any other print issues if anyone thinks they are relevant. Again this is from the stock SD card that came with the printer. I have more failed layers recorded, but unfortunately I am missing footage of anything past layers at z = 26.00 which includes the roof and arch failures. I plan to reach out to support to see if we can rule out board issues. Just wanted add some extra data points here in case someone has seen this before or has any ideas/tests to suggest:
That looks like a mechanical shift
I'm understanding these are Benchys printed with the Prusa-supplied gcode samples, correct?
If so, that really looks like something is shifting or causing a slip or crash. Crash detection should be triggered if the nozzle hit something, so a slip is likely. I'd try generating a 10x10x100mm cube or any other shape that will print quickly and observing it as it prints to see if something mechanical is slipping. Common culprits are belt tension and grub screws, particularly if this is a kit built. At some point, I'd try such a print, take some pics, then log into the online store and contact support via chat. You paid for the support, so don't be shy about using it.
and miscellaneous other tech projects
He is intelligent, but not experienced. His pattern indicates two dimensional thinking. -- Spock in Star Trek: The Wrath of Khan
SPINDA connector reseated
Confirming for the thread that the Benchy and Whistle prints were from the Prusa-supplied gcode samples. I contacted support and we ultimately tried reseating the SPINDA connector at the Einsy RAMBo board. I tried a test print of the whistle since it was quick; no failures. My first print over 20 min without such issues. I was about to post victory here then, but decided I needed a longer print test, so I printed another Benchy.
The issue reoccured but the frequency of this issue seems slightly rarer at least at the lower layers. Seems like my whistle print was just lucky due to being such a short print, or maybe there is something there with the SPINDA connection and it gets worse over time due to vibrations. I will have to take a closer look at the cabling and pins on the board. I will reach back out to support to investigate further.
Incidentally, prior to this I was dealing with some mechanical shift due to the y-carriage bearings binding caused by misalignment of the bearing brackets. This caused a lot of collisions in the y-axis near one side of the axis. I flushed/lubricated the bearings while I was at it and that resolved a lot of early issues. Since then I've had no collisions in the failed statistics. That collision behavior appears to be a little different from what I have been encountering in the videos above; the extruder returns home (x/y) when a collision is detected and then attempts to repeat a block of instructions from what I can tell. In the issue I am currently experiencing, you can see on the LCD that the controller is setting the new z value for that mid-air layer, and able to successfully return to the expected layer without collisions.
Swapped controller with a verified printer - issue follow board
It turns out I have access to a second printer of the same model, and more importantly same EINSY RAMBo controller. To figure out if the issue was with the peripheral sensors/cabling I planned to swap the controllers of the printers. Before that the other printer owner and I verified that their printer could print the Benchy without issues. Their printer appeared to be reasonably well tuned as well. For reference I'll call this printer B.
We swapped the boards and calibrated the printer. We then ran some test prints on printer B. This included Benchy and a couple of other previously successful prints the owner had done. Within minutes we observed the same odd behavior when mid layer the z-axis would change (and change would be reflected on the LCD screen) and it would continue to print out that layer mid-air until the next z command.
We ran the Benchy print a few times to validate the behavior was consistent on printer B, and got time-lapse video with the behavior:
Back on my printer (printer A), I installed the controller from printer B. I ran some calibration and set off to printing a Benchy. 0 issues completing the print, and not too bad of quality for not getting to tune the printer. I repeat the test again and got the printer more dialed in. I then tried a few other prints that had been failing previously and most were successful (the failures were due to new filament that I hadn't really tested yet). Further more, I was given permission to upgrade the board to fw Rev 3.10, and at that firmware I had no issues with the filament sensor which I previously had with my original controller.
It's very unlikely to have an issue / fault on the controller out of the box, but I think we have demonstrated that is the case here. Prusa support is working with me on the issue, but I wanted to update this thread. I have been given permission to borrow the controller from printer B for a couple of weeks to tune my printer setup and get some experience printing. My prints are remarkably better now, and I can print longer than 2 hours without having to babysit it.