On Mon, Oct 10, 2016 at 5:52 AM, Dan W engnerdan@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

I have never come across a piece of industrial  cam software that will put a length offset into the program. 

The problem is each time you wear out of break a cutting tool you would have to re post the G-code.  

Cam software will put in the radius offset but not length. 

Dan

Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone

Group: DynoMotion	Message: 13797	From: peterpan1e6	Date: 10/10/2016
Subject: Re: G43.1 Tool Length Offset

Thanks Dan Most CAM systems have post processors so it is possible to write the tool length to GCode. We have been doing that with the controller prior to upgrading to KMotion, for machines not fitted with a tool offset probe. In any case, the CAM system needs to have all the tool data such as tool steel, tool and holder dimensions, number of cutters, etc. This is substantially more comprehensive than the tool table in KMotionCNC. It also keeps the library for multiple machines. Not all the machines are the same and neither are the tools so we have to generate the G-code depending on which machine the job runs. And if the tool breaks you can replace the tool and edit the offset in the G-code so it is not necessary to regenerate it for that job on that machine. So it makes sense for us to use the CAM system as the master tool library. But this means we have to manually maintain two libraries for each machine only to be able to set the tool offset in the KMotion tool table. One alternative is to update the KMotionCNC Tool table with the corresponding offsets. I looked at the program TestChangeToolOffset.c as it looks like the tool number can be passed via the M6 command. Is there a way to write to the a persistent variable from G-code so the offset value can be shared? Failing that I can write code to read the CAM table, extract the tool No and length and generate a KMotion Tool table. Before doing that I just wanted to check if there was not an easier way that I was missing, to support the functionality of G43.1. Regards

Group: DynoMotion	Message: 13799	From: engnerdan	Date: 10/10/2016
Subject: Re: G43.1 Tool Length Offset

I guess I am still lost how you are setting things us. But there is always more ways than one to skin the proverbial cat. My personal experience is with 3 different machine makers and 4 different CAM softwares. Machines My Dynomotion power bed mill Haas VF2 Mazak VNC 510 Mazak VNC 530 CAM software HSM Express in Solidworks HSM Works in Fusion 360 Mastercam X8,X9 and a little Gibbs CAM The VF2 is my most used machine and HSM Express my go to for CAM. I have tool tables built for each machine in HSM express and within those tables I may have 3 end mills all defined as tool 10, one for slotting, one for high speed machining, and one for profiling each with the parameters for that style operation. Alternately I might have 3 or 4 of the same tool number each defining a different material like Stainless, tungsten, steel, P20 steel. While it is not the cleanest solution it does work. If all I was doing was programming I would most likely make a master library for each material and cutting tool I frequently use and then copy from there to a library for each machine. If you have never used a Mazak with a Mazatrol program, they actually do away with tool numbers and go by tool descriptions. In a program a tool might be defined as a 0.500" inch end mill with a 0.030" radius. In which case any tool in the tool changer with that description can be used. But that is all I know about the Mazatrol programs, never wrote one, I always went the G-Code route when running parts on the Mazaks. But even here the tool length offsets are touched off in the machine and stored in the machine. Anyways enough about that, good luck with your setup and machines. -Dan

Group: DynoMotion	Message: 13813	From: Tom Kerekes	Date: 10/10/2016
Subject: Re: G43.1 Tool Length Offset

Hi, KMotionCNC doesn't currently support any direct way to set a tool offset from GCode. I suppose you could do it with an M Code and KFLOP C Program.  Your post could create a call to an MCode with 3 parameters P Q R for X Y Z Tool Offsets.  ie M100 Pxxxx Qyyyy Zzzzz The C Program for M100 could alter the Tool Table using a method like ToolTableSet.c which could call  functions SetToolLength, SetToolOffsetX, and SetToolOffsetY for Tool #1. Regards TK On 10/10/2016 11:16 AM, eondekoker@... [DynoMotion] wrote:   Thanks Dan Most CAM systems have post processors so it is possible to write the tool length to GCode. We have been doing that with the controller prior to upgrading to KMotion, for machines not fitted with a tool offset probe. In any case, the CAM system needs to have all the tool data such as tool steel, tool and holder dimensions, number of cutters, etc. This is substantially more comprehensive than the tool table in KMotionCNC. It also keeps the library for multiple machines. Not all the machines are the same and neither are the tools so we have to generate the G-code depending on which machine the job runs. And if the tool breaks you can replace the tool and edit the offset in the G-code so it is not necessary to regenerate it for that job on that machine. So it makes sense for us to use the CAM system as the master tool library. But this means we have to manually maintain two libraries for each machine only to be able to set the tool offset in the KMotion tool table. One alternative is to update the KMotionCNC Tool table with the corresponding offsets. I looked at the program TestChangeToolOffset.c as it looks like the tool number can be passed via the M6 command. Is there a way to write to the a persistent variable from G-code so the offset value can be shared? Failing that I can write code to read the CAM table, extract the tool No and length and generate a KMotion Tool table. Before doing that I just wanted to check if there was not an easier way that I was missing, to support the functionality of G43.1. Regards

Group: DynoMotion	Message: 13821	From: peterpan1e6	Date: 10/11/2016
Subject: Re: G43.1 Tool Length Offset

Thanks Tom Yes, this can work. Is there a program I can look at to see how to declare and handle the PQR variables being passed to the C program?  The programs I have written so far did not pass parameters.

Group: DynoMotion	Message: 13822	From: Hardy Family	Date: 10/11/2016
Subject: Re: G43.1 Tool Length Offset

That seems very complicated. What was wrong with using global offsets instead of tool offsets?  Most post processors won't program or use the G92 offsets, will they? Regards, SJH On Tue, Oct 11, 2016 at 1:10 PM, eondekoker@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:   Thanks Tom Yes, this can work. Is there a program I can look at to see how to declare and handle the PQR variables being passed to the C program?  The programs I have written so far did not pass parameters.

Group: DynoMotion	Message: 13825	From: Tom Kerekes	Date: 10/11/2016
Subject: Re: G43.1 Tool Length Offset

Have you looked at the M Codes with Parameters Example? http://dynomotion.com/Help/KMotionCNC/MCodesWithParams.htm Regards TK On 10/11/2016 1:10 PM, eondekoker@... [DynoMotion] wrote:   Thanks Tom Yes, this can work. Is there a program I can look at to see how to declare and handle the PQR variables being passed to the C program?  The programs I have written so far did not pass parameters.

Group: DynoMotion	Message: 13835	From: peterpan1e6	Date: 10/12/2016
Subject: Re: G43.1 Tool Length Offset

Thanks This helps. I only saw the program which prints the M code number so this helps to see how the PQR parameters are handled. Another question: the VAR number specified in the example is 0 but the persist memory used in the example is 0,1 and 2 for the 3 parameters. What will happen when another program uses VAR 1 or 2? Will the Q and R variables be overwritten as it is global? If so, one has to be careful when specifying the VAR parameters. Regards

Group: DynoMotion	Message: 13840	From: Tom Kerekes	Date: 10/12/2016
Subject: Re: G43.1 Tool Length Offset

If something writes to a persist Variable and and something else write to the same Variable then the value will be overwritten. However in your case it shouldn't matter as the Variable values are immediately used to set the Tool Table and then are no longer needed.  If something else was to operate in parallel and use the Variables at the same time then there could be a problem.  So to be safe use different Variables for different functions. HTH Regards TK On 10/12/2016 1:21 AM, eondekoker@... [DynoMotion] wrote:   Thanks This helps. I only saw the program which prints the M code number so this helps to see how the PQR parameters are handled. Another question: the VAR number specified in the example is 0 but the persist memory used in the example is 0,1 and 2 for the 3 parameters. What will happen when another program uses VAR 1 or 2? Will the Q and R variables be overwritten as it is global? If so, one has to be careful when specifying the VAR parameters. Regards

Group: DynoMotion	Message: 13843	From: peterpan1e6	Date: 10/12/2016
Subject: Re: G43.1 Tool Length Offset

Thanks Tom I have tried the following: M100 P3 Q77.34  (using VAR 0) so P is the tool number and Q is the length offset. In the C code I tried int myint; myint=(int)&persist.UserData[0]; SetToolLength(myint,&persist.UserData[1]); but this is not working. Any idea?

Group: DynoMotion	Message: 13846	From: Tom Kerekes	Date: 10/12/2016
Subject: Re: G43.1 Tool Length Offset

You code is basically using the & operator to get the memory address of what you want rather than the thing you want. This is one of the more difficult C Programming concepts to get.  It is complicated by the fact that the persist variables are declared to be 32 bit integers but KMotionCNC puts a 32-bit floating point value into it.  So we need to trick the C compiler into accessing it as a float.  To do that we: #1 take the address of the variable we want with the '&'='Address of' operator #2 declare the address to be a pointer to a floating point value with the '(float *)' casting operator #3 then tell the compiler to get the value that the pointer points at with the de-reference operator '*' Try the code below: #include "KMotionDef.h" #define TMP 10 // which spare persist to use to transfer data #include "KflopToKMotionCNCFunctions.c" main() {     int ToolTableIndex = *(float *)&persist.UserData[0];     float Length = *(float *)&persist.UserData[1];     SetToolLength(ToolTableIndex,Length); } Unfortunately there is another difficulty (or not).  The SetToolLength requires the Index into the Tool Table (not the Slot or Tool ID).  That is sort of like the line number of the tool table.  Index=0 would be the first line in the Tool Table. Does this work for you?  Either you would need a fixed Tool Table Layout with a known Line Number/Tool Number.  Or you could just always use Line 0 of the Tool Table.  Which would always be Tool #1.  Change the parameters for Tool #1 and then Use Tool #1 Regards TK On 10/12/2016 11:52 AM, eondekoker@... [DynoMotion] wrote:   Thanks Tom I have tried the following: M100 P3 Q77.34  (using VAR 0) so P is the tool number and Q is the length offset. In the C code I tried int myint; myint=(int)&persist.UserData[0]; SetToolLength(myint,&persist.UserData[1]); but this is not working. Any idea?

Group: DynoMotion	Message: 13852	From: peterpan1e6	Date: 10/13/2016
Subject: Re: G43.1 Tool Length Offset

Thanks Tom I do C# and VB, so your explanation is appreciated. In terms of the Tool Table, I see there is a sorting function. From your explanation this means for example the Tool index can be different depending on the sorting? If someone adds a tool and is not careful, it can have expensive consequences. Would it not be better to update the Tool offset by using the ToolID instead of the table index? Surely the Tool Length is related to the Tool (and not the slot or index) and each tool should have a unique ID. So then it does not matter which slot the tool is in at any time or the index it has in the table. This would work well with our Tool Library as each tool has a unique ID.  Maybe you can consider a function SetToolLengthID which will use the corresponding ToolID and not the Tool  table index? (By the way, I found that the tool table accepts tools with duplicate ID's which sort of defeats the purpose?) Regards Eon

Group: DynoMotion	Message: 13870	From: Tom Kerekes	Date: 10/13/2016
Subject: Re: G43.1 Tool Length Offset

Hi Eon, It seems in LinuxCNC G43.1 requires the current tool to be selected and then it modifies the Offsets for that tool. http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G43_1 If that is the case then you might use:     GetMiscSettings(&Units, &TWORD, &HWORD, &DWORD); to retrieve the table index for the selected tool and then modify the parameters for the selected tool. Could that work for you? Regards TK On 10/13/2016 12:52 AM, eondekoker@... [DynoMotion] wrote:   Thanks Tom I do C# and VB, so your explanation is appreciated. In terms of the Tool Table, I see there is a sorting function. From your explanation this means for example the Tool index can be different depending on the sorting? If someone adds a tool and is not careful, it can have expensive consequences. Would it not be better to update the Tool offset by using the ToolID instead of the table index? Surely the Tool Length is related to the Tool (and not the slot or index) and each tool should have a unique ID. So then it does not matter which slot the tool is in at any time or the index it has in the table. This would work well with our Tool Library as each tool has a unique ID.  Maybe you can consider a function SetToolLengthID which will use the corresponding ToolID and not the Tool  table index? (By the way, I found that the tool table accepts tools with duplicate ID's which sort of defeats the purpose?) Regards Eon

Group: DynoMotion	Message: 13873	From: peterpan1e6	Date: 10/13/2016
Subject: Re: G43.1 Tool Length Offset

Thanks Tom I saw that in the ToolTableSet.c program but I could not figure out what is does or how to use it.  I guess TWORD is the selected tool? So this means the GCode is T4 M100 P4 Q70  (which uses TWORD=4   GetMiscSettings(&Units, &TWORD, &HWORD, &DWORD); SetToolLength(TWORD,NewToolLength); ) G43 H4  But now I cannot figure out which parameter refers to the ToolTableIndex?

Group: DynoMotion	Message: 13875	From: Tom Kerekes	Date: 10/13/2016
Subject: Re: G43.1 Tool Length Offset

Well in this case there is no need to use the P parameter to pass the Tool Slot to KFLOP.  The TWORD will be the Tool Table Index of Tool #4, so SetToolLength(TWORD,NewToolLength); should set the Length for Tool #4 wherever it is in the table. HTH Regards TK On 10/13/2016 2:12 PM, eondekoker@... [DynoMotion] wrote:   Thanks Tom I saw that in the ToolTableSet.c program but I could not figure out what is does or how to use it.  I guess TWORD is the selected tool? So this means the GCode is T4 M100 P4 Q70  (which uses TWORD=4   GetMiscSettings(&Units, &TWORD, &HWORD, &DWORD); SetToolLength(TWORD,NewToolLength); ) G43 H4  But now I cannot figure out which parameter refers to the ToolTableIndex?

Group: DynoMotion	Message: 13876	From: peterpan1e6	Date: 10/13/2016
Subject: Re: G43.1 Tool Length Offset

Soo simple... I will give it try! Thanks