Support for variables (#3), math (#3*5+#<gcb>) and Brackets ( X[56*#<scale>] ) #12
Comments
|
@maculata Do you have some sample gcode you could post here? I'd imagine this would be done by pre-processing the gcode, which may be out of scope of |
|
linuxcnc specs: |
|
(Mill - generated: Sat Apr 7 22:26:21 2018 ) (Units = G20 inches) (Z Clear Location = 0.0800) (Z Depth of Cut = 0.0300) (----- Start of G-code -----) G17 G90 (XY Plane, Absolute Distance Mode) G64 P 0.0050 Q 0.0000 (Path Blending) (font: FONT.TTF) G17 (set current plane to XY) G30 (move to preset G30) G00 X [#5] Y [#6] M9 (stop coolant) G30 Z [#1+#7] (move in Z only to preset G30) |
|
@maculata I think this does the job: #!/usr/bin/env python
import sys
import re
filename = sys.argv[1]
regex_paramset = re.compile(r'^#(?P<name>\w+)=(?P<value>[^\s\(]+)')
regex_expression = re.compile(r'\[(?P<exp>[^\]]+)\]')
regex_param = re.compile(r'#(?P<name>\w+)')
params = {}
with open(filename, 'r') as fh:
for line in fh:
# parameter set
match = regex_paramset.search(line)
if match:
params[match.group('name')] = float(match.group('value'))
sys.stdout.write("(%s)\n" % line.rstrip('\n'))
continue # don't print line
# evaluate expressions (with parameter substitution)
for match in reversed(list(regex_expression.finditer(line))):
exp_str = match.group('exp')
for m in reversed(list(regex_param.finditer(exp_str))):
exp_str = exp_str[:m.start()] + ("%g" % params[m.group('name')]) + exp_str[m.end():]
exp_result = eval(exp_str)
line = line[:match.start()] + ("%g" % exp_result) + line[match.end():]
sys.stdout.write(line)so if the content you've pasted above is in a file called ./pre-process.py input.g > output.gI haven't tested it, and it has limits, but it should do the trick for now as a workaround. |
|
To clarify: Furthermore, the pre-processing done by the above script is something I'm currently planning dialects for Designstuff to think about, mostly brain-storming Variables in different Dialects
Expressions in different Dialects
Line Processor Idea
Ideas welcome |
|
Good day folks! This is quite the conundrum.... And is why G-code files are not universal and cannot be shared across most machines. I program CNC machines in an industrial manufacturing environment, and this was very disappointing when I first learned it. Every machine controller can have different capabilities and can choose to interpret g-code files in it's own way. This is why your CAM software of choice requires a "Post" file to help it generate a G-code file that is compatible with your machine. Many times, the only way to utilize some features of the controller is to hand edit the G-code file yourself (or write your own plug-in for your CAM software). The machine I use at work uses an Osai 10 Series controller which interprets code differently than a Haas machine would, for example. It's easy for a hobbyist to assume that G-Code files are all interchangeable because most of them use the same software (Linux CNC or Mach 3) in their controllers, but this is not the case in the rest of the CNC world. Basically, the "dialects" you speak of will be a configuration file of sorts to help pygcode emulate certain controllers, is that right? Or perhaps you could choose to emulate a LINUX CNC or MACH 3 based machine with the dialects being different post file configurations? I look forward to see how this goes! |
This appears to be missing.... did I miss something? Thanks
The text was updated successfully, but these errors were encountered: