Reply with QuoteAlso, because of lead-in strategies, even Fusion CC code has limited value in terms of using different diameter tools, because the new tool diameter has to be near the old, or else PP will cry error because the lead-in puts the cutter too close.
Re: Dumb Thread mill question
I don't know if you have Fusion, but it can create cutter comp thread milling code. I tried setting the tool diameter to zero in PP, to use that as a base and then adding the G41/G42, but the way PP does it will not work with G41/G42. You would have to re-write the thread milling program.Originally Posted by kstrauss
Re: Dumb Thread mill question
Also, because of lead-in strategies, even Fusion CC code has limited value in terms of using different diameter tools, because the new tool diameter has to be near the old, or else PP will cry error because the lead-in puts the cutter too close.
Re: Dumb Thread mill question
Obviously the thread mill must be smaller than the minor diameter of an internal thread. For an external thread the diameter should have no special restrictions. However I am mainly interested in diametrical changes of a few thou.
Re: Dumb Thread mill question
If you use parametric programming, the diameter of the thread mill is a single parameter. You can edit that in the program (eg from 5.73 to 5.74 mm) before the next run. This is just so easy with Mach3.
Cheers
Roger
Re: Dumb Thread mill question
I wrote my own macro for thread milling. Reads the diameter from the tool table. Allows me to make adjustments without going back to CAM.
Easy to do in Mach3.
Re: Dumb Thread mill question
Are you willing to post the code? Have you modified things for PP?
Re: Dumb Thread mill question
Who, me?
See attached. Use at your OWN risk! Generic, should work on most machines.
Note that this is a single pass thread milling. You can modify this to take 2 or three passes by reducing just the thread mill cutter radius in #21 to take, say, 65% in the 1st pass, 90% in the 2nd pass, and 100% in the third pass. This is a good idea for steel. You can repeat the 100% pass for a fine polish.
Cheers
Roger
Re: Dumb Thread mill question
Nice code!
But I'm guessing you've only used it with #2 = 0.0? Otherwise I think it would have malfunctioned when it hit y0 on the "gentle engagement" line, as well as in the sub.
Did you know you can do a full turn in only 1 line by replacing your r value with a j or i value? By combining arc center vectors with incremental positioning you can eliminate the sub and replace all this:
g3 x[#1+#21] y0 r[#21/2] % gentle engagement
m98 p100 L#20
g0 x#1 y#2
g0 z#11
m5
m30
o100
#12=[#12+#6/2]
g3 x[#1-#21] y0 z#12 r[#21/2]
#12=[#12+#6/2]
g3 x[#1+#21] y0 z#12 r[#21/2]
m99
with just this:
G91 G03 X#21 R[#21/2] %gentle engagement
I-[#21] Z#6 L#20
G90 g0 x#1 y#2
g0 z#11
m5
m30
No need to keep track of Z on the way up!
ETA: Actually I'm seeing that you also messed up your R values in the subroutine - they should just be #21, not [#21/2]. Have you ever actually made a thread with this code?
Re: Dumb Thread mill question
Oh Hell!
That's what comes of writing a sample program in haste without checking it on the machine!
You are entirely right of course. I have attached a revised version.
The fun now lies in seeing how many more bugs you can find in it!
Oh bother. I have uploaded two copies of the amended file, but the first copy (uploaded) has a bug in it. If the copy you collect has a 'y0' in any g3 line, it's the wrong one. I will try to delete the wrong one, but so far I cannot see how to do that.
Now, in addition you raised two interesting points.
Use of IJ mode instead of R mode - yes, I know this makes for a neat way of doing the full revolution in one go. For some historical reasons I have got into the habit of explicitly spelling out the rotation in radius mode - partly because radius mode does not fall prey to the 'incorrect end point' error one can get with IJ mode. As we have gigabyte memories and GigaHertz processors these days, the extra few characters of code don't worry me.
Use of L repeat Yes, this too is sometimes possible, but I am not sure it will work here, at least in Mach3. The line
I-[#21] z#6 L#20 was rejected.
Changing it to I[0-#20] let the program be accepted by Mach3, but that only gave 1 turn of thread.
The problem here is that Mach3 does not accept an L parameter for a G3 instruction: it gets ignored. Other CNC machines may accept it. I don't think Fanuc does.
More later maybe - dinner time.
Cheers
Roger
Re: Dumb Thread mill question
OK, dinner over. Roast dinner - I had to carve.
Programming style is the third point I wanted to raise. It is possible to write:
g0 x#1 y#2 z#3
g0 x#4 y#2 z#3
g0 x#4 y#5
It is equally possible to write (and get the same results)
g0
x#1 y#2 z#3
x#4
y#5
But consider the poor programmer when he has to come back to this code a month later. Which style is easier to understand?
I find the first style, with most axes spelt out, to be far more readable. As I mentioned above, memory space and processor power are simply not considerations today, so extreme code compaction is no longer needed.
My 2c.
Cheers
Roger
+1
Re: Dumb Thread mill question
Sure. When I get home tonight. I have not modified for PP since it uses a different program language for macros. Mach3 uses VB for macros and I have written numerous custom macros over they years. Converting them to PP is what has kept me from switching over.
Re: Dumb Thread mill question
Thanks for the response(s) Roger. I'll acknowledge that much of how we program is a matter of style and habit. I may program the way I do because I'm used to working with CAD/CAM generated code, so my hand-written code ends up looking like it was spit out by a post-processor, and that's the way I like it!
It's interesting the subtle differences created by controls that all nominally owe their existence to fanuc. The L word limitation that we're experiencing - is that/has that always been a limitation of Mach3? It's been years since I wrote macros for a Tormach, but I know I would have found that frustratingly limiting, given that you're also only allowed to nest subroutines 3 layers deep.
Would you care to address the use of absolute vs. incremental locations? Surely incremental would add some flexibility and save you some typing. Or if not incremental, then perhaps the use of something like G52 to set a temporary coordinate system (does mach3 do G52?). Looking forward to your observations.
Re: Dumb Thread mill question
For me the second version wins hands down. Without ever having previously seen the code I can very quickly see what's happening. I'd probably just prefix g0 to each line for clarity but otherwise there's no duplication of values, so no need to compare each line with the previous to find what might have changed.
If you want to improve readability you should consider using named parameters rather than numbered parameters (does Mach3 support this?). If you would have used a readable name instead of #21 in the first example then its use would have been more obvious and the "poor programmer" would also have a much easier job interpreting the code.
Step
Re: Dumb Thread mill question
Hi all
First of all, I should explain that Mach3, Mach4, UCCNC, LinuxCNC and a few other modern implementations all support the NIST Standard for g-code. By doing so, they allow interchange of programs. Older machine makers often have their own unique custom languages, and once you write for one of them you are locked in. This is like the old battle over PC standards: the custom designs all lost out to the Open Standard. Well, I guess that is a matter of philosophy: Open or Proprietary.
NIST does not include named variables, nor does it allow the use of L-repeats on the G2/G3 commands. Yes, NIST fully supports workspace offsets in the G52 range. So that deals with that for all NIST-compatible controllers. It does allow the use of macro commands but (perhaps wisely) leaves the details to the implementation.
The idea that a whole lot of controllers owe their existence to Fanuc is a bit of a stretch - far too much imho. I am sure Fanuc contributed to the NIST Standard, but it is to the NIST Standard and not to Fanuc that modern controllers link. I dare say Fanuc see it differently. Please note that if you want to follow Fanuc, you need to decide which version you follow: the code run on some Fanuc controllers is not compatible with other Fanuc controllers.
The idea that you are only allowed to nest subroutines to 3 levels is wrong. There may have been a limitation in early versions of Mach2, but there is no limitation in the Standard or current versions of the various controllers (afaik). That said, there is a known bug in Mach3 which can create a problem for one or two complex commands if the nesting is very deep. I would very often be nesting to 3 or 4 levels in Mach3, with zero problems.
Absolute vs incremental: I use both. If I am machining a batch of components, arranged in a grid, than I find absolute to be much safer. With incremental there is always some uncertainty as to exactly where I am at any one stage. Perhaps that is a limitation in my brain? But by staying in absolute addressing, with explicit offsets, I can see exactly what I am doing. Any savings in typing are microscopic compared to the clarity of understanding.
That said, I do use workspace offsets and workspace rotations some of the time, when they are convenient. They can be useful, but they are not mandatory. There are some places where they can add clarity to the program.
Step (Turbo) - I note that you started saying you prefer the second (cryptic) version, but than added that you would head back towards the 1st version by adding a G0 at the start of each line for clarity. Well, exactly. Sometimes I will repeat an unchanged variable for clarity, sometimes I don't because it all seems fairly clear (to me) already. My example was pushed a bit far to the 1st extreme.
Would I use named variables if the NIST Standard was updated to support them? Too right! But for the moment I list and define all my variables at the start of the program, for clarity. That is the single place where I need to change the value of a variable, rather than having to search all the way through the program. If I use an external data file read in at the start, I can share those data values between several programs needed to fully machine one thing. That works very well.
Parametric vs CAD/CAM: they are two different worlds. An engineer working on something 'mechanical', especially someone used to programming, is likely to go parametric. It just makes sense. But someone carving patterns of faces or scenes in 2D has little choice but to use a CAM program to convert the STL to XYZ values - millions of them.
</sermon>
Cheers
Roger
Re: Dumb Thread mill question
Interesting insights Roger. In my neck of the woods, it's taken more or less for granted that "in the beginning there was fanuc...". I never really thought to question this. Which isn't to say I believe it to be better - for example I much prefer working with the canned cycles and coding conventions and programming features of Okuma lathes to that of Fanuc, I just assumed that what I'd been taught about Fanuc being the "original" was true. I'll have to do more research.
I got the 3 levels of nesting limitation from the manual that came with my Tormach when I bought it in 2009 or so. As I recall there was warning that seemed to indicate not that the limit was enforced, but rather that memory/data integrity could be an issue.
I would dare say that in practical terms CAD/CAM and conversational programming makes standardization of G-code nearly irrelevant. There are few jobs for which hand-writing G-code is a more suitable solution than either of those options, and fewer still for which it's important that the hand-written code run unmodified on a number of different models of machine. The number of professionals who can competently produce macros that are useful for working on part families, common repetitive features, or mathematically complex coordinate calcs is vanishingly small. I think there's a lot more money for someone who's capable of this type of programming in working on actual software, design, or analysis than in making chips. I just happen to be one of the weirdos who doesn't mind taking a pay cut to make chips, and I have more fun producing a macro to accurately mill a tapered thread than jamming a tap in it.
Given your programming style, I'm wondering how you facilitate re-use of the macros you produce. By initializing your low numbered variables at the head of your file, don't you preclude yourself from actually passing parameters in from an external program? Forgive me if I just don't recall how macros work in Mach anymore, but I thought variables #1 through #26 were passed in from the calling program, such as:
G65 P1234 A5.6
.
.
.
O1234
G0 G54 G91 Z#1 %this is a silly macro that moves the Z axis according to the A parameter it is supplied with. the Z axis will move up 5.6 inches as per the macro call shown above.
M99
Re: Dumb Thread mill question
I agree. I found it difficult to read, especially using cryptic numbered parameters.
Why the But? You can do just the same with named parameters, except the code is much easier to read and less prone to coding errors:
G Code Overview
Also, as the OP asked "Have you modified things for PP?" I'm assuming his primary interest (like mine) is not portable g-code.
By the way, personally speaking as "an engineer working on something 'mechanical', especially someone used to programming" I go CAD/CAM whenever possible (or conversational for turning).
Step
Re: Dumb Thread mill question
Hi Flick
Well, the history of CNC machines and programming goes a LONG way back before Fanuc ever existed. There were/are a large number of other control languages around, and new ones are still being proposed. This is very similar to the situation in the computer world with languages. Some of that is driven by commercial attempts at lock-in, while other ones seem to be driven by an ego wanting to be the next Zuckerberg. The Tower of Babel reigns! If you want to read more about it, you could do worse than to start with Wikipedia.
The limit of 3 layers of nesting is entirely an artifact of poor design of the actual controller program. It just means that the people who wrote the early version(s) did not allow enough stack space in their software. Inadequate memory space in the program rather than in the PC. OK, early machines doid not have much memory anyhow.
in practical terms CAD/CAM and conversational programming makes standardization of G-code nearly irrelevant. There are few jobs for which hand-writing G-code is a more suitable solution
I have to disagree quite strongly.
To be sure, if you are working for Ford or GE etc you might have access to a powerful CAD/CAM combo and not need to think. But that sort of SW can cost $100k per seat. Pity the poor hobbyist or even the owner of a small job shop! Other CAD/CAM combos which are popular at the 'small owner' level are mainly 2.5D only. I don't believe Fusion can handle continuous 4-axis work yet.
I make a number of different things, including ultra-light winter mountaineering canister stoves. I looked at modelling the parts on 3D parametric CAD (I have several), but it was faster to sketch them in 2D and write the g-code. As I was making the parts in batches of 8 - 10 at a time, I could integrate the machining across the stack of 10 in a way I doubt CAM could ever achieve. Tool changes were highly optimised. That was because I understood what I was doing. CAM can never do that. But I am sure there are other cases where CAD/CAM is quite suitable.
Your concerns about low-number variables do not seem to apply to NIST g-code and Mach, and I don't understand them. They may apply to old versions of other languages? I don't actually create 'macros' as you call them, although this may be a terminology problem. In Mach a 'macro' is called by an M-code, and is often used for control of external devices such as spindle, misting, safety sensing, etc. Templates for reuse might be a better description. Does Fanuc use the word 'macro' for a subroutine?
I did refer to reading in a data file at the start of a program - that data file actually contains a huge list of the parameters (and their definitions of course), but rarely includes any movement instructions. But there is no restriction on the use of low-numbered parameters like #1 - #26. Use them as you will. Mach3 allows up to about 32,000 parameters, Typically I will reserve parameters #1 - #19 for use as very local variables within a subroutine, while parameters with bigger numbers are more global in the program, but that is SOLELY a matter of MY programing style.
The example you give of a G65 instruction is not valid in Mach3: it is not implemented. The idea that a passed A parameter ends up as #1 does not apply at all. Some of the canned routines do take parameters passed by certain letters of the alphabet, but note that a simple instruction like
g0 x#1
falls into this class as well. Equally, the subroutine call using an m-code instruction
m98 p100 L5
is passing parameters across using the letters P and L. In both cases it is the Mach3 controller which is using those parameters for flow control.
Dear me - there seems to be a huge amount of false information out there about how modern NIST-compatible g-code works. Some of that false info dates back 20 - 30 years (or more), and some may be due to misleading comments from vendors like Fanuc and Siemans and so on. But I don't know. Equally, many claims about how you can't do X or Y in NIST g-code are more due to parroting and ignorance.
What I have seen is that while controllers like Fanuc are technically able to handle many more canned routines than, say, Mach3, those canned routines are rarely worth the bother unless you are trying to drive the CNC in a sort of manual mode from the control panel. Even then, they are so limited. Yes, you have a g-code to mill a round pocket - but its of no use if you want a different shape. And the output of the CAM programs I have seen are very often restricted to G0, G1 and a simple drill cycle. The CAM programs do not yet have enough intelligence to be able understand what they are machining. That often comes from having to start with an STL file of course, so they just creep across the STL triangles.
Cheers
Roger
Re: Dumb Thread mill question
Amusing thing. I just got an email from MECSoft, offering their latest and greatest SW. It offers
2D CAD
3D CAD
Artistic Design (Raster to Vector, Pictures to 3D geometry)
2 ½ Axis Mill Programming
3 Axis Mill Programming
Oh really? How terribly exciting. 2.5D mill programming... or even 3D. Oh my.
Meanwhile, Mach3 offers 6D continuous control: X, Y, Z, A, B, C. Unlike Fanuc, there is NO EXTRA COST for having all 6 axes.
Cheers
Roger
Re: Dumb Thread mill question
I very much understand the advantages of hand-writing g-code, and in our brief interaction you've easily convinced me that you can do everything you say can, because I can too, but that doesn't make hand programming the best choice for most people most of the time.
And that's entirely separate from the issue of whether standardization is important - if you're capable enough to understand both machining and programming to the point that you can significantly optimize your gcode without much effort, then you can also write excellent code for a variety of machines. I can understand the draw of standardization, but it seems to me there are enough advantageous non-standard features to various controls that it's very much worthwhile to learn and utilize them.
That's too bad, because it's a really attractive methodology. G65 is what fanuc terms "custom macro B". It's a specific feature emulated by many other controls, and is the more powerful version of their early and mostly defunct custom macro A. It seems that from what your describing, the way that "parameters are passed" between a program and a subroutine in Mach is to simply set global variables. This is Ok, I guess, but requires a tremendous amount of discipline on the part of the programmer, and leaves you open to the likelihood of stomping on the "namespace" of other subroutines if you happen to write a program that uses multiple subroutines that are all parameterized in such a way, or if such subroutines use each other. When you pass a parameter through G65, it becomes a truly "local" variable in the subroutine referred to by the P value - IE 26 shiny new words of memory are dynamically allocated for the use of that instance of that subroutine - no namespace issues. Also, once you've written a really nice, flexible custom macro, you can invoke it in a similar style to a canned cycle, albeit without the modality thereof. So while I can't write something like:
G0 G54 G90 X0. Y0.
G65 P1234 %threadmill first hole
G91 X1. L9 %threadmill remaining holes
But at least I can write something like:
G0 G54 G90 X0. Y0.
G65 P1234 A1.79 F.087 Z-1. D1 R.1 Q5 J.5001 %threadmill 3/4 NPT
X1.
G65 P1234 A1.79 F.087 Z-1. D1 R.1 Q5 J.5001 %next hole
X2.
etc.
And the code to call your macro looks almost like using standard canned cycle, is easier to remember because the letters all resemble uses that they have with other codes, and is a lot nicer to write (I think) than:
#101=1.79
#106=.087
#126=-1.
#104=1
etc
etc
etc
M98 P1234
Which is how I imagine you passing data from you main program to your subroutine. But to each their own, certainly, and forgive me if that doesn't actually resemble how "parameters" are "sent" in NIST g code.
