Machine (A350) restarting mid-print

Snapmaker 2.0
1

Hey all. I’ve been seeing prints stop and the machine reset/at the start screen. If I turn the machine off, then back on, i have the option to resume (and it does so). Sometimes that’s enough, but once one a quite long print (over a day) it stopped 4 times. the print did complete, but during that time everything was still hot, just not moving. On those really bad ones where i didn’t get to it quickly, there would be a glob of filament on the print. I could snip most if it off while the machine was homing and it would “smooth” it over more/less with the heat of the nozzle. But still should be able to set and forget.

The latest firmware i did see a note (i think) about fixing random stops. That (i think) has helped, but today I did see it stop. I luckily was next to the printer and able to reset it quickly (before filament gets baked in), but again should be able to start a print and let it run for days without having to worry about it stopping in the middle of the night.

My GUESS is: like when loading a really large/long print, something is “disconnecting”. The only real errors in the logs look like this:

1680457524079,2023.04.02 17:45:24.079,ERROR,SC-FW,wait gcode pack timeout and req:1620656

hundreds of lines. the latest batch of logs shows several groups of these, requesting different lines, so essentially shows each time it stopped.

I have only ever used any of my snapmakers (original and A350) for 3D printing. But in order to get what i paid for and likely buy a new MK4, I would like to start using it for things other than 3D printing. That though means moving it to a new room cuz can’t have dust and junk in my office. But having it out in another room, I don’t want to have to worry about it much, so would like to get to the bottom of the hanging reset. Cuz if it happens on the other things (machine reset with tools still going), something like the laser would be extremely bad. The 3D and CNC less so, but still.

attached are today’s log export. I updated the firmware yesterday. (can’t check the version since i have a print going, but might be in the logs).

logs-04-11-23.zip (625.9 KB)

2

Are you printing from Luban, or from the controller using a USB drive? If from Luban, how good is the WiFi signal in your office?

Which ever way you’re printing, try the other way and see if that’s better.

Looking at the controller source code, I see that error in snapmaker/src/hmi/event_handler.cpp . I’m not really familiar with the firmware, but my quick skim of the code makes me think that the buffer of GCode commands is empty, so it doesn’t know what it’s supposed to do next. That makes me think that either the WiFi connection dropped, Luban stopped sending GCode, or the USB drive stopped responding.

3

thanks C that’s a great question.

The GCode i’m generating from Prusaslicer (not luban, I don’t like how Luban does circles). the process I use is:

  • generate gcode with slicer
  • export it to local file system (I have a “print-stage” folder on my desktop, typically where it goes)
  • load GCode into Luban workspace (this and the next step could be flipped, doesn’t matter)
  • Connect to machine via wifi
  • Send to Device
  • Disconnect wifi between Luban and machine
  • Load gcode to machine job
    – Files >

it loads up and goes.

I was going to post more logs after this current print is done. This same exact gcode now has stopped 3 times so far. That first print of this it stopped once, and not in the same place. So I don’t think there is anything wrong in the gcode, but must be a connection thing. Everything is “local” to the machine to avoid exactly that connection thing.

To answer the question, I have excellent wifi everywhere with a fast mesh network. I’m not running the code external to the machine so i doubt it’s anything like that. I could of course try and turn wifi off on the next print JUST to be sure it’s nothing weird like that, but again when loading a huge gcode file you get the disconnect warning (which is from like Day 1 of snapmaker original, so no idea if that’s a thing to be fixed but could be a lead to connection things).

can you put a link to the code (since you had it handy recently at least). I am write software for a living, so i can take a look at that and see if i see anything too.

4

which is called from

I only spent a couple minutes skimming the code. It’s been years since I’ve written firmware or C++ code, so my opinion about what’s happening in the caller is, at best, an educated guess. More likely, I’m completely wrong about what’s going on there.

There are forum threads about how to build, package, and flash a custom firmware, if you’re interested.

The fact that the machine stops at different places is interesting. You said you were present for one. Did the controller happen to reboot? I’ve gotten the impression that the controller is fairly sensitive to power supply issues (some users had your issue, and fixed it by using a UPS, but it took them a while to figure that out). Since most of these pauses happen when nobody is present, it took them a while to notice that the controller was actually rebooting every time it paused.

5

awesome! yea i may end up wanting to do some customer firmware to see what’s going on.

ha funny you should mention the power. I have always used a UPS, not just for power cleanliness but in case of power outage, it shouldn’t just stop but there would be time for me to go in and properly pause it instead.

But yes whenever it’s stopped, the screen is at it’s “home” screen. For example this morning I came in it was sitting there, but the temp on the nozzle showed 205 and the bed showed 60. So it’s like whatever is sending the tool commands just stopped and reset to the main screen. Once I hit the power switch, wait about 10s, then turn the power back on, I get the Resume option and continue the print.

6

I don’t have a V2, but I understand that transferring the GCode over wifi is supposed to store the GCode on the controller’s storage. I’d suggest trying a USB drive just to see if it changes anything.

What’s the environment like? Are you using an enclosure? I’m wondering if something is overheating, or possibly jiggling the enclosure door enough that it triggers the open door stop. If you have an enclosure, I believe you can just disconnect the cable to disable the sensor as a test.

7

yea the GCode is on some storage other than USB. I have used USB when I slice a bunch of things at once (for example planning on printing a bunch of tokens of different types, and split those into multiple gcode files since printing multiple copies in different colors). The same thing has happened in the past there too, though i can try it again.

As for the env, not using the enclosure. I have it, but it’s disassembled and put in storage, which kinda sux. the enclosure gets in the way too much in accessing everything. I rarely print in anything other than PLA, so the enclosure was excessive.

The room does stay pretty toasty. Right now i see the thermostat on my desk shows 78.1F. Typically it hovers around 70-71, it’s warm today though and have not wanted to turn on the AC yet. I have a food dehydrator for drying filaments with a printed enclosure for that (rather than destroying my trays). when that is running (it’s not atm) the room gets quite toasty. I did have that thought that it might be overheating, potentially due to the thermistor not being greatly attached. For my last heating element, I replaced the heat break with an all metal version (since several of the tube versions jammed), and put thermal paste with the heat break, heating cylinder, and thermistor in the hopes that all of the heating touchpoints have high transfer connections.

While that as OK, that setup kept having filament be… strange. Curling, “sticky”, etc. i was also using a copper hardened brass nozzle from TH3D, which generally works great. For these latest prints I swapped entirely the hot end (i got like 5 new ones), and so far that’s been working.

So unfortunately i’ve done a TON of stuff to get things printing well (way more than should be necessary for such an expensive machine). The main issue still is: even attempting to do the USB gcode load, if that works there’s no guarantee that “fixes” the issue without understanding the root cause. I did have thoughts of the storage and have deleted many of the past gcode elements thinking that might “free up” storage, since it has to write lots in order to facilitate the pause/resume feature. I don’t really have any evidence of that having any effect, since again this is the same gcode printed again with different results. What’s nice is I have to print this one at least 1 more time, so that gives a nice test platform for things.

8

picture of the print “damage” because of the pauses. Otherwise would be perfect…

IMG_2559
IMG_25591920×2560 74.8 KB

Later tonight I will see about getting new (debug/mine) firmware into the thing. I checked the firmware update and while I had thought it updated, it apparently failed. The current version does say 1.15.21 (20230303), but it tries to download that same version, failing to update saying something about not being able to validate something. It’s running through the modules now so we’ll see.

9

Hello! I have been experiencing the same exact issues, but with the Snapmaker Artisan. Have you found a fix, or at least the source of the problem? I am using an UPS, but it doesn’t seem to make any difference, the console restarts randomly during prints. I need to unplug and plug it back in for the recovery option. But that doesn’t help much, since the prints are imperfect when it restarts…

I have a log file (it happens at about 15:29 in the log file). But i cannot upload a file as a new user.

Thank you very much!