LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

G-Wiz is a conversation g code generator under development by Ken Lerman. See: http://www.se-ltd.com/~lerman/gallery/v/G-Wiz/Pocket2.png.html for some screen shots of this work in progress.

Note that the name comes from "G(code)Wiz(ard)" and is (of course), subject to change.

It is being developed using Qt (which is free -- in the free software sense) on the PC. I'm using the PC for convenience. I will port it over to Linux when it gets closer to release.

(As of 2008 Fest) The Qt version has been abandoned. The new release uses Python and wxPython.

So far, I've built the screens for three wizards: the hole circle wizard, the circular pocket wizard, and a rectangular pocket wizard. The code for wizards will be implemented as gcode subroutines. Each selectable field in a wizard screen corresponds to an argument passed to the subroutine. The screens themselves are .png files.

G-Wiz scans a directory tree looking for wizards and populates the tree list on the left size with the wizards that it finds. Users will be able to add their own wizards by creating a png file, a config file, a gcode file, and a description file.

Per a discussion at fest with Dale (whose last name escapes me), I'm adding the ability to have wizards written in programming languages. See: Foreign Wizards. Dale mentioned his request at a good time. For some reason, my mind was prepped to find an easy method of doing this at the time he asked the question.

Suggestions, hints, questions, etc are solicited. Since I am not a machinist, I can certainly use some gode routines to wizardize.

In producing a library of gcode routines, there are a lot of things to be considered:

1 -- Do we support tools that cut in the CCW direction, or only tools that cut in the CW direction? If we support both, the tool direction is an additional parameter that must be accessible to every subroutine in the library. There are (at least) two ways to do this. First, each screen can have a selector for tool cut direction. Second, a parameter e.g. #100 can be reserved for this.

2 -- The same is true for lots of other parameters. The speed and feed can be preset in a previous (hand or wizard generated) line. They can be specified in each wizard screen. They can be preset as parameters that are used by convention (e.g. #101 is speed and #102 is feed).

3 -- Will the standard library routines have certain features? (A) cutter compensation (B) ramping into the material

For those who have opinions on these, please feel free to document them in this wiki. I'd suggest that we should probably add a page for each discussion as the length grows.

A few suggestions:

1. If each wizard is in its own directory, then first search for a gcode file, but failing that, search for other executables. That is, the gcode can be generated by Python or other language.

2. Parameters passed to the gcode or gcode-generating program can include strings, check box statuses, drop-down menu indices, etc. The config file will only specify numeric arguments, of course, if it is a gcode file. But a Python program could ask for strings (to engrave characters, for example) or other types.

3. Add icon files.

4. Allow both static and dynamic image files. A static file would be loaded when that wizard is started, but once any field is edited, the wizard can modify the image. Use time/date stamp to determine what image file to display.

5. Also re-display the argument fields after a field is exited, so that in response to one a field, fields further down could be modified.

6. Configuration files, in the section describing parameter fields, could also reference other wizards. (Instances? Classes? Not sure.) Thus a circular bolt pattern could reference one (or perhaps 5) instance(s) of a bolt hole.

7. Include a preface and terminating code wizard.

8. Could this be useful outside of EMC? If so, include a method to export RS274D (i.e., no "o" codes).

9. The description list for parameters could also specify separators, text without parameter fields, and even image files. (Though taken to an extreme, it starts to look like an HTML page.) But a few things like separators does help organize parameter fields.

10. Is there an advantage to having a "command line," so you could type "circle_bolt 4.0 2.3 7.4" if you knew (or could easily see) the required parameters for a wizard?

Here is a Soubroutine for a Circular Spiral Pocket in EMC G-code 
Just change the Values 
for Users how want the Tooloffset ad G41 to the Final Circel (G1 G41 X[#4-[#2/2.0]] , G3 I[#2/2.0] , G1 G90 G40 X#4 Y#5)

(Circular Spiral Pocket)
#1=3.000	(tooldiameter)
#2=30.000 	(Diameter)
#4=15.000	(centerX)
#5=15.000	(centerY)
#6=-5.000 	(Final Depth)
#7=2.000	(safeZ)
#8=1.35 	(stepover R)
#9=-2.000	(stepover Z)
#10=100.00 	(feedrateZ)
#11=200.00 	(feedrateXY)
(calculate How many times into while)
G17 	(XY Plane)
G21	(Metric) 
G90	(Absolute) 
G61	(Exact Path)

G0 X#4 Y#5
G0 Z#7
G1 Z0 F#10 (Move to Zero Z to start increment Z Cycle)
O95 while [#6 lt 0]
   O97 If [#6 lt #9] 
	G1 G91 Z#9 
   O97 else
        G1 G91 Z#6
   O97 endif
G1 G90 X[#4+#30] F#11
O10 while [#21 lt #20]
G3 X[#4-[#21*#8]] I-[[#31*#8]]
G3 X[#4+[#21*#8]] I[[#31*#8]]
O10 endwhile
G3 X[#4-[#2/2.0]+[#1/2.0]] Y#5 I-[[[#4+[#21*#8]]-[#4-[#2/2.0]+[#1/2.0]]]/2.0]
G3 I[[#2/2.0]-[#1/2.0]]
G1 G90 X#4 Y#5
O95 endwhile
G0 G90 Z#7

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited August 10, 2010 3:37 am by Sammel Lothar (diff)
Published under a Creative Commons License