[Concepts_Design]

Let me start by saying that I admittedly know very little about post processors and g-code, yes I should know more but it will take a bit of time for me. I do however have quite a few close friends that are very well versed in this area and having been doing this for 20-30 years and are always willing to help me out. This was the case last night.

I loaded in PP and right away had problems with programs that I ran just the day before with no issues. What I don't understand is how Tormach can say that if a processor worked in Mach3 that it will work with PP, when at least in my case, it did not work without modifying the processor quite a bit. I'm using Bobcam for Solidworks V4 and Tormach can say whatever they want about it, but there were no issues with it in Mach, in fact my buddy looked through many of my programs and said that Bobcam was spitting out code exactly as it should be and all the problems he found were within PP itself

He did get my processor modified to where it would work but had to change it so that it was tricking it into working, most of the issues were to do with cutter comp, for some reason PP except they Bobcam calculates lead in's and out's. Again, I never had a issue with Mach3 and in the end I had to load Mach back in because I need to get work done and even though he got the post working, I can't risk something not working In the middle of a job and waiting until my buddy gets home to come over and check It out.

Don't get me wrong I'm not bashing Tormach or PP, I think the interface is great and once all issues are resolved I can't wait until I can run it.

My question is, is anyone else having issues with their post processors and if so, what are the issues? I have looked on the issue tracker and I don't see any of the problems I'm having and I'm curious to see if it is bobcam, but like I said code looks fine and I never had one single problem with Mach and the stock Tormach post they provide was never modified before

and like I said, I'm no bashing anyone I just am trying to see if others have similar issues. I would hate to find out that PP will not function correctly with Bobcam even after it is fully released

Thanks
Kyle

[tmarks11]

That is the problem with jumping on "beta software"; you become unpaid help in the debugging process prior to commercial release. OK if you are a hobbyist, but probably not OK if you depend on your machine to make money. Hopefully Tormach will get these issues straightened out soon and release the final product.

Why is BobCAD using cutter comp? That seems strange, since CAM should easily calculate required cutting geometry that accounts for cutter diameters without having to use cutter comp. IMHO, cutter comp is only to make hand coding easier.

Doubly strange since cutter comp doesn't work right in MACH3, so I am surprised that BOBCAM g-code with cutter comp would have worked correctly previously.

I have two words for you "HSM Express". Awesome integrated CAM software for SW.

[Concepts_Design]

Bobcam has the options to use system comp or machine comp, so it works either way.

HSMexpess was what I was using but I need 3D and 4 axis and HSMworks price is way out of my range

That is the problem with jumping on "beta software"; you become unpaid help in the debugging process prior to commercial release. OK if you are a hobbyist, but probably not OK if you depend on your machine to make money. Hopefully Tormach will get these issues straightened out soon and release the final product.

Why is BobCAD using cutter comp? That seems strange, since CAM should easily calculate required cutting geometry that accounts for cutter diameters without having to use cutter comp. IMHO, cutter comp is only to make hand coding easier.

Doubly strange since cutter comp doesn't work right in MACH3, so I am surprised that BOBCAM g-code with cutter comp would have worked correctly previously.

I have two words for you "HSM Express". Awesome integrated CAM software for SW.

[tmarks11]

HSMexpess was what I was using but I need 3D and 4 axis and HSMworks price is way out of my range

Yep, that will do it.

If you turn off machine comp in BobCAD, doe the post-processor work with PP? I don't see any advantage to using cutter comp when using CAM to generate g-code for your Tormach.

[Concepts_Design]

even with machine comp turned off it still didn't work with the original post. after modifying it quite a bit it would work, but PP didn't like any of the lead in's and out's so it was still throwing errors

Yep, that will do it.

If you turn off machine comp in BobCAD, doe the post-processor work with PP? I don't see any advantage to using cutter comp when using CAM to generate g-code for your Tormach.

[popspipes]

Sprutcam also works well, I had a transformation tapping entry it didnt like, but selecting each of the holes it worked fine. I have one other error but it ignores that one, but it does shows up in the status line.

Sprut will do 4th axis and 3d and it is reasonably priced.

[tmarks11]

even with machine comp turned off it still didn't work with the original post. after modifying it quite a bit it would work, but PP didn't like any of the lead in's and out's so it was still throwing errors

This was the issue of the arc radius being too tight from PP point of view?

Post an error on their beta webpage and see what they say.

I didn't realize that BOBCAM offered a plug-in for SW. What do you think about it vs. the HSM Express that you had used for 2.5D?

[popspipes]

I have never use cutter comp, I just size the tool accordingly in cam, seems to work fine.

[shred]

The regular Bobcad Mach post needed tweaking to run with PP but only to add things like the G64 and take out some of the illegal codes that Mach ignored.

[Concepts_Design]

The regular Bobcad Mach post needed tweaking to run with PP but only to add things like the G64 and take out some of the illegal codes that Mach ignored.

that may be the case with bobcad, but for bobcam for solidworks it was much more than that. I would have thought that their posts would be the same but maybe since my version runs in Solidworks they are different

[C*H*U*D]

First part with PathPilot 1.6, first error. For some reason it does not like this line from Sprut:

N80 G0 G94 X0.375 Y-0.475 Z0.1 H1

It gives me an error saying, "G-Code error near line: 21. H word with no G43 or G76 to use it.

Any ideas?

[tmarks11]

Well the H1 is the height offset of the tool, which would be set with G43. It should be in the same line as a G43. But that is not the only issue...

It is really weird to set that offset in anything other than a tool change line (i.e. M06), as changing the offset generally only happens when the tool changes, and that line has the height set at 0.1", so it could be a disaster waiting to happen if you tried to fix it by simply putting a G43 in front of it.

Is there a tool change line (M06) in the line before it?

[C*H*U*D]

This is why I don't understand the Mach post processor not working...it's from the PP FAQ:

Will my CAM systems Mach3 postprocessor work with PathPilot?

Yes, it will. PathPilot and Mach3 share the same syntax, with the exception of subroutine programming.

Has this changed? Is there a new post?

[Philbobb]

This is why I don't understand the Mach post processor not working...it's from the PP FAQ:

Will my CAM systems Mach3 postprocessor work with PathPilot?

Yes, it will. PathPilot and Mach3 share the same syntax, with the exception of subroutine programming.

Has this changed? Is there a new post?

If it was legally formatted g-code coming out of the same post processor, it won't have a problem. Mach let you get away with some "illegal" formatting, PP won't. That's why you're having the issue.

[C*H*U*D]

If it was legally formatted g-code coming out of the same post processor, it won't have a problem. Mach let you get away with some "illegal" formatting, PP won't. That's why you're having the issue.

So then, what Tormach said in the FAQ is incorrect. PathPilot will not work with the Mach post processor for SprutCAM.

[C*H*U*D]

Here is the first tool operation. I guess I'm wondering why this worked with Mach and not with PP?

%
ORear Suspension Mount

(Tool) (2) (Diameter)(0.098) (@.098" Drill Bit) (Operation) (Hole machining)
(Tool) (3) (Diameter)(0.12) (@.120" Drill Bit) (Operation) (Hole machining2)
(Tool) (1) (Diameter)(0.25) (@.250" Endmill) (Operation) (Roughing waterline)
(Tool) (1) (Diameter)(0.25) (@.250" Endmill) (Operation) (2D contouring)
(Tool) (1) (Diameter)(0.25) (@.250" Endmill) (Operation) (Pocketing)
(Tool) (4) (Diameter)(0.25) (@45 degree chamfer) (Operation) (2D contouring2)

N10 (Postprocessor: )
N20 G90 G54 G64 G50 G17 G40 G80 G49
N30 G20 (Inch)
(Hole machining)
N40 G54
N50 M998
N60 T2 G43 H2 M6
(.098" Drill Bit)
N70 S10000 M3
N80 G0 G94 X0.375 Y-0.475 Z0.1 H1
N90 G0 M8
N100 G98 G83 Z-0.45 R0.1 Q0.125 F42.6 P0.5
N110 X2.125
N120 G80
N130 M5 M9 (Inch)
N140 (Inch)
(Hole machining2)
N150 M998
N160 T3 G43 H3 M6

[shred]

Yea, Mach ignores a lot of bad G-code. PP will error on it.

Same Syntax yes, error handling no.

[tmarks11]

You should be thankful that PP faulted rather than tried to execute that. Adjusting the height offset without changing a tool would have caused the tool to plunge 1" into the workpiece on the next z movement (as the height offset changed from 2" to 1"... or would have if there was a G43 in that line).

PP should not execute that as written, as it is clearly written wrong.

Ignoring faulty g-code is generally a bad practice for machine tools to make, as a typographical error incorrectly recognized and executed (or skipped) could have disasterous consequences. Much better to fault if something is not recognized than try to muddle through it.

Did your Sprut post-processor come from Tormach?

[C*H*U*D]

You should be thankful that PP faulted rather than tried to execute that. Adjusting the height offset without changing a tool would have caused the tool to plunge 1" into the workpiece on the next z movement (as the height offset changed from 2" to 1"... or would have if there was a G43 in that line).

PP should not execute that as written, as it is clearly written wrong.

Ignoring faulty g-code is generally a bad practice for machine tools to make, as a typographical error incorrectly recognized and executed (or skipped) could have disasterous consequences. Much better to fault if something is not recognized than try to muddle through it.

Did your Sprut post-processor come from Tormach?

I totally agree. I always do my first run with my hand on the Estop, but you are right...I'm happy that PathPilot caught it.

The post I am using did come from Tormach. It's PCNCMasterPostRev1.5. I received an email back from them, and they said they do not have the ability to make changes to the post for SprutCAM 7 Pro, and I would have to upgrade to 9. There is no upgrade to 9 from 7, only from 8 to 9 so I'm still exploring some options. I really don't want to plunk down $1,250 for the full version of 9.

[TurboStep]

I totally agree. I always do my first run with my hand on the Estop, but you are right...I'm happy that PathPilot caught it.

The post I am using did come from Tormach. It's PCNCMasterPostRev1.5. I received an email back from them, and they said they do not have the ability to make changes to the post for SprutCAM 7 Pro, and I would have to upgrade to 9. There is no upgrade to 9 from 7, only from 8 to 9 so I'm still exploring some options. I really don't want to plunk down $1,250 for the full version of 9.

That's heavy!
From the price you quoted for v9 I'm assuming you have the PCNC Posts only version. Ive no idea how this version is restricted, but if I can reproduce the problem I can probably create a modified post for you to try. I'll see what I can do.
step