Do any GCode editors actually offer... editing?

[deonb1]

I've been evaluating GCode editors for the last week, and boy, I feel like I'm back at the time of punch cards!

I can't find a decent gcode editor that can do the most basic of tasks, like allow me to (graphically) draw a rectangle around some shapes and delete them (which I then expect it to remove from the GCode file and do a rapid over that region at some safe height).

The closest I can see is CamBam, which I can do Toolpart to Geometry then delete from there, then back to GCode. This works around 25% of the time - the rest of the time it doesn't feel like selecting the (completely isolated) geometry around which I'm desperately trying to draw rectangles.


My scenario:

I'm using pcb-gcode output that's Z-axis adjusted with output from a Mach3 digitizer run that probed the top of the board every 5mm in X & Y.

I've had a slight misread of part of the probe run so it was too high, so now I just really want to delete some stuff in the file and re-mill a small part of the board at 0.1 mm deeper than the first run. It's impractical to edit the gcode in text mode because due to the Z-axis adjustment, even tiny shapes consists of 1000s of lines scattered all throughout the file.


Any recommendations? Or lacking a visual editor, how is this kind of touch-up generally done?

[ger21]

I can't find a decent gcode editor that can do the most basic of tasks, like allow me to (graphically) draw a rectangle around some shapes and delete them (which I then expect it to remove from the GCode file

That seems like a very complex task to me. I've never seen anything that can do that. If there is, it would probably be a full blown CAD CAM package.

[BobWarfield]

Deon, what you're describing is called "graphical toolpath editing". You can Google it to learn more, but it's typically been a high dollar CAM function more than an editor feature. At least I've never seen one that has it.

With that said, what you describe is not too hard to implement, particularly if you can forgo the visual drag and drop rectangle piece. For example, the ability to enter a command that would make a rectangular region "off-limits" and something to be rapided over at a safe height sounds doable.

I'll think about it some for G-Wizard Editor. I'll also think about some graphical editing.



Cheers,

BW

[deonb1]

I don't know why this is considered such an extreme high-end feature. I was able to create a primitive graphical gcode editor over the weekend using C# & XNA. Screenshots below. I'll post the code and bits up to SourceForge after I cleaned it up a bit.

Spent most of my time on the graphics and selection mechanism (didn't know anything about XNA). The actual delete algorithm itself is trivial:

* for each (Gcode) {
* Update "current tool position" based on GCode
* if (GCode in selected region) {
* Change GCode to rapid move to "current tool position"
* } }

Then run again across all the (updated) GCode and remove consecutive rapids and replace with single rapid to "current tool position" (also continuously updated as above).


No idea if this works generically for any arbitrary gcode, but it works for gcode produced from pcb-gcode, which is what I want to use it for.

Selection:


Keep selecting & hitting deleting until left with:


Save the file and open in CamBam (to prove I'm not cheating ):


I need to still run a travelling salesmen algorithm through the final output. As you can see from CamBam there are a few remaining unnecessary rapids remaining (they're not consecutive).

[datac]

I don't know why this is considered such an extreme high-end feature. I was able to create a primitive graphical gcode editor over the weekend using C# & XNA.

I think less that its only a high end feature... perhaps more that few may have had a need for it simply in that just deleting the G-code for a selected group of visible entities still would leave plenty of undesired motion in the code. What happens to smooth motion connections to some of the things you can not essentially see in a selection like rapid rates and Other I/O commands sent with M-codes? When you drag/delete in this way, what happens to the plunge commands ? Are they gone too ? Or, do some go "lost" ?

A g-code file is essentially a compilation of entities IN AN ORDER... a sequence of what the operator WANTS it to be. Just dragging thru a section of the visual aspect would seem to leave some bad results without additional hand editing. I could see crashes without hand editing afterward.

it brings me to the question of why are you editing your jobs at the g-code level and not at the drawing level ? Editing in the drawing level and reposting the code deals with adequately sequencing the job.

All that said, I dont imagine it is something that can't be done. My absolute favorite editor has been NCPlot. Perhaps write to them and ask the whats and whys. In NCPlot, it would be easy to do what you desire on the code side... refreshing the code would show you what you end up with, but you would still have the potential for missed plunges and the like without editing by hand.

I'd say just edit on the drawing side and regen the code...... Thats what the bulk of people would do.

[deonb1]

Editing on the drawing side is serious business with EAGLE!

EAGLE is very far removed from the gcode output, and there is no other drawing tool in between. You'll effectively be working on the negative side of a board, with no indication of what it represents since the isolation routing isn't computed until you run pcb-gcode. As another practical concern, the settings for pcb-gcode are global, and not saved per board, which makes redoing a gcode run after a while quite challenging.

So EAGLE + pcb-gcode is the "drawing tool" here, but it's absolutely not the right tool for the job to touch up GCODE in my opinion.

The next thing to do is to run GCode to DXF and back to GCode, but then there is no guarantee that the order or directions will be maintained, which is very important on rework. Also, I don't like playing with file conversions while my CNC almost finished a 7 hour routing job. File conversion are dangerous - a tiny mistake can ruin an otherwise perfectly good PCB e.g. by just slightly getting a turning angle off on an existing 10mil copper path. It's not expensive really but I then have to repeat the entire job, which is primarily what I want to avoid by just "touching up" the gcode and rerunning part of it.

So I want to maintain all my GCode as intact as possible, in the original order, and just do rapids at some safe Z over the parts that have already been milled (since a re-mill may ruin them). And then by removing useless rapid sequences (which is safe to do), I don't have to wait the 7 hours. Simple.

For the plunges - as long as the editor is 3D, plunges are not specifically a problem. They're just effectively linears on the Z axis instead of on X or Y and can be selected and deleted individually or along with everything else.

E.g. (Not the greatest example I know, but you should get the idea.)

(The contours you see in 3D is because I first probed the board height with MACH3 using a simple 2-wire conductor "probe", and then ran the pcb-gcode + MACH3 output through a post processor, so that the mill paths just-just hug the top of the board continuously at 6 mils deep.)

I keep MCode in the same order, though there might be a few unneeded start/stops and tool changes in there since the paths around them have been deleted. Can do something more intelligent here, but pcb-gcode don't output those for milling anyway. (Does it for drilling though).

However, my whole point of this exercise wasn't to write a new editor, but to prove that it's not rocket surgery for an existing GCODE editor to provide basic graphical GCODE select/cut/copy/paste/delete functionality, you can have something reasonably working in a couple of days, and can probably have something shippable within a month.

I guess I'm just finding myself in a unique problem here and nobody else has the need to edit GCode like this graphically. Sigh.

PS: NCPlot is too slow to be useful a tool to me. It takes several minutes to render a complex pcb-gcode file (on a fast SandyBridge SSD machine). But even after that, I also have to edit the GCode in text, which is impractical. I'm deleting 100's of thousands of lines of GCode here that's scattered throughout the file, interspersed with lines I do not want to delete.

Because of the nature of pcb-gcode output you may have dozens or even hundreds of individual tracks right next to each other to form a single isolation route, but they're not necessarily located right next to each other in the GCode so you have to go look for each of them individually. No thanks!

[Kiwi]

With older versions (V20) of BobCad, the code can generate the toolpath on screen, lines/areas deleted on screen and then regenerate new code.
This may also be able to be done with other CAM programs. I just don't know them.

[deonb1]

Interesting. I have a BobCad V24 evaluation here. Trying now.

Uhh... How do you open a GCode file in BobCad?

[Kiwi]

Interesting. I have a BobCad V24 evaluation here. Trying now.

Uhh... How do you open a GCode file in BobCad?

Here are pics using V20. I don't think this can be done with V24?

[deonb1]

Drool...

Is that just the BobCad v20 CAD/CAM product itself that provides this, or are there any additional packages that you loaded (like Milling)?

[Kiwi]

Is that just the BobCad v20 CAD/CAM product itself that provides this, or are there any additional packages that you loaded (like Milling)?

That is BobCAD-CAM V20 Std Package. No additional packages.
I believe V19 & V21 work the same. Major changes were made to V22.

[Kiwi]

deonb1
1. Tool path generated from code.
2. Zone selected and colour changed.
3. Zone selected hidden and G00 paths to zone eliminated.
4. Other area hidden and zone shown.
5. Zone selected and code generated.
6. New tool path generated from new code.