G-Code decison trees, goto and loop?

[BrooksM]

Hi

If I understand the G-Code spec and might be post processor specific, it supports gotos, decison trees, and loops.
I was wondering if anyone has messed around with that.
I can understand in a production environment, to have an operator load one multiple G-Code file and given the choose of which file to run or for looping the pass depth when re-surfacing.

Just interested. A friend asked.
Thanks for any thoughts.

Brooks

[Adrian]

I don't know about g-code but I do operations like that all the time with my ShopBot which uses the OpenSBP language instead.

[FabLab Wageningen]

Give your friend this to read:

https://rick.sparber.org › GcodeLogic
(is a PDF download)

I know Gcode. I have 25+years experience in programming. Would I use this for CNC'ing ? No way. Too much risk of f*cking up.

Marcel.

[BrooksM]

LOL Marcel,

Will do.
Adrian do you call the tap files as macros within OpenSBP?

Thanks for the food for thought.
Brooks

[wb9tpg]

Hi

If I understand the G-Code spec and might be post processor specific, it supports gotos, decison trees, and loops.
I was wondering if anyone has messed around with that.
I can understand in a production environment, to have an operator load one multiple G-Code file and given the choose of which file to run or for looping the pass depth when re-surfacing.

Just interested. A friend asked.
Thanks for any thoughts.

Brooks

I'm messing with it currently. Adrian pointed me to inserting LUA code into my post processor. It looks like it'll do the job but I got distracted by something shiny and set it aside for the moment.

[BrooksM]

Thanks for the link Marcel,

Mr. Sparber's pdf looks to be Centroid specific, syntax-wise.
So, Adrian's comment might mean it's not G-Code (RS-274) but user interface software specific.

wb9tpg, I'd be interested in what you find out when you get back to working with the LUA code.

Thanks
Brooks

[Leo]

I have done a lot of family of parts programming using that logic, with variables as well as setting work coordinates in g-code and other machine setting as needed. There are an infinate number of ways that logic can be used in CNC programming!!! Is there ample opportunity to run into issues with it - absolutely. Is it useful - absolutely.

How to use it in Vectric - no way that I know of.
Are all machine controllers able to process it - no.

When I programmed what I called parametric programming it was done 100% by hand - no CAM at all.
Faunc calls it Macro-B programming.

I think CAM packages like MasterCam has some capabilities to do parametric programming.

I do not believe that Vectric would ever incorporate that into the software. I don't think many at this level of programming understand it, neither is there much need for it.

[FabLab Wageningen]

It will definitely be very user (post-processor / machine, really) specific.

For basics, your post-processor needs to generate (logical) line identifications (numbering would be nice) which our Makerspace's post-processor (targeted at a Duet2 -equipped Ooznest WorkBee) not has by default. If not, maybe labels will help. If not that, you're in trouble, methinks.

I agree with Leo: it would be a nightmare for Vectric to build in and maintain for everything and everyone.

Marcel.

[Leo]

The only one time I created a parametric program 100% in CAM was with Unigraphics on a TW-20 Millturn machine. I also needed to create a new post processes specific to the machine. The post generates 100% G-code, but the CAD/CAM was driven by a spreadsheet filled with variables and the model was drived by the spreadsheet. That software was very expensive and required extensive training. If Vectric ever got that sort of stuff going it would cost 10-50 times more than Aspire costs now.

LUA is probably a good option. I have never tried it.

[BrooksM]

Thank you guys for your thoughts. I've got some research to do.
My friend has something like this in mind but I'm not sure what user interface or CNC controller he's using.

N100
1. change bit and set Z0
pause, change bit, run touch off, and return to X0Y0 M99
goto N100
2. call a tool path (e.g. 3D Roughing.tap/mac+M99)
?M3 (M3= m98 3D Roughing.tap)
goto N100
3. call a tool path (e.g. 3D Finishing.tap/mac+m99)
?M4 (M4= m98 3D Finishing.tap)
goto N100
4. call a tool path (e.g. Profile Cutout.tap/mac+m99)
?M5 (M5= m98 Profile Cutout.tap)
goto N100

My first skim in the WinCNC macro manual implies something along these lines. I'm still exploring the Vectric LUA scripts.

Brooks

[kstrauss]

There are many flavours commonly called "Gcode" -- genuine RS274, Mach3, LinuxCNC, etc. The LinuxCNC flavour has named variables, looping, conditionals, subroutines, etc. Many of the other flavours do not.

[Rcnewcomb]

parametric programming

Years ago I suggested to the founders of Vectric that they develop and market "Vectric Parametric" mostly because it had a cool sounding name rather than any need I had for parametric programming. The founders wisely decided to build on their core products rather than chase some wild goose.

[Leo]

Thank you guys for your thoughts. I've got some research to do.
My friend has something like this in mind but I'm not sure what user interface or CNC controller he's using.

N100
1. change bit and set Z0
pause, change bit, run touch off, and return to X0Y0 M99
goto N100
2. call a tool path (e.g. 3D Roughing.tap/mac+M99)
?M3 (M3= m98 3D Roughing.tap)
goto N100
3. call a tool path (e.g. 3D Finishing.tap/mac+m99)
?M4 (M4= m98 3D Finishing.tap)
goto N100
4. call a tool path (e.g. Profile Cutout.tap/mac+m99)
?M5 (M5= m98 Profile Cutout.tap)
goto N100

My first skim in the WinCNC macro manual implies something along these lines. I'm still exploring the Vectric LUA scripts.

Brooks

Yeah - the logic makes sense. Make sure the control is capable of the language "goto" M3 M4 M5 is generally spindle comands CW - CCW - STOP M98-M99 are generally subprogram call and return commands - don't really need the GOTO

So your control my be different, but most G-Code is pretty generic.

That logic is very similar to the way I run my machine with toolpaths.
The only difference is that I need to load my programs manually, which is a simple thing to do.

[BrooksM]

Thanks for the feedback, Leo.

We're just scratching the surface of the research and still have not figured out how to pause and process a the user's input.
And there is always mission creep. A discussion to add a re-surfacing routine with a user's DOC input. Oh well!

Brooks

[dealguy11]

Maybe I'm misunderstanding what you want to do. Is the point of this to make the gcode stop for a tool change and re-touch between each toolpath? That shouldn't require a loop or anything trickier than a macro in the control software.

I've had single-spindle machines that did that, and they were set up with a macro in the controller that executed upon tool change that would perform the task of moving to the tool change position, waiting for input after the tool change, then touching off from a fixed touchoff point before continuing. The post-processor was set up to execute that macro at each tool change. Then it was just a matter of creating all the toolpaths in Aspire, saving them to a single g-code file and running it. One of the machines that did this was a WinCNC machine, so I'm certain it works there.