PETG filament crash detection causing print to stop
Been printing with PETG filament on my Mk3, but keep getting issues where my print stops due to crash detection. The nozzle seems to be extruding blobs onto the print itself which results in a crash detection. I've attached both my print settings and the part that failed. Looking for any advice as to how I can fix this.
Re: PETG filament crash detection causing print to stop
Turning of the Filament Sensor when printing with black PETG solved the issue for me.
Re: PETG filament crash detection causing print to stop
Turning of the Filament Sensor when printing with black PETG solved the issue for me.
I"m interested in understanding why suppressing filament sensing would alleviate the blobs. From what I've read so far in the threads, this is more of a hot end/extrusion issue.
Are you seeing the blobbing after the crash happens and it just oozes out in place, or does it all shoot out during infill and cause the detection to fire?
Re: PETG filament crash detection causing print to stop
It's been my experience if you are getting periodic blobs while printing PETG, your Z offset is too close to the bed and it's causing it to slowly build on the nozzle. Here's my method for getting perfection on this:
Following the above pretty religiously now, and haven't had a PETG blackened blob fall off in a long time. 90% of my prints on the MK3 have been PETG.
My MK3 Parts: [Bowden] [New Shoes] [TPU Micro Springs]
Re: PETG filament crash detection causing print to stop
I"m interested in understanding why suppressing filament sensing would alleviate the blobs. From what I've read so far in the threads, this is more of a hot end/extrusion issue.
Are you seeing the blobbing after the crash happens and it just oozes out in place, or does it all shoot out during infill and cause the detection to fire?
The filament sensing is done optically with a sensor similar to that found in a computer mouse. In order to see movement, the sensor needs some surface texture or variation. Glossy, uniform coloured, surfaces tend to have very little variation. [ever tried using your optical mouse on a glossy white [or other solid colour] table top?] While this sensor appears to do pretty good with glossy/solid surfaces, it appears some filaments just don't register enough detail/variation for it to track movement accurately.
My guess is that the blobs are a result of the sensor, incorrectly, seeing little or no movement in the filament. As a result the printer tries to push more filament through to compensate. The result is excess filament actually being fed into the hot-end.
The errors we see are actually two fold. As Kevin mentioned we see the head crashes as a result of the head hitting the blobs, but we also see filament run-out errors, which I am assuming is a result of an extended period where the sensor does not sense filament moving.
One possible solution to this problem, in a future revision of the extruder would be to place the filament sensor after the drive gears, as the texture the gears create on the filament would provide plenty of surface detail for the sensor to track. This would require a second sensing element above the gear to detect filament insertion/removal [if that is a desired function]
Re: PETG filament crash detection causing print to stop
My guess is that the blobs are a result of the sensor, incorrectly, seeing little or no movement in the filament. As a result the printer tries to push more filament through to compensate. The result is excess filament actually being fed into the hot-end.
Negative- the filament sensor has nothing to do with the extrusion rate... it is only there to sense existence (or travel) of the filament. It doesn't have any kind of feedback loop into the extrusion engine.
One possible solution to this problem, in a future revision of the extruder would be to place the filament sensor after the drive gears, as the texture the gears create on the filament would provide plenty of surface detail for the sensor to track. This would require a second sensing element above the gear to detect filament insertion/removal [if that is a desired function]
Won't work- there is no real path for the laser to hit... there is PTFE after the drive gears and you can't really have an open spot for the laser here (Think TPU, it wants to escape anywhere it can).
Re: PETG filament crash detection causing print to stop
My guess is that the blobs are a result of the sensor, incorrectly, seeing little or no movement in the filament. As a result the printer tries to push more filament through to compensate. The result is excess filament actually being fed into the hot-end.
Negative- the filament sensor has nothing to do with the extrusion rate... it is only there to sense existence (or travel) of the filament. It doesn't have any kind of feedback loop into the extrusion engine.
As I said that was just a guess, I have not delved into the code to see if it was open or closed loop. However turning it off seems to improve the situation, so it would appear there is some form of feedback mechanism at work, even if indirectly.
One possible solution to this problem, in a future revision of the extruder would be to place the filament sensor after the drive gears, as the texture the gears create on the filament would provide plenty of surface detail for the sensor to track. This would require a second sensing element above the gear to detect filament insertion/removal [if that is a desired function]
Won't work- there is no real path for the laser to hit... there is PTFE after the drive gears and you can't really have an open spot for the laser here (Think TPU, it wants to escape anywhere it can).
It would require increasing the space between the drive and the PTFE tube, or drilling a small hole in the side of the PTFE tube to give the sensor a window. Neither of which are impossible options. My bigger concern would be heat, as it places the optical sensor much closer to the hot-end.
Re: PETG filament crash detection causing print to stop
So I've looked into the code a bit... looks like this segment in fsensor_update() of fsensor.cpp is the potential culprit.
if (fsensor_err_cnt > FSENSOR_ERR_MAX)
{
fsensor_stop_and_save_print();
fsensor_err_cnt = 0;
enquecommand_front_P((PSTR("G1 E-3 F200")));
process_commands();
cmdqueue_pop_front();
st_synchronize();
enquecommand_front_P((PSTR("G1 E3 F200")));
process_commands();
cmdqueue_pop_front();
st_synchronize();
if (fsensor_err_cnt == 0)
{
fsensor_restore_print_and_continue();
}
with fsensor_err_cnt being updated by this code in the ISR:
if( (pat9125_y == 0) || ((pat9125_y > 0) && (st_cnt < 0)) || ((pat9125_y < 0) && (st_cnt > 0)))
{ //invalid movement
if (st_cnt > 0) //only positive movements
fsensor_err_cnt++;
Basically looks like what is happening is that the sensor is failing to sense motion. As a result the code is performing a short retract, and then feed to recover. The retracted filament has texture from the gears. Now when it feeds forward again, it sees the movement because it has good texture to track. This results in no new errors being generated, so it resumes printing thinking everything is good.
This pause/retract/feed motion is what is likely leaving the nodules in the print, resulting in crashes later.