[vmax549]

Subs run as expected. It does NOT recognize L0. The L0 IS a very handy feature.

Also it needs to be able to call a remote sub from the SUB directory.

I do not know what the max depth of the sub stack can be but I will test it (L# max value)

I do not know what the max. number of NESTs is .

(;-) TP

[ger21]

I wonder what percentage of users use subs, especially in the hobby market. I'd guess maybe 1%? 3%-4% max?

[derek]

I make money with my machines and I don't even know what a sub is or why I wold use it

I'm wondering if this is a hand coder vs CAM scenario. I draw everything I build. At the very least a 2D line drawing. If I have a drawing why would I hand code? For me CAM is king. Also there is a chair in front of my design station. The machines not so much

Derek

[vmax549]

HiYA Derek, No it is more about doing a family of parts. Lets take a cabinet door. I bring in teh base code to produce a 24x24 size door. Then I call a sub to cut in a certain pattern. Then call another sub to add in another feature. In effect I created a custom door from stocked features . So once all the base code has been created in CAM I can call anything on demand and create a complex part AND never have to even fire the CAM up. It is just a matter of hand coding the Base Gcode to call all the needed features.

M98 P1 L1 ( cuts a feature)
M98 P102 L1 ( cuts a different feature)
M98 P10 L1 ( does the finish detailing)
M30 ( done)

OTHERWISE I would have to totally create the entire project in CAD and CAM for each custom door. With subs I just need a list of the features. NO CAD NO CAM needed. OF COURSE NOW I do need to remember where all the SUBs are and be able to CALL from that directory. (;-) I just had to throw that part in there.

NOW are subs for everyone NOPE but they ARE extremely handy for those that can use them and know how.

(;-) TP

[dontpanic]

I would use the macros just as you do.

We used to programm a knee mill long years ago in the shop floor exactly as you are explaining.
we created family of common operations with fixed macros, then we "assembled" some new parts
very easily without any need for cam or thinking trajectories. It was straightforward and very SECURE
because the Subs or macros we used, were all tested.

We need from UCcnc the macro support as I mentioned in another triad. To be able to call a macro from another macro
with

M98 mickey.tap .....
M98 donald.tap

etc....

[vmax549]

OK you are talking both apples and oranges. Subs are subs and macros are macros (;-). UCCNC does not have G65/G66 like fanuc

When you use M98 you are calling a SUBprogram

When you call a Macro it is an Mcode M9001.

AND YES we do need to be able to call a global sub from an outside folder

In teh Haas world they use M97 for a local sub (inside the Gcode) and M98 for a global sub (outside the Gcode)

(;-) TP

[OlfCNC]

I would use the macros just as you do.

We used to programm a knee mill long years ago in the shop floor exactly as you are explaining.
we created family of common operations with fixed macros, then we "assembled" some new parts
very easily without any need for cam or thinking trajectories. It was straightforward and very SECURE
because the Subs or macros we used, were all tested.

We need from UCcnc the macro support as I mentioned in another triad. To be able to call a macro from another macro
with

M98 mickey.tap .....
M98 donald.tap

etc....

UCCNC can call macro from macro, however I think you thought about subs instead of macros,
but it can also call subs from subs, so no problem with that either.
Subs must be the part of your g-code thought, not external files.

[dontpanic]

Sory I was meaning calling a subprogram stored in a sepparate file ! Not a macro.

I tested at the moment Macro calls, and it works well in v.1.2
I tested also Subprogram and return on the same file and it works well in v1.2

I can not call from 1 file another Gcode file. This is a subroutine or subprog. stored in a sepparate file.
(I am testing at the moment yours example with exec.mainform.loadfile() so probably I get a workarround
calling a macro from a Gcode main program, that this macro calls a file... it is more complicated than
a G98 "externalfilecall.tap" but..... it is a workarround)