The printer will not complete prints, and just… stops. Right in the middle of a print. The screen says ‘100% complete’, the bed goes down - exactly as it would for print completion… but the print is only 40% done (or there abouts).
This, combined with the unresolved issue with late-print layer shifts makes the J1 entirely unusable, for anything other than printing guitar picks.
Snapmaker, you need to respond to your users’ issues - the Facebook page is also flooded with these problems.
I have a similar problem, but the other way round:
my printer tells me that it’s already at 100% and 0 minutes are remaining, but the printer is still printing. How is this possible? It happened to me while printing the included Two color shark, which is preinstalled on the machine.
I have a feeling your previous experience with 3D printers is limited
The time the printer tells you is as (in)correct as the average time MS Windows will tell you when you copy a large set of files somewhere - it is just a rough estimation based on the file size, the amount of filament or such, which might fit… or not.
This is the same with every 3D printer (and every Windows computer…)
I’m printing since 2016 but never had a printer which counted downwards. Usually my printers counted the time that it took to print, not the other way round. But the estimated time in Cura and the final time where almost the same, maybe with 10-20 minutes difference.
But if my brandnew snapmaker j1 is not able to show the time of the preinstalled file in a correct way and needs twice the time than estimated, then they could also hide this information
And just to mention: 100% is 100% so it’s finished. And if the screen shows 100% but the print is at the half, than it’s 50%
Then you were lucky My Duet-based printer estimates about as correct as the J1, the only difference is that it a) rounds off differently and stays on 99% longer in such cases (and the last minute or so may take a bit longer than it should), b) updates the calculation a bit more often - and c) it shows you three differently calculated times to choose from - file length, slicer and… layers I think. It is interesting to see how much these differ, converge, diverge again… and with some experience you can guess which one might be closest to “correct”.
Had exact same issue recently, firmware is latest version.
Exported the log files but could not see there why it stopped.
Then opened the gcode file with a browser and found the reason. Apparently Luban tool loaded some garbage to the file corrupting it. The file defect is at about the portion where the printing stopped.
The Data at this section looks like this:
"G0 X131.924 Y33.411
G0 X131.983 Ñ«<MT.ÎúPÁbQÿÁSâŠÚR|`8ÝBÓ-+± "
and so on…
The obligatory “gcode end” was missing too.
Unfortunately the firmware does not check validity of the data before starting - potential future improvement?
