Potentially dangerous behaviour of Taz 6

Summary: If a gcode file is truncated, Taz will stop wherever it was, and keep the heaters on.

Full Story:
I created a gcode file using slic3r and used slic3r to save the file directly to an SD card.
I properly ejected the SD card using the software before removing it from the card reader. (note this is on Linux Mint 18.2).
I put the card into the Taz and printed from SD.
The print started fine, and was still running fine 4 hours after I started it, and I went to bed. I woke up at 3:00 AM and checked the print. I found the printhead stopped on the object with a small puddle of molten plastic under the tip. The % complete indicator was missing, but the print time was still incrementing. I was able to go into the menu, move the head off the print, extrude a bit more plastic to make sure the nozzle was not carbonized shut, then turn of the heaters.
I found later that the gcode file was about 600 k shorter than it should have been, and the end gcode was missing.

possible solutions:

  1. The Taz could scan the gcode before starting to verify that it ends with the print head temperature set to zero, and if not generate a warning message requiring the user to acknowledge the situation before continuing.
  2. If the Taz reaches the end of the file with the heaters still on, it could turn them off.

I like my hardware to fail safe. This was not a safe fail.

This brings up another interesting thought. Perhaps adding a MD5 checking algorithm to the firmware would be a good improvement. Not only would it be able to detect an incomplete file, but also a corrupted file before the print even starts. The MD5 hash could be generated and inserted by the slicer tool as a comment and the printer FW could calculate and compare to what the slicer inserted to pass/fail the file.

Hmmmm… :slight_smile:

All good ideas, the one thing you need to remember is the processor in a Rambo board is very limited compared to a computer. There isn’t necessarily any processor overhead available to add cpu intensive pieces to without going with a newer style board.

I have seen Arduino based MD5 libraries out there. Granted, I never actually looked into any of them, but I gotta think that they can operate on files on SD cards. Fortunately, gcode files are pretty small so the processing wouldn’t be too bad. I think the main concern would be if the additional memory resource requirements of a MD5 generator library would cause the build to exceed the available memory resources of the device.

Sounds like a good idea for an octoprint plugin