Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: rcaffin on November 10, 2011, 10:09:22 PM
-
I want to use cutter radius compensation.
M3M says that G10 L1 P1 R5 Z6 should set the tool table entry for tool diameter to 10 (and tool length compensation to 6) - although it is rather brief and hesitant about the radius bit.
However, I don't seem to be able to get the radius setting to do anything. The Z parameter works fine.
Would I be right in thinking that this radius/diameter feature has not yet been implemented in Mach3?
Or have I just not done the right thing yet?
Cheers
-
To use cutter radius compensation, you need to program using G41/G42. You can just enter the diameter in the tool table, there's no need to use G10 to do it.
-
To use cutter radius compensation, you need to program using G41/G42. You can just enter the diameter in the tool table, there's no need to use G10 to do it.
Oh yes, I know that.
But I would like to be able to specify the cutter diameter IN the program because I am cutting multiple units from one blank, and the separation of the units depends on the cutter diameter.
And, ... I may want to change the cutter diameter from 5 mm to 6 mm if the 5 mm cutter proves to be too weak (and breaks). What i don't want to have to do is manually adjust the layout because of the cutter diameter.
Cheers
-
You can specify the cutter radius along with G41/G42 by using the P word.
G41 P3 for a 6mm diameter cutter. This method doesn't use the vales in the tooltable.
-
You can specify the cutter radius along with G41/G42 by using the P word.
G41 P3 for a 6mm diameter cutter. This method doesn't use the vales in the tooltable.
Bingo! The instructions for G41 were not wildly clear either ... Thank you.
Just out of curiosity, what about G10 R5 though?
Cheers
-
I think the G10 calls you are tryng to use are for TURN applications.
(;-) TP
-
I think the G10 calls you are tryng to use are for TURN applications.
Well... M3M does discuss the use of tool diameter compensation, and defines G10 thus:
To set the offset values of a tool, program
G10 L1 P~ X~ Z~ A~, where the P number must evaluate to an integer in the range 0 to
255 - the tool number - Offsets of the tool specified by the P number are reset to the given.
The A number will reset the tool tip radius. Only those values for which an axis word is
included on the line will be reset. The Tool diameter cannot be set in this way.
What I do NOT understand is the distinction between the A number and the tool diameter, which is defined elsewhere (eg EMC I think) as being set by R, not A. Is M3M talking about a square end mill with a radius rather than sharp corners maybe? I don't know, and such a tip radius does not appear in the tool table last time I looked.
My bigger problem at this stage is that if I don't use G41 the outline appears in the window exactly as it should, but when I insert the G41 line the system goes slightly ghaywire on me. I get an arc back to some arbitrary position from every corner, followed by a straight line to the nect corner. BUT, these arcs are superimposed on the correct outline???? Umm.....
Clearly I am doing something wrong, but right now i can't see what. Any suggestions very gratefully received!
Cheers
-
Well, I spent the afternoon creating test programs.
It would seem that if i create a simple shape, largely convex, and go around it with G41 turned on, all is well and compensation works.
But a complex shape (something like a wobbly starfish for instance) sends Mach3 haywire. This may be assisted (I am not sure) by a slightly complex program with quite a depth of embedded subroutines. It can't cope with all the inside corners, and starts arcing all over the place. Well, I have some sympathy.
It also gets upset when I have lots of sharp inside corners in a complex prgram - it complains that the cutter can't do a sharp inside corner. It manages with a simple shape though. yes, I KNOW the corner will come out radiused - that is intentional.
Yes, I have tested my complex programs with the G41 line in and commented out, and that is the determining factor. Pity - it would have been useful. I have reverted to creating the tool path outside Mach3 and not using G41.
Next version maybe?
-
When things get more complex it can be easier to just use a program which provides offsetting from the profile.
Even the offsetting from programs will provide some strange results depending on what the programs decide is the proper thing to do for
a "foot that dosen't fit the shoe". In manny cases it just plain poor design to begin with.
I don't hand code a lot but a quick look at requirements for G41/ G42 to work right ( Smid's book on programming ) will provide insight into limitations.
RICH
-
From what I understand, G41/G42 doesn't work well with subs. And it really requires inside corners to have a radius larger than the tool.
When I read tool tip radius, I think of turning tools, as Terry said.
-
G10 L1 P~ X~ Z~ A~, where the P number must evaluate to an integer in the range 0 to
255 - the tool number - Offsets of the tool specified by the P number are reset to the given.
The A number will reset the tool tip radius. Only those values for which an axis word is
included on the line will be reset. The Tool diameter cannot be set in this way.
First the axis involved ARE lathe axis XZ NOW read the last line of the paragragh above(;-)
"The Tool diameter cannot be set in this way."
A is the tip radius on a lathe tool bit.
Use of the G10 is a standard way of setting the fixture offsets Via Gcode only you use G10 L2.
IF you want to be able to set tool table Values you need to use a Mcode and use parmeters to set the values
M1999 P1 Q2.000 R.250
That could be used to set the Tooltable values to Tool#1 Tlength 2.000 and radius .250
(;-) TP
-
Hi all
Thanks for words of wisdom. Appreciated.
It does seem that the text in M3M is a trifle obscure at this stage. It may well be that it needs a little editing to clarify what applies to a mill and what applies to a lathe. I guess I was hoping for a little too much :-)
Yes, if I could find a copy of one of Smid's book I would read it with great enthusiasm. Can't find any around here though.
It just seems to me that if LazyCam and CamBam can do it (for example), then it should be possible for Mach3 to do it. Mind you, some CAD programs attempt it and get bits of it wrong. I have to manually correct embedded arcs for instance in one of my most commonly used CAD programs. So maybe it wouold be hazardous to include in Mach3 it at this stage! And, it is possible to describe outlines which cannot be handled with a cutter of X mm diameter - so what then?
OK, back to the shop.
Cheers
-
I don't have a clue as to what you are trying to saying(;-) MACH3 is a machine controller, it is not CAD or CAM. It can ONLY do what it is told to do via the Gcode program.
What is it you think Mach3 should do that it already doesn't do?
"It just seems to me that if LazyCam and CamBam can do it (for example), then it should be possible for Mach3 to do it. Mind you, some CAD programs attempt it and get bits of it wrong. I have to manually correct embedded arcs for instance in one of my most commonly used CAD programs. So maybe it wouold be hazardous to include in Mach3 it at this stage! And, it is possible to describe outlines which cannot be handled with a cutter of X mm diameter - so what then?"
(;-) TP
-
I don't have a clue as to what you are trying to saying(;-) MACH3 is a machine controller, it is not CAD or CAM. It can ONLY do what it is told to do via the Gcode program.
What is it you think Mach3 should do that it already doesn't do?
OK, understood. Let me explain.
If I define a tool diameter for milling I can get Mach3 to compensate for that tool diameter when machining a simple square. For a SIMPLE convex object in fact. Example follows.
Let's assume a 50 mm square and an unknown diameter cutter for instance (yeah, metric, but that's where I am). First, I program the control point to go around the actual square (non-minimal coding for clarity):
g1 x0 y0
g1 x50 y0
g1 x50 y50
g1 x0 y50
g1 x0 y0
Now, with any realistic physical cutter this code by itself will produce a square which is undersize. However, if I open up the tool table and put, say, 10 mm into tool 1 diameter, and load a 10 mm cutter, and prefix that code with
G0 x-20 y-20 % move to outside the square to allow a lead in - essential for g41 to work
G41 D1 % turn on cutter compensation
and then run that code, I will get a square cut exactly to size. Now let's assume i break that cutter, and only have an 8 mm cutter left over. I load it, change the Tool 1 diameter in the tool table to 8 mm and rerun the code. Behold: another perfect 50 m square.
What this means is that Mach3 can right now compensate for tool diameter when machining a simple convex outline. But it can't handle a complex and sometimes concave shape. OK. But many CAD/CAM programs can handle complex outlines and generate correct tool paths. What that says to me is that the code in Mach3 which handles cutter diameter compensation is but a limited and incomplete copy of the CAD/CAM programs. LazyCAM can handle this in most cases.
Where this becomes a serious problem is when the shape I am cutting slowly gets more complex, and the program gets more complex with subroutines. I can rely on Mach3 to correctlly handle simple shapes in a 'flat' program, but at some degree of shape or program complexity it will fail, and I don't know when that will be! That uncertainty is dangerous.
What should Mach3 do?
Well, we have several possibilities here.
1) Attempt NO cutter diameter compensation at all (rather than an unreliable version)
2) Upgrade the cutter compensation code to handle ALL cases (this is possible but may be difficult)
3) Do the best it can but alert the user at load time when the shape is too complex for it to handle correctly.
4) Ban the use of subroutines when G41 is active
Possibility 1) is going backwards.
Possibility 2) is possible (eg lazyCAM) but requires a lot of programming to bring it up to CAD/CAM SW performance. $$ implications.
Possibility 3) sounds very nice but I am not sure whether it is either theoretically possible or reliable enough. There are huge complexities.
Possibility 4) might work (I am not sure), but it would be extremely inhibiting and a serious backwards step. I write very parametric programs using lots of subroutines.
Cheers
-
(;-) Mach can follow ANY contour inside or outside with tool comp as long as the radius of the cutter is smaller than the smallest radius it has to follow. IF you use a cutter that is LARGER than the smallest arc then MACH will error out and NOT run the code AS IT SHOULD.
IF it ran the bad tool/code combination it would GOUGE the part and the results would be an incorrectly made part. AKA JUNK.
Now that does require you to be able to program it correctly.
(;-) TP
-
(;-) Mach can follow ANY contour inside or outside with tool comp as long as the radius of the cutter is smaller than the smallest radius it has to follow. IF you use a cutter that is LARGER than the smallest arc then MACH will error out and NOT run the code AS IT SHOULD.
IF it ran the bad tool/code combination it would GOUGE the part and the results would be an incorrectly made part. AKA JUNK.
Now that does require you to be able to program it correctly.
Actually, not quite correct, on either point, and I now suspect that the problem lies not with the complexity of the shape but with the use of subroutines. As Ger21 said "From what I understand, G41/G42 doesn't work well with subs." That is a SW fault, pure and simple.
But I had better explain about the 'problem' of convex corners. Suppose the part I am making does have a convex corner. I do not want that corner to be a sharp point: that would produce stress concentrations leading to part failure under load. That's bad design. Instead, I want to filet the internal corner. Suppose I decide to use a 4 mm radius filet. I can get Mach3 to produce that filet by using an 8 mm cutter (radius=4 mm) and programming the outline without the filets. Yes, I tell Mach3 to go to the corner, but it does not: it stops short so there is no gouging and heads off on the next segment. It correctly creates a 4 mm radius filet just like that. I think that is wonderful. And Mach3 does not error out: It accepts the instructions and correctly executes them. No junk at all.
But I tend to program with subroutines for a number of reasons. Laying out several identical parts on one sheet, with some of them rotated to fit in optimally, is one reason. When I start to use subs, G41 fails. I would show pictures of the tool paths if this forum could handle images ... Is this a valid form of programming? Well, I think so, and I have been writing software at all levels for the last 50 years.
Cheers
-
(;-) Mach can follow ANY contour inside or outside with tool comp as long as the radius of the cutter is smaller than the smallest radius it has to follow.
Not this code:
G20 G40 G90
G91.1
S10000 M3
G0 Z0.25
G0 X18.0538 Y9.7864 Z0.25
G1 X18.0538 Y9.7864 Z0.0 F50
G42P0.125
G1 X18.3056 Y9.0 Z-0.1 F1
G1 X18.3056 Y6.9396 Z-0.1
G2 X18.1732 Y5.4917 Z-0.1 I-0.75 J-0.6614
G2 X17.5412 Y4.5622 Z-0.1 I-2.1176 J0.7604
G2 X17.3762 Y4.5 Z-0.1 I-0.1651 J0.1878
G1 X17.3762 Y3.75 Z-0.1
G3 X18.0364 Y3.9990 Z-0.1 I0.0 J1.0
G3 X19.0556 Y6.2520 Z-0.1 I-1.9809 J2.2530
G1 X19.0556 Y11.7480 Z-0.1
G3 X18.0364 Y14.10 Z-0.1 I-3.0 J0.0
G3 X17.3762 Y14.25 Z-0.1 I-0.6603 J-0.7510
G1 X17.3762 Y13.5 Z-0.1
G2 X17.5412 Y13.4378 Z-0.1 I0.0 J-0.25
G2 X18.1732 Y12.5083 Z-0.1 I-1.4856 J-1.6898
G2 X18.3056 Y11.0604 Z-0.1 I-0.6176 J-0.7865
G1 X18.3056 Y8.7147 Z-0.1
G40
G1 X18.0556 Y8.4647 Z0.0
G0 X18.0556 Y8.4647 Z0.25
M5
M30
It works for 99% of what I do, but it does have issues.
But there's nothing that can be done. Fixing bugs adds more, and delays the next version, which actually has comp that works in all situations.
-
Hi Ger
ERRRKKK!
I just pasted that in to see what it looked like. OUCH! Really wierd the way it took off at the top. Yeah, problems!
Ah well, when do we get the next release?
Cheers
-
When Brian stops fixing bugs in the current version.
-
Hi Ger
Do I interpret what you wrote as meaning that the subroutine problem has been fully fixed in V4?
Cheers
-
Brian posted a test version about 3 years ago, and he showed an example of it working in subs.
http://www.machsupport.com/forum/index.php/topic,9915.0.html
-
I'll have to admit the later versions seem to be terrible.
(;-) TP
-
Brian posted a test version about 3 years ago, and he showed an example of it working in subs.
http://www.machsupport.com/forum/index.php/topic,9915.0.html
If someone could explain to me how to upload an image to a posting without using an external web site, I could show what I am getting. It is not for internal holes but for external outliones. It's pretty wild!
Anyone?
Cheers
-
If your options are Post, Preview, and Spell Check, then click Preview, and choose Additional Option in the lower left corner below the text entry box. You can attach images there.
-
OK, thasnks. Trying ...
Top one is outline without G41
Bottom one is outline with G41 turned on - pretty wild?
Um ... ??
Cheers
-
Can you post the code for that?
-
Herewith.
Note that the full code actually is meant to create 4 units, while the pics just show 1 unit.
Also, there are some commented-out sections for drilling clamping holes.
If I have any errors in the code which are causing the problem, I would be grateful if anyone can educate me!
Cheers
-
I don't think you will ever get that to work with just setting the TC 1 TIME(;-). I believe you will need to rethink the use of the ToolComp.
First ,Nice program. I would never had tried Tool comp with it BUT if I did I would use TC a bit different. The TC should be used to move into a cut then when done Move OUT of TC. Then move to the next section and reapply it do the cut then Move out,etc,etc.
There are times when you jump through 3 subs with TC on and never made a cut. I don't think the TC in MACH3 will every be able to follow your Logic.
I am surprised that MACH3 can even follow the SUB logic that deep and not get lost.
(;-) TP
-
Hi TP
I don't think you will ever get that to work with just setting the TC 1 TIME(;-).
I do get simpler programs with much less SR nesting to run very nicely with TC on. There's some hope ...
First ,Nice program.
Thanks! SW programming background.
The TC should be used to move into a cut then when done Move OUT of TC. Then move to the next section and reapply it do the cut then Move out,etc,etc.
Oh yes, there is a lead-in move all right. I guess it is hard to see :-)
As for move out - that is done by a Z lift and end of program. The Z-lift is mandatory of course.
There are times when you jump through 3 subs with TC on and never made a cut. I don't think the TC in MACH3 will every be able to follow your Logic.
Dunno about that. Just because the program jumps down a few sub levels does not mean that position gets lost; equally the TC offset should not get lost. After all, sub level should not really have anything to do with position calculation.
I am surprised that MACH3 can even follow the SUB logic that deep and not get lost.
That should not be a problem, as I suggested above. And yes, Mach3 manages just nicely. I would expect it to handle far deeper nesting than that - virtually unlimited in fact. Sub level is just stack control - nothing to do with position and offset. Think of it as the machine just bringing the sub code 'in-line', that's all.
I will play some more and see if I can get a tighter definition of where the problem arises.
Cheers
-
Even Art has said that Machs sub nesting is limited(;-) The fact of a stack is not a problem but what can occurs in each layer of that stack can be extemely complicated to positional tracking.
Remember the the fanucs of this world have about 40-50 years of software enginerring to create what you see today and they may run on as many as 8 processors to get it all done.
I think even Fanuc has a known limit on nesting subs.
I think IF you were to rethink where you actually NEED to apply the TC and then turn it off after it has done its job and then reapply it as needed you will see more success with it. I don't think the idea of turning on in the begginning and leaving on until the end of the program will ever pan out in the cases of deeply nested subs.
Just a thought, (;-) TP
-
Hi all
OK, I have appended here two programs to demonstrate when G41 breaks down in the latest release.
In essence they are 'identical', except that in V6 the four points of the star are created by calling a sub 4 times, while in V7 the code has been unrolled into an in-line form. But the instructions are identical.
The crucial point here is that this is a single layer of subroutine!
In V7 you will see a 4-point star being cut, and the cutter diameter is set by the G41 call. The white line is the actual path the cutter follows; the blue line is the required or programmed outline. This version works.
In V6 you will see the 4-point star, but the cutter does these huge loops back to one point at each corner. If you comment out the G41 call the program runs correctly (by way of confirmation).
This seems to mean that G41 cannot be used reliably with ANY subroutines? But it should not be that difficult to carry the state information across a sub call. Every computer programming language since Fortran manages to do that.
Cheers
-
We will just have to waite and see what V4 brings.
(;-)TP
-
Hi TP
We will just have to waite and see what V4 brings.
Very true, but ...
I wonder whether I could ask you to check the two programs (V6 & V7) on your machine, to see whether the problem reproduces?
Be a bit sad if it only happens on mine!
Cheers
-
I did already V7 runs fine and V6 fails.
BUT not all subs fail with TC (;-) here is an example of one that runs fine with TC. You are running the trifecta, Parametric,subs, & nested subs (;-)
N0090 T3 M06 G43 H3
N0100 G00 X3.7195 Y3.9437
N0110 G01 Z0.800 F60
G42 P.500
M98 P1 L2
G40
N0260 G1 X3.7195 Y3.9437
N0270 G00 Z0.0000
N0280 M05 M30
o1
N0120 X3.7026 Y2.9439
N0130 X3.6710 Y2.8073
N0140 X2.7719 Y-1.0715
N0150 X-0.0074 Y-1.7757
N0160 G03 X-0.0127 Y-1.8319 Z0.8000 I0.0074 J-0.0291 F60.0
N0170 G01 X2.7240 Y-3.1110 Z0.800 F60
N0180 X3.7942 Y-5.5192
N0190 G03 X3.8508 Y-5.5139 Z0.8000 I0.0274 J0.0122 F60.0
N0200 G01 X4.4768 Y-2.8848 Z0.800 F60
N0210 X7.2253 Y-1.9610
N0220 G03 X7.2241 Y-1.9037 Z0.8000 I-0.0096 J0.0284 F60.0
N0230 G01 X4.5004 Y-1.1174 Z0.800 F60
N0240 X3.7296 Y2.8064
N0250 X3.7026 Y2.9439
N0260 G1 X3.7195 Y3.9437
M99
%
Just a side note the normal fanuc standard(Peter Smid) calls for a max of 4 sub nests and MACH3 has a repetetion limit of 999 per sub call. I have seen MACH3 get flacky above 3 nest layers
Also IF I remember correctly Art warned that Variables may not be stable deeply nested as well
What version of MAch3 are you running. The latest versions are the quirkyest I normally run V.020.
SOmetimes you just have to go back to basics on programing. One standard I stick to is IF I plan to program an exotic version like you have I NEVER plan to use TC and they rarely fail to run properly(;-).
(;-) TP
-
I did already V7 runs fine and V6 fails.
OK, thanks. Reassuring.
BUT not all subs fail with TC (;-) here is an example of one that runs fine with TC. You are running the trifecta, Parametric,subs, & nested subs (;-)
Hum ...
Not sure that parametric programming should affect the results - surely?
Just a side note the normal fanuc standard(Peter Smid) calls for a max of 4 sub nests and MACH3 has a repetetion limit of 999 per sub call. I have seen MACH3 get flacky above 3 nest layers
Oh. Hum ...
Mind you, Smid's comment is NOT indicative of what is theoretically possible for Mach3. Older CNC controllers were very crude things with very limited hardware and power, and a limit on sub layers was quite reasonable for the technology then available.
But this is 2011, and we have all the power of dual and quad processors and GBytes of memory to play with. Mainstream programming languages and compilers can handle more subroutine nesting than you could ever sanely contemplate, and a Basic interpreter (or Perl, HTML, etc) can do just the same. A g-code interpreter should be able to draw on all that computing knowledge and be equally adept. Program state (eg subroutine level) should not interact with either global variables or logic flags. The old limits due to primitive technology no longer apply.
Yeah, I am prepared to stick my neck out that far.
Also IF I remember correctly Art warned that Variables may not be stable deeply nested as well
?????? Huh ??????? WHY????
What version of MAch3 are you running. The latest versions are the quirkyest I normally run V.020.
R3.043.022
Hum .... ?
IF I plan to program an exotic version like you have I NEVER plan to use TC and they rarely fail to run properly(;-).
Yeah, well, that's my normal programming style. Too many decades of mainstream programming, and I am not using CAM packages as I can't afford them. But also I think I can do some neat and tricky things by hand-coding for production purposes.
So far my style has never failed due to limitations in Mach3 - except for the TC problem. I am not wedded to TC and can live without it. I just thought it would be convenient. But I can manage.
Cheers
-
Mind you, Smid's comment is NOT indicative of what is theoretically possible for Mach3
But the comp in V4 is based on Smid's book, I believe.
-
But the comp in V4 is based on Smid's book, I believe.
Quite possibly, but totally irrelevant. Even though I have not been able to find a single copy of any of Smid's books in any public libary here in Australia (why???), I feel very confident in making two predictions about what Smid has written.
1) The compensation should produce a tool path which gives the required shape, which is pretty obvious to the user.
I think this one is perfectly obvious. How it is done is 'left as an exercise for the reader', but testing the result is very easy.
2) The level of subroutines involved in the program does not affect the required outline or path in any way.
After all, why should it?
To be sure, a practical implementation such as an old Fanuc controller might impose it's own limitations on what sort of program it can execute. That is quite different, and no problems there. But the idea that global variables such as the current position or direction might depend theoretically on the subroutine level - no way!.
If the gaming industry can write code which lets you fly around WoW or Halo or Second Life in full 3D, then a g-code program should be able to create a tool path for cutter compensation regardless of how many subroutine levels you have in your code.
Looking at the results from my test programs and TP's test programs, I have to say it lokks like an errant SR return or an errant pointer is causing a jump to the code for a spiral or similar (G2, g3 for instance) instead of the correct code. That is a bug. Period.
Cheers
PS: I have frequently been told in other venues that I am far too blunt for American sensibilities. This seems to be a failing common to many Australians. We are blunt. If anyone is offended by my bluntness, my apologies.
-
Graham........could you shed some light at a "high level" on this thread?
RICH
-
If the gaming industry can write code which lets you fly around WoW or Halo or Second Life in full 3D, then a g-code program should be able to create a tool path for cutter compensation regardless of how many subroutine levels you have in your code.
I do agree with what you're saying, but I think the issue has more to do with the 1 man development crew rather than what's theoretically possible. No offense to Brian's abilities, but he just doesn't have the time to develop Mach3 as it really needs to be developed.
-
Interesting thread since it covers a lot of subject matter. Not a simple thread by any means........
Don't know the specifics of different controller systems, level of developement or even the differences in application since
there are differences even within families of controllers. Smid eludes to this in his writings and to get the big picture one would need all three books,
ans a crasp of all the material . I don't have the Fanuc Macro Book and it's my bad to say that something follows something exactly since who knows exactly
how something is handled internaly within the controller software ( they are certainly not exact ). TP has touched on this somewhat.
Not trying to be defensive or negative on any of them.
FWIW,
RICH
-
HIYA RCaffin, I understand where you are going with the discussion. I was one of the ones that took that stand LONG ago with mach3. When Art was programming Mach I think he had to set a limit as to what the original Base code (emc) would handle as far as nested levels. With Mach we have a repetetion limit of 999, most modern fanucs will do 9999 (;-) on subs.
Brian is aware of most of this as well. But with Brian as with Art it is basically a one man show to do the developement work. We actually burnt out Art we don't want to do the same to Brian.
In the game of DIY cnc patience and adaptabilty are the keys to happy machining. IF it won't/can't work this way TRY it from another angle untill you get want you need. AND it may not be the way you would want it to be.
Also you will find that Brian is a modern type CNCer his main thrust is CAMed code and the General USERS methods. And yes he understand it but is not crazy about the parametric code side (;-) so we have to kinda tippy toe about the matter. Same with conditional code in the parametrics. Maybe one day we will have it but no time soon.
As with Mach3 it has evolved to an everything motion controller NOT just a CNC controller so they have to be carefull about what they may break when they go back in to do a fix. Many things have already been effected by fixes(;-). That is a reason for some to go back to OLD versions because they still will do certain functions that the later versions have trouble with.
ALso they have to make it WORK over a Very broad range of computer hardware. In modern CNC controllers the hardware is a fixed variable that never changes so you can program around any obstical you may have in hardware. NOT ALWAYS SO with PCs and the millions of variations of hardware over the years.
With the LPT version it is very easy to load up the VERY fast CPUs so bad that MACH3 will come to a crawl (;-)
Take the driver for instance it is LOCKED in as a 32 bit driver and may never change. I believe Mach will evolve to only running motion controllers as outside hardware like everyone else has done.
So hopefully Mach3V4 will better suite the modern CNCer not just the hobbiest CNCer.
Just a thought, (;-) TP
-
Hi Ger and all
I think the issue has more to do with the 1 man development crew rather than what's theoretically possible. No offense to Brian's abilities, but he just doesn't have the time to develop Mach3 as it really needs to be developed.
I wonder how many people are involved in writing and maintaining the Fanuc code? All the different versions!
In other words, I agree with you completely here. That's the problem with proprietary code development as opposed to Open Source: resources.
I am not at all suggesting that Mach3 should be turned into Open Source, but should Brian want to get some help - I started programming in the 60s and have worked at all levels (hardware micro-code, Assembly, drivers, compilers, OSs, HLL, to DB SW) since then.
Ah well, back to chips.
Cheers
-
He posted today that he's hired a new programmer to work on the new version.
-
Experienced I HOPE!
Last time someone hired a new programmer to work on one of my systems (NOT someone of my choice) the project went backwards by at least one year. Sigh.
But, hope!
Cheers
-
Experienced I HOPE!
No worries there, the guy knows what he is doing and has already worked on bits and pieces for Mach :)
Hood
-
No worries there, the guy knows what he is doing and has already worked on bits and pieces for Mach :)
Them's good vibes!
Ok, so now we all heap on Brian for the next release date! :-) :-)
cheers
-
You being a programmer should know programmers watches and calenders dont seem to be on the same time scale as us mere mortals ;)
Hood
-
You being a programmer should know programmers watches and calenders dont seem to be on the same time scale as us mere mortals ;)
Ooh - below the belt! Unfair to ... huma... ahem. :-)
Programmers would argue (and frequently do) that the problem lies not with their watches, but with the watches of management who create arbitrary deadlines. An old argument, which should not be restarted here.
Instead let us contemplate the light at the end of the tunnel ...
and wonder whether it is daylight or the headlight of an oncoming train...
Hey, I'm an optimist (with the odd skinned knuckle).
Cheers