[Gun-Machine]

EDIT: I FIXED THE ERROR IN THIS FIRST POST. POST #4's Issues are slighlty resolved.

New Insight/Conclusions in Post #10

I hope this helps other newbies though....
I just put the X and Y movements from N095 On separate lines. Did the G00 X move on N092 and then left the Y move on N095, and now it moves to the proper locations.
I am wondering if the Slight angle in one move caused the error. .010 of X-axis movement over the entire distance of Y-axis movement (about 2.5 inches) hung it up for some reason. After I separated them all is right.


ORIGINAL POST:

I am new to Programming G-code, so please excuse me if there is an honest mistake in there. (Also excuse the wild nature of my code:drowning:, this is more of an exercise to make a jig out of a odd shaped piece of scrap I have, and I am just learning to use G-code, and writing this to educate myself)

The tool path generated in Mach, and in the Demo version of Back Plotter shows my tool path exactly how I programmed it.

I am not at my machine, but I have been running it in Mach off-line and at a certain line in the program is doesn't actually follow the tool path correctly.
I've tried re-writing the 3-4 lines of code that effect that move and nothing seems to work. I have a Demo version of Data-View (which is a little confusing to me) but it shoes the incorrect tool path when I load the G-code into it. It also says I have 61 and some odd errors, but I can't seem to figure out what they are. I've gone over the code multiple times, and I can't figure out why it Generates the proper tool path but doesn't follow the tool path when I run it in Mach.

Starting at line (N095) it doesn't follow where it's supposed to go.
N090 G1 M98 P600 L1
N095 G00 Y-1.475 X2.421
N100 F6.1 S993 G04 P2
N105 Z-.470
N115 G1 M98 P700 L1

It never moves to the y-1.475 Coordinate... it then pauses (I'm assuming due to the 2 second dwell) and then Z plunges, and begins my Subroutine O700, and the line that is the proper first move is high lighted on the tool path, but the spindle location on the screen is still up above my work piece in the Y coordinate it is left at leaving the O600 Subroutine.
It then moves to the first X Coordinate in Sub-O700 then tries to move through the entire piece to the the Y Coordinate in Sub-O700

All of my moves have been okay everywhere else, and I have used the same order of execution. I have re-written those handful of lines many times, nothing seems to fix it. It simply won't do line N095.

[rowbare]

Your code is a bit of a mess to be honest but as you said, you are learning...

It mostly comes down to style, readability and consistency. A couple of good guidelines to follow:
Don't put more than one G and M code in the same block (outside of the setup blocks at the beginning of a program),
The first word in the block should be the command, and the parameters should follow,
Explicit is better than implicit.

Lines N090 and N115, the G1 command shouldn't be there. It violates the guideline about putting more than one command word on a line. Also if you have coded your subroutine assuming that the G1 was done externally, you could be in for a big surprise. Suppose you were calling that subroutine, and had just done a G0 or G2 and forgot to add that G1, you would crash in the subroutine. A subroutine shouldn't assume a certain mode. As well when you return from a subroutine, you should reset to a known state since you cannot be sure what happened in the subroutine. However applying the Explicit is better than Implicit rule takes care of most of that.

N095 I am not sure why this wouldn't work other than the command is called G0 not G00 and that might have thrown the parser off.

N100 the main problem is that G word is lost in the middle. It should be written
G04 P2 S993 F6.1
or be broken into multiple lines eg:
S993 F6.1
G04 P2
I think the single line form is probably the more readable in this case. Someone looking at it will see that you are dwelling to let the speed change happen. Don't worry about the S word following the G word since commands in a block are executed in a specific order (see Mach manual table 10.9 and section 10.12).

N105 this is a rapid move in Z since N095 has put you into G0 mode, is it meant to be? The fact that the previous line sets a feed rate makes me wonder if that was your intent or not. Again explicit is better than implicit. Write G0 Z-.470 or G1 Z-.470 F6.1 and there is no ambiguity.

In the end it comes down to what you can wrap your mind around though I would recommend that you write things a bit more explicitly while you are learning. It makes it a lot easier to debug the code.

Do you know what dialect of G-Code DataView expects? That might be the source of a lot of the errors. There is a common one, Fanuc I believe, that expects decimals in all dimensions so G0 Z0 would be an error since it wants G0 Z0.0

good luck!
bob

[Gun-Machine]

I appreciate the input.

The G00 works, not sure why I always put two 0's. I need to break that habit. I guess because I have also been writing some commands like M06 vs. M6. But I need to stop doing that.

The Z-plunge is correct in rapid mode, I adjust the S-F and it rapids down, then the G1 is called before the sub-routine. But It's really more of a precaution since I have G1 in the very first line of the sub-routine as well. Because I figure it's only two more characters to type, but I want to be doubly sure it's moving at feed rate, and I always specify the proper motion command in the line following a subroutine to be sure of its motion after the sub routine.
I have been reading Peter Smids book and trying to maintain some of his principles, however as a beginner I am always just trying to make sure it don't crash anything, even if it means repeating modal commands on multiple lines after I called some kind of subroutine in between.

I wrote the line with the S and F change in that order because the Manual with my tormach has a Order of execution table in it
#3 is Set feed rate (F)
#4 is Set spindle rate (S)
and
#10 Dwell (G4 P~)

So I was trying to maintain the order of execution on a line to maintain "critical safety and effective machining" since in Smid's book it talks about following the order of execution for a line as specified by the machine manufacturer.
Originally I had it as
G04 P2 Sxxx Fxxx
But I had reversed it to follow the order specified in my machine manual, as I was trying to figure out what was causing the issue.

I suppose over time I will become more knowledgeable and capable with the machine, and know what to write and what not to write and in what orders.

As it is I am writing a Small segment of the Commands, and then Verifying them on Mach's Tool Path screen. As long as things look good, I keep going. I then ignore the lines with feed rate specified and up the feed rate and watch it run through the program so I can see if the Tool actually follows the generated tool path (in off line mode of course), and I will do this once above the piece before I actually run it on my machine in real time.

[Gun-Machine]

Now I'm having a new issue... and it makes no sense to me.

For some reason, random Z-rapid movements won't work.
But it's random every time I run the program. (random as in they happen at certain spots in the program but not consistently... sometimes they work other times they don't work at the exact same line of the part program)

I block skip the Feed rates, so I can run the program faster (because the Run from here command doesn't work in Mach 3 and it always tries to run it from the the first line of my first subroutine no matter what I do... )

I fixed one of them by putting G0 on it's on line then the Rapid Z movement on the following line. But other lines that have the G0 and z-rapid movement on one line work perfectly fine, but others, written the same way, skip the Z-rapid movement. It makes no sense.

The tool path that is generated shows the proper movement on the screen, however when I run it... it doesn't make the movements.
It's always during a Z-rapid (+ and/or -) movement that follows a subroutine (first line immediately after a subroutine).
I would make the general assumption that there is some kind of issue when writing such a movement after a subroutine, however, it works in some places but not in others. After putting the G0 and the Z movement on two separate lines at one of the troublesome area's it fixed the issue. However, I don't understand why I should have to do that, when it works perfectly fine in other lines.

Also. Why can't I utilize the "Run from Here" command on the tool path screen, no matter what I do or what line I put it on, it always jumps to the First line of my first subroutine. Never does it attempt to run from the line I have select. Even if I am in Comp Run and manually enter the Line number then try to "Run from here" It ALWAYS resorts to the same line.

Another issue I was having... I tried using a G52 Offset later on in the code to simply profiling a shape, and after I did this... all of the Rapid Movements prior to the offset post really funny and combine Z and XY motions in areas where the motions are completely on separate lines and should not be moving at the same time. It also generates Random ZXY rapid movements I never even programed on weird areas connecting coordinate points from random lines that otherwise would have no direct connection to one another.

This is becoming extremely irritating. Especially considering that I then deleted the G52 lines and everything I wrote past them, and even after regenerating the tool path, it showed these lines. I had to close down Mach and reopen a copy of the G-code file that was prior to me making any changes...

EDIT: I realized these odd "white" rapid movement lines that have strange orientations that connect points, go away when I delete a G41 P.125 radius offset command in the program (I thought they had to do with the addition of the G52 offset... pardon me). What's strange though, is that when included on the program it makes those lines in area's that are not even related to the offset too path... area's where the tool won't be anywhere near? When I test run it, the program never moves in any of these lines... but why do they appear at all?
Note: I am not talking about the Radius Offset lines that follow the designated tool path I have specified, just the Dotted/Rapid Movement lines that are all over the place making connections to coordinate points in what appears like random order, just zig-zagging all over the places in linear XYZ movements.

I know the general conclusions would be that somewhere in there these are faults of my own (being that I am a beginner) but no matter how much I reference my Manuals and go over my lines of code, I can't help but think Mach 3 is buggy as hell... Everyone says it runs flawlessly, so why do lines of code written the exact same operate differently at different parts of my part program?

I have mach 3 on 3 different PC's and I get these issues with all 3 (which further leads one to believe it's operator error ... or the alternative that my Copy of Mach 3 or the way I installed it is flawed) but I can't figure out what I am doing wrong or why things are not working the way my Machine manual says they will or the way the CNC programmers Hand Book says they will.

This is really frustrating to me...

I would really appreciate any insight into my issues.
Sorry to ask so much, I just can't seem to figure out the source of my many issues I am having. (most likely Operator error)

[dbrija]

Now I'm having a new issue... and it makes no sense to me.

For some reason, random Z-rapid movements won't work.
But it's random every time I run the program. (random as in they happen at certain spots in the program but not consistently... sometimes they work other times they don't work at the exact same line of the part program)

I block skip the Feed rates, so I can run the program faster (because the Run from here command doesn't work in Mach 3 and it always tries to run it from the the first line of my first subroutine no matter what I do... )

I fixed one of them by putting G0 on it's on line then the Rapid Z movement on the following line. But other lines that have the G0 and z-rapid movement on one line work perfectly fine, but others, written the same way, skip the Z-rapid movement. It makes no sense.

The tool path that is generated shows the proper movement on the screen, however when I run it... it doesn't make the movements.
It's always during a Z-rapid (+ and/or -) movement that follows a subroutine (first line immediately after a subroutine).
I would make the general assumption that there is some kind of issue when writing such a movement after a subroutine, however, it works in some places but not in others. After putting the G0 and the Z movement on two separate lines at one of the troublesome area's it fixed the issue. However, I don't understand why I should have to do that, when it works perfectly fine in other lines.

Also. Why can't I utilize the "Run from Here" command on the tool path screen, no matter what I do or what line I put it on, it always jumps to the First line of my first subroutine. Never does it attempt to run from the line I have select. Even if I am in Comp Run and manually enter the Line number then try to "Run from here" It ALWAYS resorts to the same line.

Another issue I was having... I tried using a G52 Offset later on in the code to simply profiling a shape, and after I did this... all of the Rapid Movements prior to the offset post really funny and combine Z and XY motions in areas where the motions are completely on separate lines and should not be moving at the same time. It also generates Random ZXY rapid movements I never even programed on weird areas connecting coordinate points from random lines that otherwise would have no direct connection to one another.

This is becoming extremely irritating. Especially considering that I then deleted the G52 lines and everything I wrote past them, and even after regenerating the tool path, it showed these lines. I had to close down Mach and reopen a copy of the G-code file that was prior to me making any changes...

EDIT: I realized these odd "white" rapid movement lines that have strange orientations that connect points, go away when I delete a G41 P.125 radius offset command in the program (I thought they had to do with the addition of the G52 offset... pardon me). What's strange though, is that when included on the program it makes those lines in area's that are not even related to the offset too path... area's where the tool won't be anywhere near? When I test run it, the program never moves in any of these lines... but why do they appear at all?
Note: I am not talking about the Radius Offset lines that follow the designated tool path I have specified, just the Dotted/Rapid Movement lines that are all over the place making connections to coordinate points in what appears like random order, just zig-zagging all over the places in linear XYZ movements.

I know the general conclusions would be that somewhere in there these are faults of my own (being that I am a beginner) but no matter how much I reference my Manuals and go over my lines of code, I can't help but think Mach 3 is buggy as hell... Everyone says it runs flawlessly, so why do lines of code written the exact same operate differently at different parts of my part program?

I have mach 3 on 3 different PC's and I get these issues with all 3 (which further leads one to believe it's operator error ... or the alternative that my Copy of Mach 3 or the way I installed it is flawed) but I can't figure out what I am doing wrong or why things are not working the way my Machine manual says they will or the way the CNC programmers Hand Book says they will.

This is really frustrating to me...

I would really appreciate any insight into my issues.
Sorry to ask so much, I just can't seem to figure out the source of my many issues I am having. (most likely Operator error)

I recall reading somewhere that Tormach specifically recommends NOT using G41 and G42. Don't recall the reason right off.... Someone will be along shortly who does.

[Gun-Machine]

REALLY ???!!!

That would be quite inconvenient...

What is especially puzzling me now is that I have another program I wrote with g41 offsets used... and it works just fine, and the dotted white lines I mention, don't show up in it like the program I am working on.

I'm going over the lines and through my manuals repetitively at such a rate my head is hurting.

I'm about to scrap the program and start all over with a different approach.

But either way, if the G41/G42 commands are not doable with the Tormach machines, I am going to be seriously pissed off.
Note: I am using the G41 Offset with a P~ number, not utilizing the Tool number offset.

T02 M6 G43 H02 is programmed early on in both programs.
But when I call for G41 I use G41 with a P.135 Radius Offset in the troubled program vs. no P~ in the good program which defaults as the Tool table #2's Radius offset.

Now I am really confused...

[Gun-Machine]

It's recommended that you let CAM take care of it.
Not that you Can't utilize G41/G42 off sets/

However, I can get the G41/G42 offsets to work just fine.

I just tried them out on multiple different configurations, they get funny when using ARCs as entries. I just use a single linear entry and they are fine.
(as long as you lead the start position the Full Diameter of the tool, and enter the path of linear travel with 20% lead of the Tools diameter on the Axis of travel) So I suppose for 2D profiling it is just fine.

[dbrija]

It's recommended that you let CAM take care of it.
Not that you Can't utilize G41/G42 off sets/

However, I can get the G41/G42 offsets to work just fine.

I just tried them out on multiple different configurations, they get funny when using ARCs as entries. I just use a single linear entry and they are fine.
(as long as you lead the start position the Full Diameter of the tool, and enter the path of linear travel with 20% lead of the Tools diameter on the Axis of travel) So I suppose for 2D profiling it is just fine.

I can't remember the context I read that G41/42 recommendation in. Letting CAM handle that is the "usual" path. It may even have been in a Mach3 forum.

[R.DesJardin]

Maybe I missed this, but WHY aren't you using a CAM program? I know all the mini mill/lathe guys use g-code stuff for their little hobby projects but.........why? It sound like most of your issues would be resolved if you had CAM software. I do understand the need to know what the code is doing but to hand code something, no way no thanks. I know this won't solve your issues, but..............

[Gun-Machine]

I purchased Alibre, and where the CAD is great... the Basic CAM that comes with it is completely useless and horrible.

For right now I'd prefer to learn to code by hand completely, That way I can make the most efficient program possible.

The main part I will be making on the machine will be run many times over. I only have to write it once. I'd prefer the program be more efficient, not the process of writing it through the CAM.

When I have more money to spend in the future I will invest in Better CAD and CAM and tell Alibre to shove it. They have horrible support when I ask questions, I've gotten more "I don't know" 's then I have answers from them.
And the tutorials you get and videos you have access to, to watch on there site only work if you have there upgraded version of CAM (you need features in the upgraded version to utilize the info provided in the tutorials) so it's completely useless to me. You can do some basic functions but 80% of the options are locked. It's quite the gimmick and more of a hassle to use then not.

And regardless... Using a CAM wouldn't solve the issue I am having.
I have the correct code written, The tool path it generates does what I say, but the actual tool motion does not. So using a CAM does not solve any of the issues I am having.

N100 G0 Z-.350 should work.... and will be written like that in a CAM program.

Putting G0 and the Z-movement on separate lines fixes my issue... that is not right... I will have to go in and edit a bunch of lines regardless at that rate.
Not to mention the other issues I am having that are not based on my code at all. Like why I can't use the "Run from here" option in mach.

So spending more money on a New CAM program does not solve the issues at hand.

But I have thought about what Affordable CAM programs will allow me to import Alibre CAD files, and work well for me.
I just don't have a few grand to spend on the big names.
And the first "affordable" CAM program I purchased was a complete waste of money and very misleading as to what I can do with it according to their REP. If I could have completed the tutorial, sure... but there answer to that issue was "Well you can unlock those features if you upgrade the CAM then you can complete the tutorials and follow the videos" .... What a Crock. I won't give them another penny based on that alone.

Any recommendations for an Affordable CAM program?

[ger21]

EDIT: I realized these odd "white" rapid movement lines that have strange orientations that connect points, go away when I delete a G41 P.125 radius offset command in the program (I thought they had to do with the addition of the G52 offset... pardon me). What's strange though, is that when included on the program it makes those lines in area's that are not even related to the offset too path... area's where the tool won't be anywhere near? When I test run it, the program never moves in any of these lines... but why do they appear at all?

The white lines are the compensated toolpaths. I don't have time right now to thoroughly read all your posts. I'll try to look closer tonight and give you more info.

It sounds like you're not using the G41/G42 correctly, which is causing unexpected results.

[rowbare]

Any recommendations for an Affordable CAM program?

CamBam at $149 seems to be pretty good. The demo version allows you 40 sessions so you get a good chance to evaluate it. I don't have a lot of experience with it but I managed to get a simple part done fairly quickly the first time I tried it. I will buy it when the demo runs out.

SprutCam is quite powerful and Tormach has a pretty good deal for Tormach owners. However it is considerably more expensive and there is a substantial learning curve.

I like D2NC ($79 - 14 day demo) for quick ad-hoc 2.5D jobs. It has a built-in language that allows you to describe shapes via simple commands. It is a bit hard to describe but if you go to the site and click on the Screen Cams link, you will find a few demo videos. It works well for the way I think.

Bob Warfield sells GWizard which is a machinist's calculator. He also has a beta version of a G-code editor available.

This is a shot in the dark. What are you using for a text editor? Is it possible that you editor is saving as Unicode or in some encoding that Mach has problems with?


bob

[ger21]

For some reason, random Z-rapid movements won't work.
But it's random every time I run the program. (random as in they happen at certain spots in the program but not consistently... sometimes they work other times they don't work at the exact same line of the part program)

Generally, if you're getting inconsistent results from Mach3, it's an indication that something is corrupted somewhere. The best fix is usually to completely uninstall it, and then re-install.

(because the Run from here command doesn't work in Mach 3 and it always tries to run it from the the first line of my first subroutine no matter what I do... )

Two things. Do you have a licensed version of Mach3? Check Help>About
Run from here doesn't work with an unlicensed version.
Also, are you trying to Run From Here inside a Subroutine? The manual says not to.

As for the G41/G42, there may be some bugs in the Tormach version of Mach3. I believe there are also bugs in all versions of mach3 if using G41/G42 in subroutines.

But I don't have a Tormach, and I use G41/G42 for most of my parts in the latest Mach3 with no problems. No subroutines, though.

I think what you need to do is post small g-code files you've written that don't work, so we can tell you why.

I have mach 3 on 3 different PC's and I get these issues with all 3 (which further leads one to believe it's operator error ... or the alternative that my Copy of Mach 3 or the way I installed it is flawed)

My bet is one of these two options.

And lastly, both G01 and G1 are correct. Either way should work fine.

[Gun-Machine]

Tormach has an issue with G41/G42 Offsets in there version of Mach.
I am running them with Subroutines. However, I got them to work. I use linear entry moves.

I realized, for some reason, if I use a G52 Offset anywhere in the program it makes Radius compensation go crazy. I also can not switch the Work offset I am using (i.e. G54 to G55) anywhere in the program or the radius compensation goes crazy.

I can work around either it's just a pain in the ass.
Easier to calculate where I want the offset to be once in a subroutine then have to manually write in all of my Radius Compensation.

No sure why one affects the other, but I tested it multiple ways earlier.
Cutter Radius comp works Fine as long as I don't use any other Offsets in the program (Axis/work offset).

Lessons I learned today about Tormachs Version of Mach.

If I use a Rapid Z movement on the 1st line following a Subroutine (after returning from a subroutine) it is random if it will work or not (sometimes it does sometimes It doesnt) Fix: I put G0 on the First line following the subroutine then the Z-Movement after it and it worked every time.

If I Run a Radius Compensation Offset, I can not use g52/92 offsets or switch from a work offset (i.e. switching from G54 to g57) or the radius compensation goes crazy anywhere in the program (even prior to the work offset change)

They said they are working hard to fix this issue, and I look forward to that very much. until then I will just work around it.

My program worked exactly as I wrote it, once I realize these things. (I removed my G52 offset)
So I'm kinda happy to know I didn't screw up my coding , but equally disappointed that I can't utilize Cutter Radius comp and Axis/Work offsets in the same program oh well. Guess I have something to look forward to from Tormach aside from the 770 Power Draw bar

Now the only thing that doesn't make any sense to me is that... Prior to removing the G52 offset from my program, the Tool path posts correctly on my two comps running Mach off line. But the one hooked up to my machine showed the Radius Compensation going crazy and all over the place. When I run it on my Off line Computers the Tool path follows the right path.... on the Controller it follows the crazy path....
... So why does it Post differently on the controller, if they are all the same version of Mach? Same code, different paths generated?
Note: My office PC and the Machine Controller are the EXACT same PC's I ordered two of everything and built Identical computers. So I don't believe it to be a issue with the variances in Computers, though I may be wrong. But I'd like to remove that possible variable from the equation here.

(Mach3 Tormach version, and yes they are licensed)

Note: Tormach was Extremely Helpful on the phone earlier, as I discussed Issues with them. They are a wonderful company and have gone above and beyond for me every time I deal with them. The Gentlemen I spoke with stayed on the phone with me and answered every possible aspect of every question as best he could until I had only a few possibilities to look at. Ultimately their help lead me to my conclusions and for the most part solved me issues.

Thank you Tormach

[Gun-Machine]

The white lines are the compensated toolpaths. I don't have time right now to thoroughly read all your posts. I'll try to look closer tonight and give you more info.

It sounds like you're not using the G41/G42 correctly, which is causing unexpected results.

I appreciate the Help.
I did Note that I wasn't talking about the Compensation lines. I get those.

It was like Dotted White Lines that Looked like Rapid Motion lines, but would Zig Zag in straight XYZ linear motions connecting other coordinates where I had Rapid motions moving, but not in the paths I had specified.

Nothing results from them, and they only appear when I have cutter Radius Compensation in the Program. But nothing every becomes of them. They just appear on the Tool Path Display. The program runs safely.... I just wasn't sure why they exist, and couldn't figure out any logical order for them.

They'd connect Coordinate locations that had no connection to each other in terms of tool path, but the only similarity is that they were all locations where Actual Programmed Rapid motions went to or from.
Example:
I have these Rapids somewhere in my program. (Assume I am at X0 Y0 Z0)
G0 Z1
X1
Y1
X0
y0

You'd expect Rapid motion lines that would Rise 1 then make a 1 inch square.
I would see these motions in Dotted Red lines.
Once I enter Offsets into my program (later in the program)
I would see White Dotted Lines drawn from ZOXOYO to all corners of the square at the Z1 height
Example Lines like I had programmed coordinates (from Z0X0Y0)
Z1 X1
Z1 X1 Y1
Z1 X0 Y1
(All coming from Z0X0Y0)

But they were in no particular order in my actual Part program. The only common factor in them is that they made lines connecting start and stop points of programmed rapid movements, but not all of them. Just some.
Just weird zig zagging white lines all over my part program.

Like I said though. Nothing ever came of them...
I see them, but no movement ever results from them.

[Magnum164]

But I have thought about what Affordable CAM programs will allow me to import Alibre CAD files, and work well for me.
I just don't have a few grand to spend on the big names.
And the first "affordable" CAM program I purchased was a complete waste of money and very misleading as to what I can do with it according to their REP. If I could have completed the tutorial, sure... but there answer to that issue was "Well you can unlock those features if you upgrade the CAM then you can complete the tutorials and follow the videos" .... What a Crock. I won't give them another penny based on that alone.

Any recommendations for an Affordable CAM program?

Actually, the CAM that comes with Alibre is very basic almost like a demo with it's limited features. But the CAM program is a very good one, it is not Alibre's it is Visual Mill. For the better features you are going to pay about $1-2K or you can try SprutCAM. But either way it is going to cost a bit. If you are buying a Tormach you can a discount on SprutCAM.

Funny how you can get different opinions on the internet. For me I saving up and will probably by AlibreCAM full version before long. I started to buy it when I bought Rhino3D and BoBCAD. I don't like BobCad, but there are others that love it.

[dbrija]

Actually, the CAM that comes with Alibre is very basic almost like a demo with it's limited features. But the CAM program is a very good one, it is not Alibre's it is Visual Mill. For the better features you are going to pay about $1-2K or you can try SprutCAM. But either way it is going to cost a bit. If you are buying a Tormach you can a discount on SprutCAM.

Funny how you can get different opinions on the internet. For me I saving up and will probably by AlibreCAM full version before long. I started to buy it when I bought Rhino3D and BoBCAD. I don't like BobCad, but there are others that love it.

I've been debating upgrading my Alibre CAM from standard to Pro to get the 4th axis, but I just couldn't justify the $1200 upgrade, plus $399 maintenance. I decided to go with Sprutcam when I buy my mill next month. It gives me 4th, even 5th axis, plus lathe (I might buy a Duality, so that will be nice to have). Only advantage Alibre gives it that if you mod the model, you just regen the toolpaths. Sprutcam means re-export and redo.. not a huge deal though.

[Magnum164]

I've been debating upgrading my Alibre CAM from standard to Pro to get the 4th axis, but I just couldn't justify the $1200 upgrade, plus $399 maintenance. I decided to go with Sprutcam when I buy my mill next month. It gives me 4th, even 5th axis, plus lathe (I might buy a Duality, so that will be nice to have). Only advantage Alibre gives it that if you mod the model, you just regen the toolpaths. Sprutcam means re-export and redo.. not a huge deal though.

SC is good.. In fact, I think it used to be bundled with Alibre several years ago. With all of the features being added in SC, I can see them raising the price up soon. Hope not. But yes, VisualMill pricing has always been high for the higher end options....

Someone posted in another forum is that you can export operations from SC and then re-import then into SC and your model and just reassign the features. May be a little easier than redoing everything. But my parts are so small at the moment, redoing them is not really a problem..