Re: [CAD_CAM_EDM_DRO] CNC scripting stuff....

On Wed, May 18, 2005 at 11:03:51AM -0500, Jon Elson wrote:

> Right! TK/TCL are meant for creating GUIs, and are a bit rough, but
> handle a
> lot of the complicated details of packing many windows, buttons,
> sliders, etc.
> onto a screen. But as a programming language, it leaves a GREAT deal to be
> desired. Debugging is nearly impossible, too!
>
> Jon
>

Nah, you're thinking more of Tk which came after Tcl, although it does
make graphical programming pretty simple. Tcl itself is small, very
embeddable, extensible and has trivial syntax. You can write
extensions in Tcl or C and that OO stuff is available if you want it.
As with most tools, proper application is the key to an easy job.

Debugging insn't that big a deal either and there are debugging environments
available as well.

Tcl itself was never meant to be a general purpose programming language
(although you can abuse it that way). It's a scripting language, which
is why it would be useful for the application we were originally
talking about. Given a number of extensions that would generate
appropriate Gcode, it would be trivial to write short scripts that
would produce Gcode to fabricate parts. Now, would you write those
extensions in Tcl? You could, but I'd probably use C myself.

As a thought experiment let's say you had a pocket extension that took
length, width, depth, and X and Y coords of the center and you wanted
to created gcode for a 4 x 4 array of them, the Tcl script might look
something like this:

set gcode []
for [set row 1] [$row < 5] [incr row] {
for [set col 1] [$col < 5] [incr col] {
set X [calculate X coordinate based on row and column]
set Y [calculate Y coordinate based on row and column]
lappend gcode [pocket $length $width $depth $X $Y]
}}
puts $gcode

The key to making this useful is defining the correct extensions with the
right parameters, determining which are optional and what the default
values would be. Then you just write short Tcl scripts to produce the
gcode for whatever without having to worry about a lot of syntactical
gobbledygook.

If you wanted to be fancy, you could keep the gcode in an internal data
structure and optimize it when it was retrieved rather than returning
a list of gcode on each call as shown above.

Paul

--
Paul Amaranth, GCIH | Rochester MI, USA
Aurora Group, Inc. | Security, Systems & Software
paul@... | Unix & Windows