Nope still not running OK.
And its not the Timeshift app on the laptop, its not the laptop at all.
I tried running from USB stick with gcode this time, and the printer still stalled.
Doordetection?? Havenot thought of that. But you may have a point there.
Because I couldnot find anything I took my printer apart and cleaned and lubed every axis which was also needed after printing 9-10 hours a day for half a year.
Put the printer back together again and placed it in the case and now it seems to run OK.
I read your reply about the door detection and checked. I forgot to plug the detection in.
So it runs OK without the detection and before this all started I probabley did something with the door detection and forgot all about it. My stupidity again!!!
But if the doordetection is the case then why will the printer run for a while and stop at any given moment.
And why doesnot either snapmakerjs or the controler display give an error or a message??
I am letting the printer run for a while on the USB stick and doordetection disconnected since I have got a project to finish, I think next week I will try SMJS again and connecting the doordetection.
I will let you know how this turns out.
Thanks for the tip and your help.
Hey Radt,
According to your first picture, when the machine stops, the gcode file disappears on the touchscreen. That is, the machine had a powered off.
Thank you for the gcode file and I just tried. I can print it over. So the issue is not related to the gcode file.
How many percent does it show on the touchscreen when it shops each time?
Hi Tracey…
Tx fr the try out… I think I figured out the fault … It’s in the pendrive… I suspect that SM1 dosent support usb 3 formatted pendrives or ntfs formatted pendrives…
I faced the same error on some other print also… nd formatted the pendrive vth a usb 2.0 and vth FAT32 … and succeeded in printing the jobs without ny failure/stops…
Plz clarify about the issues
DOES SM1 SUPPORT NTFS PENDRIVES .
DOES SM1 SUPPORT USB3 FORMATTED PENDRIVE…
TIA
I also had a large print just stop, maybe 20% complete, with the print head in position, but with everything hot, but cooling down. Was printing a gcode file from the USB drive that came with the Snapmaker.
As I recall, the touch screen wasn’t responding properly, either. I power cycled it.
I know it was NOT the gcode file, because I had previously printed it successfully. It was gcode to print several bias tape tools out of PLA for local mask makers.
Snapmaker is running firmware version 2.11
Hi Saratbob,
That is great that you have figured the issue out.
Are you using the original USB flash drive?
It only supports FAT32 USB2.0.
Hi Tracey…
I am using a new usb drive… the original usb got crashed and is not functioning properly.
Hi OldCoder, can you please share a picture of your screenshot when the printing stops? Thank you
Maybe I should have started a new topic for this?
Chris
Hi Chris, here is Edwin from Snapmaker Team.
Could you tell me where and when did you buy this machine? Can you send me the serial number of the machine?
Edwin
Edwin:
I do not see a serial number. Where should I look? I got the machine as Kickstarter backer 4978.
Chris ShakerAlright, thank you for your reply. We are working on this issue. How about the frequency of using the machine
Edwin:
I’ve made maybe 20 prints total with the machine. This crash hasn’t happened since yet, but I am now power cycling the machine before starting each print.
I am successful printing PLA with the machine, but have not yet learned to get PETG to stick to the bed.
Chris
Chris,
I am sorry that the Snapmaker Original does not applicable to PETG due to the temp limited temperature, But you can try some glue or tape.
Metal wiring is oxidized or there is dust on it resulting in poor connection. You can clean the cables with alcohol cleaner.
Best regards
I’m now having the same issue, where the printer stops in the middle of the print for no reason. Like the pictures above, it’s the same situation too. tl;dr solution: On the last instance of this, all I had to do was pause the print from inside Luban workspace, and then resume.
Right now, I’m using 2.11 firmware and Luban 3.7.0.331 on macOS 10.15.6. I’m exporting directly out of Luban to the machine over USB. I haven’t tried using the flash drive, though for the first few days I was only using code from the USB drive. When I hooked it to the iMac, I stopped doing that and instead used Workspace instead.
At first, I thought it was the models themselves. On this latest print, it stopped at 1:04:55. What’s interesting is that it displays a one byte difference in sent/received:
Sent 21799 / 195239
Received 21798/195239
Not sure if that has happened before in the case of missing bytes.
I “continued” the print by hitting pause, then resuming.
I tried going through the console to see if that would be informative and the only odd thing I saw was a feed code (F3000 3748.39). Maybe there could be a way to save the console log to an external file? CMD-C to copy doesn’t work there.
Then shortly thereafter the resume, I see an F1000 instead.
Not sure if this helps.
Is it possible that there are a power options active, like standby or anything else?
I would suggest you to try it with a thumb drive and check again.
This could be a bit challenging, to get one drive working, but I think printing with this is the most secured way to print.
I have been looking into that. Waiting to see if it happens again with another print.
And it did, so I disabled as much as possible under Energy Saver in System Preferences. Continuing with other prints to see if the behaviour continues.