[WIP] New print history plugin

  1. Noted :wink:

  2. I think this could be realized by using two different accounts, one personal and one for business.

Really cool, would be great to have something like this!
Any chance you would also save a snapshot of the final print if a webcam is configured and available in Octoprint?
Shouldn't be difficult, and would be really cool to see the final prints in the history.

Maybe also link in the detailed info to timelapse videos of this print, if there are any?
Don't know how this is possible, but should be.

Great ideas, and the mock-up looks good. One thing that bothers me about the current history plug-in, and I’m sure you’re already considering this, is that the existing plug-in will record the full estimated filament used on a failed print, even if only a percentage of the print actually took place.
Also if I cancel a print via OctoPrint before it’s actually started printing anything (during heating or bed leveling, say) I don’t think this should be recorded as a failed print, but the current plug-in treats it as such.

Just what I was looking for ! Sounds perfect :slight_smile:

@Wolfsblvt Taking a snapshot after the print is already on the list. But still thinking about how to implement this with multiple printer. Saving images to the database is usually a no go. Other options are a shared folder in the network or showing the picture only within the OctoPrint instance which made the snapshot :thinking:

@Peel The filament manager plugin tracks the extruded material by analyzing the gcode send to the printer. Therefore it should be fairly accurate. Your second point is arguable I think, but I might add a setting for it. Something like "Don't include prints canceled during heating/calibration phase" maybe.

What's wrong with saving images to the database? I know it's mostly not recommended, but there are even databases and formats that are able to save large files in a database. It wouldn't be that bad.
But I agree, a shared folder would be better, if possible. What are some arguments against it, that you still think about it?

So I've been thinking of working on something along the same lines.

Key features for me would be:

  • Spool tracking
    ** filament data (mfg, color, material, date opened)
    ** tracking remaining amount filament on the spool
    ** tracking of spool data like filament costs, usage rates
    ** tracking of spool usage by both mass and distance extruded
  • tracking and including fixed print costs
    ** printer operator labor (flat money / print started)
    ** printer capital costs amortization and rent (as represented by money / hr run)
    ** tool wear (flat money / print started for build tak, scrappers, etc)
  • Tagging of prints in history database
    ** Client/end user (who is getting/paying for the part)
    ** user defined job tag (tag to group all the various files from one job)
    ** user defined project tag (tag to group all the various jobs from one client's project)
    ** user defined orderflow tag (where the order/job came from such as etsy, 3dhubs, printerserviceRus, etc.)

I run a printing hub and having multiple tags for prints is critical as I am doing lots of iterative printing for clients. I currently track all of this in an excel spreadsheet and would like to automate all the logging.

@NB4cSUYn, My reason for asking for not counting cancelled prints that haven't actually started yet is that I will sometimes realize immediately after clicking print that I have the wrong filament selected in the filament manager, or didn't have timelapse turned on, some other setting that I want to adjust prior to starting. I don't consider stopping something before it's begun the actual printing process to be a print failure, unlike, say, seeing halfway through that there was an axis shift or I was getting a spaghetti monster.

@Wolfsblvt There are some reasons not to use BLOBS in (relational) databases. But to make it short, it's slow and scales very poorly. The question might be: Does it matter in this case?

There are also some arguments against a shared folder:

  1. The user has to set this up and some already struggle with a PostgreSql database
  2. It might be more complex to migrate from the local database to an external with a shared folder

@stidf I'm not targeting commercial services with that plugin , but most of your requested features will be available. For spool tracking and print costs I'm using the plugins mentioned in my first post (FilamentManager and CostEstimation). If you're missing some functionality you should open a feature request on their github repository.

I think tagging can be done with a naming convention of the gcode file, e.g. "client_project_job.gcode" or similar. For the rest there will be the notes field.

@Peel I get your point and added this to the list in the first post.

How can we put on Octoprint ?

Hi @NB4cSUYn did you already started with the implementation or do you still in the "design-phase"?
I looked into the Plugin-Repository and couldn't find a print history plugin.

Power usage for the print if using TPLink-Smartplug or eventually the Wemo plugin once I integrate that option.

Did you start with the Plug in? or just an intention? I would gladly add my 2 cents (real money) for this

Seems the plug is now dying after a recent upgrade:

2019-08-18 01:04:30,844 - octoprint.plugin - ERROR - Error while calling plugin printhistory
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/init.py", line 219, in call_plugin
result = getattr(plugin, method)(*args, **kwargs)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory/init.py", line 146, in on_event
return eventHandler.eventHandler(self, event, payload)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory/eventHandler.py", line 46, in eventHandler
parameters = gcode_parser.parse()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory/parser.py", line 28, in parse
parameters = self.parser_factory.parse(self.file)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory/parser.py", line 41, in parse
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory/parser.py", line 90, in parse_bottom
File "/usr/lib/python2.7/ConfigParser.py", line 324, in readfp
self._read(fp, filename)
File "/usr/lib/python2.7/ConfigParser.py", line 512, in _read
raise MissingSectionHeaderError(fpname, lineno, line)
MissingSectionHeaderError: File contains no section headers.
file: <???>, line: 1
'{"extruder_quality": ["[general]\n'
2019-08-18 01:04:30,985 - octoprint.util.comm - ERROR - Error while processing hook DisplayLayerProgress for phase sending and command G1 Z+0.5 E-5 X-20 Y-20 F{travel_speed}:
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 3220, in _process_command_phase
hook_results = hook(self, phase, command, command_type, gcode, subcode=subcode, tags=tags)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_DisplayLayerProgress/init.py", line 249, in sendingGCodeHook
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_DisplayLayerProgress/init.py", line 442, in _updateDisplay
feedrate = self._calculateFeedrate(self._feedrate)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_DisplayLayerProgress/init.py", line 560, in _calculateFeedrate
newFeedrate = float(feedrateFactor) * float(feedrate)
ValueError: could not convert string to float:

Anyone able to fix this or is there an update on the replacement plugin?


Looks like bad gcode to me. The token {travel_speed} was not replaced. Search for this in your gcode file, or within your Octoprint start/end gcode.

1 Like

@Zlynt: you may consult this: When I try to print something I keep getting a "format error" from the printer on a line containing "{travel_speed}"

1 Like




Thanks for the hint! I'll check that.

Did this ever get off the ground? A common database for print history across instances would be WONDERFUL!!!