Tormach's deprecation of advanced gCode features

[Fenichel]

Named parameters, subroutines, math functions, and miscellaneous control structures (if/endif, repeat/endrepeat, do/while, while/endwhile, break, continue) are explicitly deprecated by Tormach, with the claim (Section 7.9 of my 770 manual; probably similarly located in other manuals) that such code is "difficult to debug and very difficult for another operator to understand."
This is backward. For example, the PP's conversational facilities let me generate gCode to do external thread milling of two 1/4-20 threads, located at (0,0) and (1,1). The resulting code (579 lines) is in the attachment. Most of its lines are nearly-repetitive blocks of which

(Pass 5)
G0 Z 1.5099
G1 X 1.3610
F 16.92 (Arc Feed, inches/minute)
G2 X 0.7079 Y 0.7878 Z 0.3399 I -0.3610 J 0.0000 P 24
F 10.00 (Feed, inches/minute)
G0 X 0.6870 Y 0.7726
G0 Z 2.0000
G0 X 1.3869 Y 1.0000

(Pass 6)
G0 Z 1.5092
G1 X 1.3598
F 16.95 (Arc Feed, inches/minute)
G2 X 0.7090 Y 0.7885 Z 0.3392 I -0.3598 J 0.0000 P 24
F 10.00 (Feed, inches/minute)
G0 X 0.6870 Y 0.7726
G0 Z 2.0000
G0 X 1.3869 Y 1.0000

are typical. As seen here, some of the numbers are the same from block to block, some are related to each other in simple arithmetic or trigonometric ways, but others are completely obscure. To call this sort of code easy to debug seems crazy, and it's hard to see how anyone might read it to learn about the considerations involved in thread milling. If a user wanted to revise this code (say, by adding another thread, or by moving the second thread from (1,1) to (1,2)), then trying to edit the changes into the code would be hopeless. A more ambitious revision (suppose that one of the bosses to be threaded were near an obstruction, so that the tool's escape path at the bottom of the thread had to be more complex than a radial move followed by a straight move up) would be out of the question. The only way to do any revision would be to go back to the PP conversation.
I have tried to reverse-engineer this code, and to rewrite it using techniques which would be considered elementary in any other programming environment. The reverse engineering was incomplete, because

• The initial feed rate used for cutting the thread is larger than the user-specified feedrate by a factor whose origin is obscure.
• On successive passes cutting each thread, PP slightly increases the feed rate along the arc, presumably to maintain chip load. I didn't figure out what calculation PP uses for this.
• Successive passes are cut more deeply, in a progression determined obscurely.

If these gaps could be filled, the resulting code would be much tighter and more comprehensible.
With these gaps in my understanding, the resulting code (attached) had to carry forward a little of the obscurity & verbosity of the original. Still, the revised version is about one third the size of the PP-generated code. It is more accurate than the PP-generated code, because some pass-to-pass changes in the PP-generated code should be monotonic, but aren't, presumably because of rounding errors in reducing the floating-point calculations to 4 decimal places for PP's ASCII output. The recoded version is in some ways easily modified: to change the location of the second thread from (1,1) to (1,2), and to add a new thread at (3,2), one would need only to change its lines 62 & 63 from

#<_XCenter> = 1  #<_YCenter> = 1         ; second thread
M98 P1000                                ; ..

to

#<_XCenter> = 1  #<_YCenter> = 2         ; second thread
M98 P1000                                ; ..
#<_XCenter> = 3  #<_YCenter> = 2         ; third thread
M98 P1000                                ; ..

One potential objection to this sort of gCode is that by moving the trigonometric calculations from preparation time to machining time, the code will take so much longer to run that the machine operations will be slowed or even compromised. This objection is almost surely unrealistic, given the speed of typical controllers. For example,

#101 = 0
o1000 repeat [100000]
#101 = [#101 + 0.01]
#102 = [cos[#101]]
o1000 endrepeat

runs on my controller in about 7 seconds.
A more serious potential objection is that PathPilot might be used to prepare gCode for controllers in which modern gCode is not supported, or that one might want to submit code prepared by PP to a less capable simulator (for example, to the linguistically-challenged simulator in the GWizard editor).

Similar Threads:

• madCAM GCode and Tormach PCNC1100 PathPilot not working "out of the box"
• Tormach 1100 S3 using Tormach 1.5" face mill....
• Newbie Q: (Mach/Gcode/Tormach?) display vars?
• I have a problem with my gcode or my conversion to gcode , everything is tiny?

[JW_55Degrees]

The title of this thread might be misleading. In software systems the term "deprecated" usually means something like "you are advised not to use the feature as it has been replaced by something better and the earlier implementation will eventually be withdrawn". This is not the case with advanced G-code features.

I read the advice in the PCNC mill manuals as advice to new users that they will not generally need to use parametric code, nor to learn to read it, as Conversational and CAM does not generally produce it. The approach taken is to encourage people to learn to read simple G-code as it helps understand what the machine is doing, for example, with clear planes but it will generally be best to generate code using CAM or Conversational screens and to go back to the original "model" if improvements are needed in the machining process. This has always been easy with CAM and is now very simple using the Job Assignment feature of Conversational.

JW

[Fenichel]

Thanks for your response.

When you mentioned

the Job Assignment feature of Conversational

were you referring only to PP's ability to save/append conversational code to a file, or is there some other feature, one that I've obviously overlooked?

I don't agree that deprecated is consistently used in programming manuals to hint at better options coming along. For example, Borland (now Embarcadero) has deprecated features that are platform-specific, whether or not there exist, or ever will exist, platform-independent alternatives. They have also, for another example, deprecated features of Pascal (notably, procedures local to other procedures) that have no equivalent in C, presumably because they want to claim that they are supporting Pascal even after they move to a single compiler with an optional front end to turn a subset of Pascal into C. There are other examples.

That is all a digression. I still think that the advice given in Tormach's manuals is bad advice. The features they advise against are

• numerical parameters
• named parameters
• subroutines & macros
• common control structures (if/endif, repeat/endrepeat, etc.)

Of these, all but the first make gCode easier to read and modify, not harder. Aren't the examples I gave in my OP convincing? Which version of the thread-milling program would you rather be assigned to debug? If you ran the Conversational Thread-Milling wizard just in order to see the code and learn the strategy of thread milling from expert machinists, which would you rather study?

As it happens, I did run the Conversational Thread-Milling wizard just to see the code; I don't have any immediate need for thread milling, and indeed I don't own a thread mill. I do have a current need to mill a pocket, so yesterday I started looking at the Conversational Pocket wizard. It is even more unnecessarily verbose than the Thread-Milling wizard. It used over 3000 lines of gCode to produced a single circular pocket; the code makes some arbitrary assumptions (e.g., that the desired finish WOC is 0.001"), and of course modifying it in any way -- or just using it to try to understand how circular pockets are milled -- would require reverse engineering. I've done the reverse engineering, and now I have a 119-line file (attached) that does the job, and that could be adapted to do multiple pockets (add two lines each), different feeds and speeds (one line each), different pocket dimensions (one line each), and so on.

I believe that PathPilot's conversational Wizards should generate code that is readable, not only in detail (yes, anyone can see that

G01 X 0.645 Y 5.3

moves the tool horizontally to (0.645, 5.3)), but strategically. For a trivial example, the reader should be able to understand why the DOC used in the code may be different from the one specified in the wizard's UI.

[saabaero]

Fenichel,

I for one have wished numerous times that I had the capability in Path Pilot to do conditional programming. I have to wonder which was more work for Tormach... taking that capability out or leaving it in. If it was more work to take it out why in hell wouldn't Tormach allow the user to decide for himself how he wants to create machine code.

I agree with you that most code generated by the conversational is extremely difficult to modify and understand. There were times that I was forced to go back in the conversational to make a small change. An example is one time I manually inserted a tool change after the conversational code was generated to insure I had a blank location on the turret to avoid a crash with a chuck when using a gang tool. Later I wanted to change the peck depth of the drill so when I went back to the conversational to make that change the code that was reposted did not contain that tool change (and I forgot about it being there) so it caused my machine to crash.

It is very common for me to want to make small tweaks to my programs as I run them to improve machining efficiency. I find having to go back into the conversational to do that very cumbersome. It is so much easier to change such things directly in the machine code.

If there are any others out there that feel the same we should band together and petition Tormach to provide that capability in PathPilot.

[Fenichel]

It's good to hear from a kindred spirit.

My latest thought is that the whole notion of Conversational gCode programming is misguided. Changing the parameters inside the DROs on one of the conversational pages in PP is not easier than changing the assignments to well-named and well-annotated parameters in gCode.

Instead of having Conversational options in PathPilot, Tormach should curate (providing some, accepting others from users) a library of gCode utilities covering the same (and new) functions. In each such utility, the computation now done in PP before generating gCode would all be done in the gCode itself. My round-pocket utility shows examples of this, as the parameters of the plunge and the spiral are computed on the fly, in response to the user-specified assignments at the beginning.

Here is a thought experiment, only slightly farfetched: Create gCode to cut a line of 6 circular pockets, with centers at (0,0), (1,0), (2,0), ..., (8,0), with the nth pocket 0.1*n deep and n/8 in diameter. That would be a PITA to generate with PP Conversational programming, and the resulting gCode would run to over 20000 lines. I could tweak my existing program to do that with about a dozen new lines of code.

I will be working on creating more specimen utilities for such a collection, but I'll need some help. As noted in my thread-milling exercise, the code generated by Path Pilot makes use of some knowledge I don't have; I've had to throw in a number of arbitrary-looking constants. I'll try to make a list of the places where arbitrary constants are utilized in creating the PP code, and members of this board may be able to fill some of the gaps.

For that matter, I might be able to get some help from Tormach itself. As noted above, I believe that the whole Conversational approach was Tormach's error, but in general, as shown by their videos, they are serious about teaching; they are not willing to sell iron and forget the customer.

[saabaero]

Fenichel,

I believe Tormach's thinking on the subject of G code programming is synonymous to saying that there is no value to parametric CAD modeling because it complicates a design and makes it harder for others to understand.

If I understand correctly, what you are contemplating accomplishing is to build programming logic into the code generated by conversational routines so that the code generated is shorter and less complicated. That sounds like a great idea and an positive expansion on the idea of conversational programming.

I'm not sure how many other people would make use of enhanced G code programming functions but it is good to know that there is at least two of us!

[Fenichel]

If I understand correctly, what you are contemplating accomplishing is to build programming logic into the code generated by conversational routines so that the code generated is shorter and less complicated.

That was my original idea, but my thinking has advanced. I didn't express myself clearly in my previous post.

When Tormach provided the Conversational code generators in Path Pilot, it was addressing the needs of people who have no CAD program, or who want to perform a simple-seeming machining task without resorting to the overhead of going through CAD. PathPilot's conversation-generated code performs to specifications, but it is essentially unmodifiable, so variations not contemplated by Tormach are not achievable. Presumably to reduce the clutter of the conversational tabs, some constants describing the code to be generated are not user-modifiable or even user-visible (e.g., the finishing WOC in circular pockets, fixed in PathPilot's wizard at 0.001. Would you prefer a different value? Too bad for you).

The need that Tormach was addressing is real, but I don't believe that the Conversational route is the way to go. What I am doing for myself is building up a library of generic gCode programs:

• mill out one or more circular pockets, not necessarily identical, with specified centers (done)
• mill one or more external threads, not necessarily identical, on pre-existing bosses (done)
• shave a specified amount from a rectangular surface, starting at the current Z value
• etc.

When I need to perform one of those not-quite-CAD tasks, I'll

• open the pertinent gCode program,
• change some assignments (possibly doing no more than I could have done by filling in PP DROs, but possibly adding control structures, so as (for example) to machine features in some pattern), and
• load and run that code.

Instead of maintaining the conversational features of PathPilot, I believe Tormach should simply distribute a library of such generic routines. The library might have an inner shelf (code vetted by Tormach) and an outer shelf (code submitted by users, not necessarily safe). Forum members (and other users) could build a community of shared problem-solving.

[kstrauss]

There is really no reason that it must be either/or. The code that is generated by the conversational screens could include explicit constants for stuff like WoC for finishing but make no provision for setting the variables conversationally in order to reduce UI clutter. For the user who is clever enough to understand, the constants could be edited manually.

BTW, make it at least 3 users who use conditionals, subroutines and other "advanced" features. I'm in Ontario about 60 miles east of Toronto. Where in Canada are you?

[Fenichel]

I'm in West Vancouver. Do you ever get out this way?

Incidentally, there's another reason to move toward readable short utilities in place of massive, unreadable code produced by presumed experts. It's the usual reason for favoring open-source software. A case in point: the PP-generated code for circular pockets goes through multiple passes of

• (a) at the center, get the tool DOC deeper
• (b) spiral out to near the full diameter

It does (a) by using the endmill like a drill, simulating a G83 cycle (although doing it all with explicit G00s & G01s). Even with a sharp new endmill in 6061, one can hear the mill suffering. In the latest version of my utility, I achieve (a) by ramping down at 3°. That's not rocket science, and I don't claim to be much of a machinist. All this suggests is that when the strategy of a gCode (or other) program is known only to the one or two people who wrote it, some howlers can be missed.

[DLawrence]

You have expressed about what I have been thnking.....Geez who would want 20,000 lines of hard or impossible to modify code when it can be done in 20

When Tormach provided the Conversational code generators in Path Pilot, it was addressing the needs of people who have no CAD program, or who want to perform a simple-seeming machining task without resorting to the overhead of going through CAD. PathPilot's conversation-generated code performs to specifications, but it is essentially unmodifiable, ........................
The library might have an inner shelf (code vetted by Tormach) and an outer shelf (code submitted by users, not necessarily safe). Forum members (and other users) could build a community of shared problem-solving.

I would pay money for a better way to go than than the stock PP conversational and a lot of others would too. Hope you can keep the vision and the fire in this direction...

Thank you very much for your much needed "rant" !

Dave Lawrence

[Fenichel]

I'm grateful for the encouragement that I've received here.

I have started a Web page with links to gCode utilities. As of now, the only utilities linked there are my own, but I'll be happy to link to routines by anybody else. As I tweak, update, and add to the library, I will keep that Web page up to date, but I won't necessarily take the time to say anything here.

[daniellyall]

Just learn Macro-B

[Fenichel]

Tormach's version of gCode has named variables, which make all the difference. Macro B seems to be a subset of what's available in PP gCode.

[daniellyall]

Macro - B/macro subroutines has been around since the dawn of cnc there a few examples online and in the linux forum Linux just has there own version fanuc, haas and all the big boys use them

[jeffrey001]

It's good to hear from a kindred spirit.

My latest thought is that the whole notion of Conversational gCode programming is misguided. Changing the parameters inside the DROs on one of the conversational pages in PP is not easier than changing the assignments to well-named and well-annotated parameters in gCode.

Instead of having Conversational options in PathPilot, Tormach should curate (providing some, accepting others from users) a library of gCode utilities covering the same (and new) functions. In each such utility, the computation now done in PP before generating gCode would all be done in the gCode itself. My round-pocket utility shows examples of this, as the parameters of the plunge and the spiral are computed on the fly, in response to the user-specified assignments at the beginning.

Here is a thought experiment, only slightly farfetched: Create gCode to cut a line of 6 circular pockets, with centers at (0,0), (1,0), (2,0), ..., (8,0), with the nth pocket 0.1*n deep and n/8 in diameter. That would be a PITA to generate with PP Conversational programming, and the resulting gCode would run to over 20000 lines. I could tweak my existing program to do that with about a dozen new lines of code.

I will be working on creating more specimen utilities for such a collection, but I'll need some help. As noted in my thread-milling exercise, the code generated by Path Pilot makes use of some knowledge I don't have; I've had to throw in a number of arbitrary-looking constants. I'll try to make a list of the places where arbitrary constants are utilized in creating the PP code, and members of this board may be able to fill some of the gaps.

For that matter, I might be able to get some help from Tormach itself. As noted above, I believe that the whole Conversational approach was Tormach's error, but in general, as shown by their videos, they are serious about teaching; they are not willing to sell iron and forget the customer.

Could you create your program for only 1 pocket and copy paste the lines of code and inserting a G52 between each pocket?

Jeff

[DLawrence]

Another area to move into with this work is the development of Tormach vertical lathe .....Every tormach owner that doesnt have a Rapidturn or freestanding CNC lathe could make use of it.

Fenichel,You are surely on the right track

Thanks
Dave Lawrence

[kstrauss]

It seems to me that the right approach to conversational programming is a mix between Fenichel's approach and Tormach's. That is, have the conversational UI generate a few lines of Gcode that defines variables based on what is input via the UI. These would then invoke the actual cutting by loading named subroutines from disk. That way users could define their own "better" implementations. Plus, modifying the original parameters would be easy -- just parse the parameter definitions and put the values back into the UI screen displays.

[Fenichel]

@jeffrey001

Could you create your program for only 1 pocket and copy paste the lines of code and inserting a G52 between each pocket?

Once the guts of the code for one pocket is all packaged in a subroutine, then what you propose has essentially been done, but no copying & pasting is necessary. My current pocket utility has default pocket dimensions of 0.8" deep and 0.8" OD. The lines to cut one such pocket at (2.5,0.75) are

#<_XCenter> = 2.5 #<_YCenter> = 0.75 ; pocket #1
M98 P100                             ; ..

To cut a second, identical pocket at (1,1), I think [I say "I think" because I've never used G52] one could change those lines to

#<_XCenter> = 2.5 #<_YCenter> = 0.75 ; pocket #1
M98 P100                             ; ..
G52 X -1.5 Y 0.25                    ; pocket #2
M98 P100                             ; ..

but I'd prefer to write

#<_XCenter> = 2.5 #<_YCenter> = 0.75 ; pocket #1
M98 P100                             ; ..
#<_XCenter> = 1 #<_YCenter> = 1      ; pocket #2
M98 P100                             ; ..

Moreover, G52 doesn't take one very far. To get the second pocket to have an OD of 1.2", the code would be changed to

#<_XCenter> = 2.5 #<_YCenter> = 0.75 ; pocket #1
M98 P100                             ; ..
#<_XCenter> = 1 #<_YCenter> = 1      ; pocket #2
#<_Diameter> = 1.2                   ; ..
M98 P100                             ; ..

@kstrauss

It seems to me that the right approach to conversational programming is a mix between Fenichel's approach and Tormach's. That is, have the conversational UI generate a few lines of Gcode that defines variables based on what is input via the UI. These would then invoke the actual cutting by loading named subroutines from disk.

Indeed. I'm proceeding the way I am only because it doesn't require any immediate buy-in from Tormach.

[kstrauss]

The beauty of open source (like PP) is that buy-in isn't required. Modify the code and make it available. What is really needed is a sophisticated merge utility that intelligently combines your changes with the base code from Tormach and puts everything into the right directories.

[DLawrence]

Fenichel , you are really taking things where they need to go. Currently available conversational is like buying a diamond, and getting mixed in with your diamond a whole big truckload of dirt, stones and assorted trash. Bob Warfields wizzards are just as bad..... My hats off to you

Dave Lawrence