Generic Post Processor Frame - reverse engineering

Does anyone have one already, or any interest to contribute?

My personal target is to detect repetitive G-code, turn thousands of lines to few intelligent ones using subroutines, loops and named parameters.

Some requirements could be:

Easy controlling (for example with more or less self-descriptive xml-tags) to enable non-regex usage for searching and replacing the blocks of code:

- detection of replaceable start and end block (some regex expression can be used also in tag values by advanced users) but generally *- and ?-wildcards should enable effective use

- way to read parameters from near block start and end with some example syntax like :

- read 3rd row, 2nd or X-parameter of G1 after start row, name it "pyramid_wall_x", use variable inside the replaced context, optionally after that also

- replace starting +- n lines before/after, replace ending similarly, optionally starting from a name-defined command, or Nth parameter on startline

- inclusion of re-usable code, passing parameters, and generating names for parameters used, add snippets

- parameter or variable generation from scanned lines inside a hyphotetical pyramid like X-> "pyramid_width", Z--> "pyramid_bottom_layer", again when in another block "X"--> pyramid_wall_x

- detection of min/max-values, name them like "pyramid_wall_start", pyramid_wall_end

- recursive: generate iteration inside iteration: detect block in generated block, replace again some named_parameters, generate internal loop

- Chainable, easy way to define output and input parameters between the blocks

If someone knows anything like this, for example from totally different context, please let me know.

Unfortunately I personally have no time to this before July but if someone sees any sense in this, I can contribute by writing some xml-pseudo reflecting the requirements.

I'm not sure I understand what problem you are wanting to solve. What would be the advantage of such code? I don't see that it is advantageous to implement design changes by modifying the G-code - it is surely easier to modify the STL and re-slice?

If your goal is to reduce the size of the G-code file, then a simple Limpel-Zev compression routine would do that - it effectively finds repetitive code and substitutes a token. The decompression algorithm is simple & fast enough to have the controller decompressing on the fly - but I see no need to do this these days as the files are relatively small uncompressed compared to storage and memory.

Dave

Dave,

Great point - what to really "obtain with that reduced code", once again I went to tech specs without writing anything sensible for the stake holder! :-DD

I'm after human-readability, and generating lean human understandable and re-usable G-code.

Whether a postprocessor or G-code is a right way to do it, is also a good point. This started from my initial need to turn G1s of circles to G2/G3 - commands, ok, I found a tool doing that (not tested, but took a short glimpse of the perl-code) z-level -wise. But why not to go further?

Many softwares (like 123-Design free version) puke that machine-flavour stl, and that's the only yummy for example Repetier likes to eat.

I'm sure a guy eager to do things on their correct place, but I'm not aware of any looping in STL (textual or binary), is it possible? What I know (albeit being a newbie), STL is just a bunch of triangles, of course including the same or root information, but in G-code there are basically easily detectable layers. My current version of Slic3r (1.1.7) doesn't support G2/G3 at all, and the same applies to Cura.

Of course, re-using G-stuff between parties having different slicing and printer settings, is practically impossible now, but maybe getting the different factors inside the G-code could help in that also.

Now, after clarifying the idea not being around the file sizes, LZW is out of this discussion.

But after all, if you have better ideas to accomplish the target, please let me hear about the ones!

I'm not convinced that having the G-code any more human-readable than it already is will have any practical advantages. G-code is designed for use by machines, and is rarely looked at by humans apart from very occasional debug purposes or to make minor changes (e.g. inserting a pause at a layer height or changing temperatures etc.). Anything more complex is best done at an earlier stage (before slicing) or via a computer application that reads/modifies the G-code rather than hand-editing.

I can see there could be some reason to compress the code in certain applications (and lose all human-readability). e.g. real-time operation over a relatively slow link. If that is the goal then it would be pretty trivial to convert every character to a 4-bit value (G-codes tokenised and numeric values BCD packed), then that file could be Limpel-Zev compressed to reduce all repetitive moves. This should easily result in a file that is 10% the size of the original G code but still reasonably trivial to expand.

Dave

Hmmm...

Dave, if you don't see any idea in making G-code human-readable, is it very useful to mock the very idea?

I cope with better ideas like "doing the things at earlier stages", but could you suggest something constructive? Please do some real suggestions!

Threre are people who appreciate readable G-code, understanding what my 3d-printer does and why.

And if you take account that some stl is loaded as it is, some generated by the user who is doing the printing, what are our choices?

I was not mocking the idea, and do not see that anything I posted could cause you to believe I was. I stated that I am unable to see any reason for making G-code more human-readable, which is questioning your idea, not mocking it. I did indeed offer a couple of constructive ideas (including the one you gave as an example). Perhaps if you were to give an example of a situation in which having the G-code more readable would make it easier, quicker or cheaper to modify a design than existing techniques I would understand the need and change my view. G-code is always going to provide a slice-by-slice and semi-rasterised representation of an object which is not conducive to easy interpretation by a human no matter how its format is changed. Compatibility issues are best corrected by running some type of script on the G-code file. STL's can be edited with a suitable CAD application whether they are your own design or not, though there is little that will beat using the original design file of whatever CAD program created the design.

Dave

Dave,

Sorry I used too hard words - we are both after a solution, not more problems.

For me it would be at least nice to have human-readable and thereby also editable and re-usable code.

[www.youtube.com]