[WIP] New print history plugin

@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

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!!!

Hi @NB4cSUYn,
how is your progress of the history-plugin?

I also started implementing a history-plugin (https://github.com/OllisGit/OctoPrint-PrintJobHistory), because:

  • I want to implement a "bigger" plugin as in the past. The last released plugins were just smaller improvements
  • Using of database-communication in python
  • Implement a plugin with a clean software architecture, like "separation of concern", documentation, project-management stuff
  • ReUse of already released plugin informations

The backend part is already finished. It collects the following informations and stores the data in a local database:

  • username
  • filename/path/size
  • start/endDateTime, duration
  • state
  • bed/nozzel temperature
  • layers, height
  • spoolname, material, diameter, density, costs
  • used filament length
  • take a snapshot-image after the print

Some of the informations were collected by these plugins: PreHeat, FilamentManager, DisplayLayerProgress.
So, the goal is to reuse as many information from 3rd party plugins as possible.

On my todo-list (https://github.com/OllisGit/OctoPrint-PrintJobHistory/projects/1) you can find plugins like: Octolaps, MultiCam, CostEstimation, PrintTimGenius
In the planning board you can see the progress and what feature is implemented next (e.g. finish settings-dialog)

Now comes the tricky part: UI development...bloody damn hard.
Currently I used the table of Print History-Plugin.

image

Hopefully I can release a first development version next week.

By
Olli

2 Likes

Hi. I was actually just looking around for something like this. I was wondering if you had a chance to release this.

Hi @simpat1zq!

Well, some basic features are still not implemented (e.g. Filter/Sorting of History-Table).
You can see the current state of release #1 implementation in the updated README.

Beside the missing features I want to change the whole database access implementation.
Currently I am working in parallel on a SpoolManager-Plugin (see Filament database) and this plugin use "peewee" as a databaseframework. It looks really promissing and offers a lot of features (e.g. reducing lines of code, support for different database-vendors).

So, I think it will take more then one or two weekends for a "well proofed" release.

Please be patient..or just install the current implementation and play round...if you find errors/improvements or just leave some information what kind of feature is really important for you, feel free to raise an issue in github.

C, ya Olli

Just curious why the preference of peewee over sqllite3?

Hi @jneilliii,

peewee is a Object Relational Mapping toolkit and (IMHO) sqlite3 is just a barebone database access-layer. With peewee you don't need to work with sql-statements, you work with python objects.
If you switch e.g. from mysql to Postgresql you don"t need to handle the different columntypes/expressions, this is done by peewee.
I think if you use just a few tables (<5) you can handle this by sqlite3, but if you use a more complex database model with a lot of relationships it is much harder. With peewee you just query with the flag 'recursive' and you get all related object. The same for deleting entries.
And finally: you save a lot of lines of code.

E.g. you only need to create your model-class and then with two lines the entry is created in the database:

note1 = Note.create(text='Went to the cinema')
note1.save()  

BR
Olli

1 Like

Hi,

a release candidate of my new "Job History"-Plugin is out now.

Hopefully most bugs were fixed!

The first release includes just some basic ground features.
But I think the plugin is now well structured with a good fundament.

Next step is testing on different printers/cameras and cleanup the sourcecode.

BR
Olli

2 Likes

I'll give it a go as soon as my current print job finishes, got just under 6 hours on a 21.5 hour multi-color print left to go using my palette. I noticed on your planning board power consumption gathering possibly from one of my plugins. Right now, the tplinksmartplug plugin is the only one I've integrated power gathering but when you get to that point I'd be glad to help/make changes to get some synergy. To be honest, you might find pulling the stats direct from tasmota devices within your plugin is actually pretty easy utilizing just web requests. I don't have a power monitoring device but I think the link to pull would be this one.

"http://" + plugip + "/cm?user=" + username + "&password=" + requests.utils.quote(password) + "&cmnd=Status%208"

[Advertisment] New RC3 is out!!!!!

If you want to participate into the future development, please take look at this poll:

BR
Olli