[WIP] New print history plugin

Hi,

I'm currently brainstorming about a new print history plugin. Yes, I'm aware that there already exists one but that project seems abandoned and I wasn't able to contact the author. That's why I decided to create another one.

The following properties of a print ought to be provided:

  • filename
  • the user who started the print
  • print date
  • print time
  • used filament (FilamentManager Plugin)
  • print cost (CostEstimation Plugin)
  • wheather the print was successful or not
  • added notes

Because of the amount of the properties it is not easy to provide them inside a small table. Therefore I'm considering to show only the most interesting from the outset. The rest is shown when clicking on a row. Here is an image of how it could look like:

Bildschirmfoto_2018-05-05_19-55-49

Some features I'm also considering:

  • export of database
  • some statistics (maybe print time about weeks/month?!)
  • common database for multiple instances
  • make and save a photo of the object after a print
  • load file with click on the filename (@Ray_Price)
  • track prints only if actual filament was extruded (@Peel)

I opened this thread because I'm curious about what you think and which improvements/ideas you might have.

Edit: A more complete mockup → https://i.imgur.com/SnsmsuT.png

5 Likes

Those features sound good. Couple of other thoughts:

  1. Would be nice to be able to click on a .gcode file and have that file loaded to the printer in order to print another one, instead of having to go back to the file list and find it.

  2. Going way out there - it would be great if you could automatically or selectively tag prints (based on date / time, file name, ...). My thought is that I'd like to be able to identify how much print time is spent on "business" prints vs "personal" prints. Exporting the print history would be great for post processing, but tagging (and summarizing print time based on tag) would do it all there.

  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
parameters.update(self.parse_bottom(gcode_file))
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory/parser.py", line 90, in parse_bottom
config.readfp(io.BytesIO(settings))
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
self._updateDisplay(UPDATE_DISPLAY_REASON_FEEDRATE_CHANGED)
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?

TIA

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

3 Likes

ezgif-2-333b9b76ea8c

2 Likes