Advanced Search

Andy

I am not able to test that out at the moment but seriously i do not tell it to add those statements. It would be worth having a go yourself as this would help with another experience from somebody else. DXFtoGcode runs from Python scripts so no install required. GCNCCAM needs to be installed. there is nothing that gets saved to EMC from either just NC code to be opened in EMC

2e0poz wrote:

Any compensation is done by the CAM software.

I am not sure that is true, the first file you posted had a G42 at the beginning, which turns on diameter compensation.
It is possible that the two bits of software are fighting each other, with one using G42 compensation, and the other offsetting those lines again.

Does the output look OK if you comment out any G41 and G42 statements?

Andy

i think there maybe some confusion here, the code that has been generated has been done purely from the cam software (available from this site). The only input required is specifying the tool diameter and length, speeds and feeds etc. This is not done in the G code directly.

DXFtoGcode

specify tool diameter, speeds, feeds, etc. Which side to cut of the line done on the drawing then export the code.

GCNCCAM

You create a template of the above then open the drawing, specify which layer is cut first then build the code automatically and save. Any compensation is done buy the CAM software.

This is why i find it strange that if create a new machine profile and run the code generated from either of these it works fine first time. If i then load up some new code generated from either of these it errors with the gouging corner etc etc. I don't feel i have been doing anything different from last year on my first machine using 8.04 and never saw errors like this.

You might want to give SheetCAM a go.
It is commercial software, but you can do some stuff in the demo mode. (And there is a Linux version)
www.sheetcam.com/index.shtml

Do the CAM packages you are using have an option not to use diameter compensation (ie to do the compensation in the CAM package). Diameter compensation is great if you want to run the same G-code day after day and simply measure the tool and adjust the tool table for wear, but I have generally found it to be more trouble than it is worth.

The problem I have found with G42 is the requirement for entry moves, and it may be that the CAM software is not doing those very well.

Here is the drawing

Yes John it does ask for the diameter and also GCNCAM it also asks which you set up in the template. With this you have to match the tool table in EMC against tool numbers. It's a shame that these projects don't seem to be still running as for simple stuff they are ideal.

I just ran a dxf file through dxf2gcode and if the start radius was not bigger than the tool diameter it didn't generate a long enough entry move and EMC politely complained that I was a dufus and didn't know how to write g code .

You might play with the settings in dxf2gcode a bit.

John

2e0poz wrote:

I set up code again using DXFtoGcode and GCNCCAM (tried both) and still get the same results with smaller cutters. Silly question now but surely if the cutter is smaller in diameter than the smallest hole or curve you want to cut it should work right?

When you say "I set up code again" does DXFtoGcode want to know the cutter diameter? I've not used either of those programs yet so I'm in the dark here. Is it generating software offsets in the post processor part? Did you change the cutter diameter in the tool table before running the code?

Can you attach the dxf file so we can look at it?

John

Andy

That explains things much clearer, like most people i am always in huge rush with never much time to spare. Writing code by hand will be possible for me as it is not that difficult to learn. i spent a lot of time getting to a point of cutting with my build and not had the opportunity to spend a lot of time on the software aspects. X/Y movements are easy to see visually but the arc movements are not. This is why i think it is easy to misinterpret with what you think is happening. I WILL calm down now and learn more and understand there are limitations with free cam software.

Thanks again

Paul

I am no expert on this, I write all my G-code so far by hand (and I tend to not use diamter compensation, partly for reason of the complexity you are finding)
It is possible that the diameter of the cutter needs to be smaller than the radius of the hole, not the diameter. However that would only be the case if EMC checked the tool outline against the metal already removed, not the path, and I am pretty sure that EMC doesn't try to do that.

I wonder if this line:
"If the tool is already covering up the next XY destination point when cutter radius compensation is turned on, the gouging message is given when the line of NC code which gives the point is reached. In this situation, the tool is already cutting into material it should not cut."

from:
linuxcnc.org/handbook/gcode/diacomp.html

Is the problem?

Still confused here????

I set up code again using DXFtoGcode and GCNCCAM (tried both) and still get the same results with smaller cutters. Silly question now but surely if the cutter is smaller in diameter than the smallest hole or curve you want to cut it should work right?

I like using QCAD as it is quick and simple for the 2D type drawings.
DXFtoGcode and GCNCcam keeps things simple for creating the code

Am i just using the wrong software tools for the job?

I've been trying to keep everything in Linux and don't really want to be using Windoze for anything if i can help it. Any suggestions?

Thanks

Paul

Guys

i think i understand now and can see i will be a while in getting to grips. As for Mach being more superior that i feel not, i do like the sound of the protection i am actually getting from EMC. I will have a play with the tools today and would like to thank you for clearing this up. This is what makes EMC a great community and not just a tool.

Many thanks

Paul

2e0poz wrote:

Just to note the drawing does no appear when i load the code just a small dit in the middle of the table (roughly where start position should be). Thanks for the feedback so far
Paul

Only that portion of g code that is runnable (no errors in coding) will display on the back plot. As soon as the error is discovered then the preview stops loading at that point and does not try and load any more. As Andy pointed out your code may run on other systems without gouge protection but you will not like the part when it is done.

John

2e0poz wrote:

T1 is set to 4.5mm in the tool table so still not sure the code can be at fault here.

But it is wrong.

Your first G2 move demands a 3.182mm diameter hole with diameter compensation active and a 4.5mm dia cutter.
(G2 is clockwise, G42 is cutter to the right)
That is simply not possible, and EMC2 points that out to you.

You say that the code runs fine in Mach, but I rather suspect that after that first move there isn't a 3.182mm diameter hole, there will be either a 4.5mm hole, or possibly a 5.818mm dia hole. The difference is not that Mach is superior to EMC2, but that it doesn't have gouging detection.

If you are trying to leave a 3.182mm dia "peg" then you need to either make the first cut a G3, or use G41 compensation.

I sent the code to a friend to run on Mah3 and it run straight out the box. I'm still confused why it would work fine if i create a new machine profile, it loads straight up and runs without a quibble? Should i be looking at any config files in EMC to see if any change before and after in the scenario i describe? Do machine offsets get written anywhere and not clear properly afterwards? Both the code generators produce similar code and the same thing happens regardless. John you said the code loads fine on yours? T1 is set to 4.5mm in the tool table so still not sure the code can be at fault here. It will have to wait till tomorrow but i will set some smaller bits to see what happens. Just to note the drawing does no appear when i load the code just a small dit in the middle of the table (roughly where start position should be). Thanks for the feedback so far
Paul