AstroBox Desync from printer?


Using version 0.14, I’m having a curious problem with printing. It seems that after completing a print… the next print has … issues.

The first print works fine. The next print, however, it appears in the UI that nothing happens when clicking the “Start Print” button for another object. However, the printer does indeed begin to heat up and print. So, the GCode is running in the background, but the UI doesn’t know about it. There’s no way to cancel the print. If I try to take over control by manually sending commands to the printer, the GCode overrides my overrides. The only way I can seem to regain control of the printer is to reset the Astrobox.

This may be not be related, but I had one print which seemed to stop mid-print. The print head just stopped in the middle of the part with the bed and nozzle heaters on. The Astrobox had returned to the main menu as if it had rebooted mid print. Fortunately, this only happened once.

I’ve tried looking at the logs /var/log/astrobox but nothing jumps out at me as to the cause of either of these issues. The lockup/freeze/reboot/whatever-it-was happened while version 0.13 was loaded. I upgraded immediately after that and haven’t had that problem again.


There could be some connectivity issues. I would recommend two things:

  1. read this article and see anything there can be causing or affecting your setup:

  2. enable serial logs in the setting / software / advanced section of the AstroBox Web UI and send us logs when this has happened with logs enabled.


Great! You made sending logs stupidly simple :+1:

It seems I can reliably replicate the problem.

  1. Reboot
  2. Print - everything ok
  3. Upload new gcode file
  4. Print - nothing seems to happen
  5. Go to utilities
  6. Change bed temperature - receive error that the current print needs to be paused for utilities to communicate with printer
  7. Overlay appears with buttons to pause or go back
  8. click go back - taken to astrobox/#printing where the print is running normally

So… it might just be a matter of the UI not automatically redirecting to the /#printing url for some reason.

I’ve enabled the serial logs. I’ll continue to diagnose. Thanks for the quick response! :space_invader:


Hi Daniel. I uploaded my serial logs - however, I realize that I believe the error was caused by myself, at least in this instance. When I uploaded the serial logs, my slicer settings caused the head to impact part of the print, so, not the same thing as the topic of this post.

I haven’t seen an instance where the printer just stopped again. The event referenced in my previous post was different in that the print head stopped and Astrobox thought the print was completed, but the heaters were still on and the print was unfinished. That wasn’t a gcode problem.

I’ll continue monitoring the serial logs a little longer but… maybe it was just an electronics gremlin and hopefully it won’t happen again.