isn't -1E10 = -10000000000?
Oh snap, I was thinking 1E2 in my head, you're right. ha
I'd probably add a little bit more info to the debug flags plugin link, saying it's only for setting repetier firmware's own built in debug flags (of which dry run mode is just one option) and not as comprehensive or customisable as your plugin.
If you have Repetier Firmware, "dry run" mode is already built in, you can easily tweak the debug flags to enable or disable it using this plugin < insert link here >
Very good discussions so far. Thanks a lot!!1
@foosel totally agree, a specification is a good think!
So for the MVP (Minimum Viable Product) my spec looks like this:
- Turn on/off feature with checkbox under print-buttons
- User could define exclude-patterns in plugin-settings
- User could define include-patterns in plugin-settings
- Only one methode is possibel (ex- or include)
- Posible to send pre "Cooldown"- and "Fanoff"-commands
- The mentionied expression here are the default values
Hopfully I can release the first version next week.
It took a while .... (more than a week) .... but now I released a first version of "Dry-Run".
I droped the "Expression-Approach" and use the "Test-Mode" Code from "@FormerLurker". (Thx, for your work )
Maybe I change the behaviour in the future.
If you want to take a look: https://github.com/OllisGit/OctoPrint-DryRun
Great work @OllisGit!
You might be interested to know that I've re-written that parser in C++ and is easily an order of magnitude faster than the python version. It's not production ready yet, and eventually I want to make it installable via pip. When it's ready you should consider using it as it would increase performance and simplify your code.
Edit: I forgot to mention, I just got it working in Python 3 too. I noticed you added some compatibility to the old parser code since I just started learning the differences between the code versions (I learn eventually, lol!).
@FormerLurker did you do the rewrite because of performance-issues?
In my case, it could be possible to parse the whole g-code and filter the "harmful" statements before printing.
So, not every statement is parsed while printing.
I never thougt about performance, because Octoprint is just sending small text-lines to the printer. A Raspberry should handle this easily.
Or did I missed something?
It's probably not a big issue for your plugin since, as you said, you are parsing one gcode at a time, and there are only a limited number of gcodes being parsed per second. However, I wanted to parse an entire gcode file before printing, which took 270 seconds for a 30MB file at first on my PC (way more for a and rpi), which was unacceptable. I got it down to between 1 and 2 second running the C++ natively, under 5 seconds while running through OctoPrint on my dev machine, and about 25 seconds on the PI, which I think is pretty good. Not only does the routine parse gcode, but it can also track position, extruder state (retracting, retracted, extruding, primed, etc), axis mode, layer number, height, speed, and statistics like total filament extruded. Position tracking is important for Octolapse, obviously. It even has logging support!
The primary benefit, once it's finished and available to install via pip, is that you'll be able to add it to your setup.py file as a required module and it can be automatically updated if changes are made. I'll post back here once it's ready, though I have to say I've had lots of trouble developing the module. The documentation for C/C++ extensions is confusing and incomplete, and many behaviors of the various python.h functions are not consistent, especially dealing with reference counts and calling back into Python. In other words, it will take some time before I get all the kinks ironed out. I wish I knew some Python extension and/or C++ experts who could review my code. It has been a great learning experience though!