[visky]

I am having problems with radius comp. G41 .
Watch this program and tell me where is a problem.
I am running EMC 2.2.5

[HuFlungDung]

You need to call the workshift G54 (or whatever).

You'd need a callout for the length compensation, for example
G43 H4 for your length offset.

You'd need a clearance plane (in Z) for the tool to approach the start point.

You'd need to call G41 D4 for the tool radius compensation register, and ensure that you actually have the tool radius entered in that register.

[visky]

I tried this but doesnt help.
I am fighting with concave corner and cutter gouging error codes.
If i left tool diameter 0.00 it works ,but when i change it 0.02 inch i get concave corner error message.
tool diameter shuld be 0.023 inch or 0.6mm

I will give nc code ( it is PCB milling code )

Tell me if i have a change to mill this board with cutter compensation or not

[acondit]

I tried this but doesnt help.
I am fighting with concave corner and cutter gouging error codes.
If i left tool diameter 0.00 it works ,but when i change it 0.02 inch i get concave corner error message.
tool diameter shuld be 0.023 inch or 0.6mm

I will give nc code ( it is PCB milling code )

Tell me if i have a change to mill this board with cutter compensation or not

You cant use cutter radius compensation to cut to the inside of any concave corner (angle between 0 and 180 degrees). You have to convert a corner to a radius greater than the radius of the milling cutter.

Alan

[acondit]

I am having problems with radius comp. G41 .
Watch this program and tell me where is a problem.
I am running EMC 2.2.5

Here is your original file modified to work with cutter compensation (outside rather than inside). At least this will give you an example of changing a concave corner to a radius.

[Andre' B]

You cant use cutter radius compensation to cut to the inside of any concave corner (angle between 0 and 180 degrees). You have to convert a corner to a radius greater than the radius of the milling cutter.

Alan

And I really wish they would consider that the bug that it is.
Every modern control I have programmed for will do it if the parameters are set correctly which is generally the default settings.

It really makes writing macro type pocketing programs difficult, you have no idea what size end mill the user is going to use. So you need to have the tool radius/dia. as a parameter passed in to the macro, which means the user needs to enter that data in two locations (EMC also does not make the tool table data available to macros) or just not use the rad comp and do it all in the macro, which means lots of trig calculations in the macro.

[lerman]

And I really wish they would consider that the bug that it is.
Every modern control I have programmed for will do it if the parameters are set correctly which is generally the default settings.

It really makes writing macro type pocketing programs difficult, you have no idea what size end mill the user is going to use. So you need to have the tool radius/dia. as a parameter passed in to the macro, which means the user needs to enter that data in two locations (EMC also does not make the tool table data available to macros) or just not use the rad comp and do it all in the macro, which means lots of trig calculations in the macro.

No... When you design a part, you need to specify the maximum radius of the internal corner. Write the macro to match that specification. Then use a cutter of that radius or smaller. If you try to cut it with a larger radius tool, you should get an error. You don't need to change the macro when you change the tool size.

When you specify a part with a zero internal radius, you can't cut it unless you have a tool of zero radius. That's what is happening here.

[Andre' B]

No... When you design a part, you need to specify the maximum radius of the internal corner. Write the macro to match that specification. Then use a cutter of that radius or smaller. If you try to cut it with a larger radius tool, you should get an error. You don't need to change the macro when you change the tool size.

When you specify a part with a zero internal radius, you can't cut it unless you have a tool of zero radius. That's what is happening here.

Then you should go tell the little guys of control manufacturers like Fanuc, Mitsubishi, etc. that they have all been doing it wrong for the last few decades. And that programs running on controls all over the world are just all wrong.
Here is a Mit M300V Manual relavant stuff starts about page 112 of the PDF, page 100 of the scanned book.

[lerman]

Then you should go tell the little guys of control manufacturers like Fanuc, Mitsubishi, etc. that they have all been doing it wrong for the last few decades. And that programs running on controls all over the world are just all wrong.
Here is a Mit M300V Manual relavant stuff starts about page 112 of the PDF, page 100 of the scanned book.

I wouldn't suggest that it is wrong for a controller to support that; but I think it is wrong for a part programmer to depend on it. The whole point of cutter radius compensation is to get produce the same part without caring about the cutter diameter (within some range).

Failing to specify an inside radius defeats the idea of cutter radius compensation.

If I design a part with a sharp inside corner, I expect to get that part; I dont expect to get a part with a .250 or .240 internal radius depending on how many times the cutter had been resharpened.

If you are manually programming parts, I can understand that using this feature can save you time. Nowadays, though, the part should be drawn with a CAD program and the gcode generated automatically.

Ken

[Andre' B]

It is not the part design process as much as the machining process. I do lots of family part programs with lots of subs and macros. So that the machine operator can stand at the machine and grab a shop order punch a few numbers into the calling program run the 1 or 2 parts (with maybe a 2 or 3 minute cycle time) to fill the order, rinse and repeat. No time for messing with CAM software and loading new G-Code to the machine for each order. Once and a while a big order for 10 or 20 parts may come thru.

EMC or any control should be as flexible as possible and should not be a limitation on how a part is designed, or machined.

Say you do a lot of rectangular pockets. Most of the time radius on an internal corner is not that big of a deal and the CAD driver realizes he/she is going to get whatever radius in on the tool used, at most he/she may put a min and/or max rad callout on the drawing.
So you write a macro and put it in a sub program which is always in the machine and can be called by any program. You want the corner radius to be whatever the rad is on the end mill the operator/setup person picks. For one part they may be using a 0.050" diameter end mill and the next it may be a 1" diameter. There is no way to know at the time you are writing the macro in the sub. And it defeats the purpose of using subs if you have to edit it every time you use it.
If there was a way to get the tool radius from the tool table (like you can on any main stream control, #[13000+2] gives me the radius of tool 2 on the Daewoo sitting 100' from me) then the corner rads could be built into the macro, some small % larger then the tool.

The only way I know to do it will EMC is to require the operator to enter the tool radius in the tool table AND the same number into the program as a parameter being passed to the sub. A procedure which leads to errors by the operator.
So with EMC I would end up skipping the tool table and tool table and the G41/42 and just do the rad comp in the macro which on a complex tool path can make for a lot of extra trig calculations in the macro.


Related issue, this code will run on any mill control I have run or programmed, but last time I checked EMC would error and I never found a way to make it work.
A useful bit of program to keep in a control for carving out vice jaws.

#100=5.0
#101=-1.0
()
G0 X0 Y0
G0 Z1.0
G0 Z0.1
G1 Z#101 F50.0
G1G41 X#100 D1.0 F10.0
G3 I-#100 F20.0
G1G40 X0 F50.0
G0 Z1.0

Got to go, back on Tuesday.

[samco]

The emc group is working on this... (so you don't have to draw the original file 'correctly') It is not done yet and help is appreciated


or extreme

[lerman]

Andre,

I appreciate your thoughtful response and now understand the problem a little better. As far as your sample program is concerned, I haven't actually tried it, but this seems to be a problem

G3 I-#100 F20.0

After an "I", you must have either a number or an expression. Change that to:
G3 I[0-#100] F20.0

Have a great holiday.

Ken

[Andre' B]

The emc group is working on this... (so you don't have to draw the original file 'correctly') It is not done yet and help is appreciated

Most cool.

One of these days I would like to get a computer setup for some development work and do more then just whining.

Problem is keeping it up to date, no web at home, phone company wants a few thousand to run wire thru the woods to the house and every time I talk myself into a sat link I hear another story about bad service. Price on the sat hardware is down to the point it would no be a major lose but they still want a multiyear contract.

Samco I am north of you about 150 miles near Amery.

[Andre' B]

G3 I-#100 F20.0

After an "I", you must have either a number or an expression. Change that to:
G3 I[0-#100] F20.0

Have a great holiday.

Ken

That is a typo, !@#$% on my playing with EMC I have gotten so I always put variable stuff inside [] on the controls I use most the I-#100 will work but others do not like it and have to be I[-#100]. I think EMC will spit that out also, seems to be a problem in how much AI is built into the interpreter.
The problem on EMC (as I remember) was the G41 line.

Seeeeeeya



For real this time.

[lerman]

...snip...



If there was a way to get the tool radius from the tool table (like you can on any main stream control, #[13000+2] gives me the radius of tool 2 on the Daewoo sitting 100' from me) then the corner rads could be built into the macro, some small % larger then the tool.
...snip...

Making it so that tool table values are accessible as parameters should be pretty simple. I will add that to my list of things to do if someone will write the enhancement request and assign it to me.

Ken

[skullworks]

Read access would be a great start.

But It needs to be implemented in a way that will also allow write functions.


Referring to mill type tool tables...

G10 L1 has many different formats due to the differring types of offset tables in use. ie: does the offset table have entries for wear offsets in addition to geometry or are the offsets just a list that can be used as either H or D.

I would propose that the format be as follows:

G10 (G90) L1 P1 H##### D#####

Where P1 is the FMS#, H is the actual TLO and D is the tool dia.

G10 (G91) L1 P1 H##### D#####

Where P1 is the FMS#, H is the signed amount of change to the existing TLO entry and D is the signed amount of change for the tool dia.

In both cases only a H or D entry is required as a minimum.

One possible issue with write access is when will EMC re-read the tool table so the changes will take effect. On most commerical controls D values require a G40 then G41|G42 for a same D# or just a G41|G42 if using a new D#.

Same goes for G43 H values - a G49 would be required for the same H# or a G43 H for a different H value.

At present I think EMC only reads the tool table on startup - but that info may be well out of date.

--- If you want me to write this up as a feature request I would be glad to.