So, this is affecting two of our printers – a Leapfrog Creatr XL and a Prusa i3 MK3. We’re debugging right now to check if it is a hardware problem on the Prusa, but we think the issue may be localized in Astroprint.
The basic problem is that we think we’re seeing “geologic moments” in our prints (periodically, but with some distressing regularity – within the first 5-10 layers, and then again within every 10-20 layers) – where either a layer is skipped in the print, or the Z-axis is moved a step too far.
We spent a while dinking with this on the Leapfrog this fall, and ran through a variety of hypotheses: were the prints failing because of overnight fluctuations in air temperature? Failing USB connection? Faulty GCODE? What we found, in the end, however, was that Astroprint was (in addition to never successfully controlling the second print head), also the single variable that we could influence that affected print outcomes. If we connected directly to the printer from a PC running Simplify3D, rather than through a RaspPi running Astrobox, prints went well (or, better, at least – different failure, rather than this skipped layer jazz.)
We are currently futzing with adding a new Prusa i3 MK3 to our printer pool, and had run some fine test prints on it off of the SD card. Having connected to it via Astroprint, we’re now seeing the above-described “geologic events”. The Prusa recovers from the apparently skipped layer (or excess Z-axis move) within, usually 4-5 layers – which is supercool – but there’s still a stratum of non-adhered, misaligned filament in the middle of the print.
We’ve seen these strata both slicing in the Astroprint cloud and uploading working GCODE via the Astroprint cloud (working = GCODE that successfully prints on another Prusa i3 MK3).
We’re in the midst of running that same GCODE “that works” off the SD card on the problematic Prusa, to try to either eliminate or indicate the Astroprint controller.
Questions:
- When we upload GCODE through the Astroprint cloud, is it being wrapped in the print driver’s start and end commands, as defined in the printer profile on Astroprint? (Could it be the printer profile that is affecting this, even if we’re uploading “working” GCODE?)
- Is Astroprint downloading the whole GCODE file to the RaspPi in one shot, or streaming it… and if it is being streamed, could that impact the skipped layer situation? (Is this about a hiccup in the network connection or the RaspPi processing of instructions?)
- My assumption is that when Astroprint slices an STL file in the cloud, that the resulting GCODE is being sent to the RaspPi, rather than involving the RaspPi in the slicing process, is this true? (Is this really about tuning the printer/material profiles and slicer settings in the cloud… or do we have RaspPi issues too?)
- We’ve started with the “out of the box” Prusa i3 MK3 and PLA profiles on Astroprint, are there better-tuned profiles that we should be using?
Thanks!