Thanks for the hint and also for the solution.
I will add the two expressions on the top and but the "remove" expression to the bottom.
match [^G[0-1] E[+]*[0-9]+[.]*[0-9]* F[0-9]+] single extrude, feedrate at the end
match [^G[0-1] F[0-9]+ E[+]*[0-9]+[.]*[0-9]*] single extrude, feedrate at the beginning
I suppose it would be correctly if you also do the version in which the G0/1 En doesn't include the feedrate... after those two above. If you did the naked version first, then the orphan doesn't match, get it?
I don't think commands such as G1 F100 are 'orphaned' at all. This would set the feedrate for commands that follow this one, and your slicer may rely on this for subsequent commands.
TLDR, you should definitely keep the 'naked' feedrate and send it to the printer.
Edit, change question mark to period
One more thing, I found that using regex to parse gcode is daunting. Initially I was using this technique for my plugin, and found that things were way easier to use a regex for each parameter. However, I found that even this doesn't work all the time either (I can elaborate if you want) and ended up writing my own parser. Let me know if you ever think about switching.
I'd be curious to hear this one.
@OutsourcedGuru, I was afraid you'd say that, lol! Check out this issue. Basically I learned that spaces could be added or removed anywhere within a valid gcode line and the result is also valid gcode. I'm not sure if every printer can handle this (probably not), but the Taz6 at least could. Also i learned that decimals can include a + (I already took the - into account).
As I tried to take every newly discovered situation into account my regex got crazier and crazier, until I decided to scrap my original code to try another approach. Unfortunately my parser now will likely accept gcode that many machines cannot interpret, but I figure it's better than misreading gcode that the printer CAN handle. I'm sure there are still improvements that can be made, but now I don't need to write any regex if I want to handle a new gcode, I just need to add a new command object to my list of accepted commands. The rest I just ignore.
Here is a command definition I created for G0 which contains the command address, a friendly name, a display template, the accepted parameters and the associated parameter value parsing function. Each paramater also includes a display order used when converting a command object back to a string:
G0 = Command(
"G0",
"Rapid linear move",
"G0 - Linear move to X={X}, Y={Y}, Z={Z}, E={E}, F={F}",
parameters={
"X": CommandParameter("X", CommandParameter.parse_float, 1),
"Y": CommandParameter("Y", CommandParameter.parse_float, 2),
"Z": CommandParameter("Z", CommandParameter.parse_float, 3),
"E": CommandParameter("E", CommandParameter.parse_float, 4),
"F": CommandParameter("F", CommandParameter.parse_float_positive, 5)
}
)
This object is added to a command dictionary and for 'cool running mode' is also added to a list of commands that should have the E parameter stripped. Another list is maintained for commands we want to completely suppress in this mode.
Let me know what you think about this, especially if there are obvious flaws in my logic that I'm overlooking.
Thanks for all the work to type that up. I had no idea how loose the specification was. (And I'm usually the one to point out that 1E1 is actually a number to my students.). I wonder how the printer would do with this one G1 E-1E10? :evil laugh:
There is no actual specification, that's the problem 
I REALLY hope that doesn't work 
In theory, that's a 100mm retraction.
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.
Something like
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:
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
C ya,
Olli
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?
C ya,
Olli
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!
I know this thread is pretty old, but I just ran across it.
Marlin 1.8 (possibly earlier, and presumably later) has a built-in safeguard agaist cold extrusion:
Send: N13 G1 X10.0 Z0.2 F3600*72
Recv: ok
Send: N14 G1 X70 Z0.4 E9.0 F1000*23
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
I use this all the time for testing - the printer will still "run" all the moves normally, just not heat or extrude. No plugin or code changes needed. Very handy.
For what it's worth, I dry-print files every workday of my life this year. I don't need to waste plastic just to see a prototype dance.