@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
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.
Hopefully I can release a first development version next week.
By
Olli
3 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
[Advertisment] New RC4 is out!!!!!
The new version includes the option to use the thumbnail from UltimakerFormatPackage-Plugin.
It was planned for release 2, but it was easy to implement and I want to use the "momentum" of the new released plugin 
The plan is that rc5 is the last before I am bringing my plugin into the official repository.
C ya,
Olli
1 Like
Thanks for the added momentum...
When can you propose a version into official repository ?
So I just realized today that this plugin hasn't kept history for anything for the past month or so. What do I need to look at to troubleshoot?
You may look for the most recent upload at the github.
Hi @typhoons,
the goal is to finalize the first version end of the month and then I will try to put it to the offical repository.
I had some unexpected trouble with my existing plugin "DisplayLayerProgress", so I didn't achieve my goal to release it end of 2019.
@simpat1zq as Ewald_Ikemann mentioned, just create an issue and describe your issue in detail.
1 Like
has this plugin been updated to work with the latest version of OP? It stopped working for me at the first RC and it still doesn’t on the latest stable release.