Re: [Emc-users] Effects of mode changes
Chris Radek schrieb: > On Sat, Apr 28, 2007 at 03:22:01AM -0400, Eric H. Johnson wrote: > >> 2> Similarly, if I issue "S3000 M3" in MDI mode, and then jog an axis which >> requires setting the mode to manual, the spindle turns off as soon as I >> start to jog. I assume that is from changing the mode from MDI to manual. Is >> there a way to issue the jog command which does not stop the spindle. > > Nope, unless you start it (using the nml command) after switching to > manual mode. I've also considered this a bug in the past, but was > told it was a feature. I'm still not sure it's a feature. Hmm, I would agree with you and say it's not (necessarily) a feature. Perhaps this behaviour could be made configurable? cu, sven - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Unexpected realtime delay
I made a module named Mlink under HAL,It uses the IRQ 10 and cycle time is 1 ms. Every time I start the emc2,it reports that unexpected time delay. I don't know why it happened?And does it influnce the realtime thread of emc2? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
Chris Radek wrote: [probe moves] > > It would be nice to be able to set tool length offset this way - but > > currently there is no way to do that, since lengths need to come > > from the tool table. Hmm, I'm still mostly a newbie regarding EMC. But does the above mean that EMC can't automatically correct for tool length differences unless you measure these in advance and store them in the tool table? Furthermore: If the lengths come from the tool table, what exactly keeps EMC from feeding the detected tool length differences into the tool table upon detection? Regards, Sven - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
On Sun, Apr 29, 2007 at 03:34:34PM +0200, Sven Mueller wrote: > Chris Radek wrote: > [probe moves] > > > > It would be nice to be able to set tool length offset this way - but > > > currently there is no way to do that, since lengths need to come > > > from the tool table. > > Hmm, I'm still mostly a newbie regarding EMC. But does the above mean > that EMC can't automatically correct for tool length differences unless > you measure these in advance and store them in the tool table? Well yes and no. In the part of my message you clipped, I mentioned that you could set a G10 offset using the result of a probe. But if you're talking about G43 tool length offset, that's right. As you can see here, http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_33a.html#1013768 G43 takes a tool number, not a length - so yes it is intended that you measure your tools (which are in holders) and put that information in the tool table. The G43 length is measured relative to a "reference" tool, and you use the reference tool when you set the coordinate systems, touch off to the work, etc. Yesterday sat down to change the interpreter so you can specify a length to G43. This is a simple change to make but I quickly found a couple problems/questions: Currently, G43 H- X- Y- Z- changes the tool offset and then causes motion to XYZ with the previously set motion type (G0,1,2,3). I don't see this behavior described in the ngc spec, but I'm afraid to use XYZIJK for something else if people use the current behavior. So that's problem 1 - I don't know how to allow specification of these lengths at the gcode level without breaking existing programs. (If you guys agree that an existing program that uses this behavior is NOT ngc, I'd feel less bad about breaking it.) Even if G43 can take a tool length directly, I couldn't come up with a straightforward way for the user to use that in gcode. Imagining the mill case first because it's simpler: maybe you'd store in a gcode variable the Z coordinate you get when you probe your reference tool. Then when you probe a new tool you'd take the difference and pass that to G43. But if someone doesn't have tool holders at all, I don't know what the reference tool would be, and with no reference tool I don't know what you'd use to touch-off the work. Tool length offset is just that - a length - and to measure a length you need to find the difference between two points. If you probe a tool tip, that's only one. This is problem 2 - I don't quite see a good way for someone to use G43 in this way, after we solve problem 1. Chris - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
On Sun, Apr 29, 2007 at 10:03:29AM -0500, Chris Radek wrote: > I don't know what the reference tool would be, and with no > reference tool I don't know what you'd use to touch-off the work. Replying to myself! Is it as simple as G49 insert any tool, touch off, set work coordinate system start program program probes first tool, THIS is the reference tool for this run program saves reference Z coordinate in a variable cut... program goes up to tool change height, prompts for next tool program probes this tool, this - reference => G43 cut... ... - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
Hi Chris, others. Really tool length is just part of the problem. A tool number is associated with both a tool length and a tool diameter which may or may not be nominal. So far I just grit my teeth and work thru the process. I have considered (briefly) a procedure to normalize the measured lengths against the reference tool and write that to the tool table. Dave On Apr 29, 2007, at 8:03 AM, Chris Radek wrote: > On Sun, Apr 29, 2007 at 03:34:34PM +0200, Sven Mueller wrote: >> Chris Radek wrote: >> [probe moves] >> It would be nice to be able to set tool length offset this way - but currently there is no way to do that, since lengths need to come from the tool table. >> >> Hmm, I'm still mostly a newbie regarding EMC. But does the above mean >> that EMC can't automatically correct for tool length differences >> unless >> you measure these in advance and store them in the tool table? > > Well yes and no. In the part of my message you clipped, I mentioned > that you could set a G10 offset using the result of a probe. But if > you're talking about G43 tool length offset, that's right. > > As you can see here, > http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_33a.html#1013768 > G43 takes a tool number, not a length - so yes it is intended that > you measure your tools (which are in holders) and put that > information in the tool table. The G43 length is measured relative > to a "reference" tool, and you use the reference tool when you set > the coordinate systems, touch off to the work, etc. > > Yesterday sat down to change the interpreter so you can specify a > length to G43. This is a simple change to make but I quickly > found a couple problems/questions: > > Currently, G43 H- X- Y- Z- changes the tool offset and then causes > motion to XYZ with the previously set motion type (G0,1,2,3). I don't > see this behavior described in the ngc spec, but I'm afraid to use > XYZIJK for something else if people use the current behavior. So > that's problem 1 - I don't know how to allow specification of these > lengths at the gcode level without breaking existing programs. (If > you guys agree that an existing program that uses this behavior is > NOT ngc, I'd feel less bad about breaking it.) > > Even if G43 can take a tool length directly, I couldn't come up with a > straightforward way for the user to use that in gcode. Imagining the > mill case first because it's simpler: maybe you'd store in a gcode > variable the Z coordinate you get when you probe your reference > tool. Then when you probe a new tool you'd take the difference and > pass that to G43. But if someone doesn't have tool holders at all, > I don't know what the reference tool would be, and with no > reference tool I don't know what you'd use to touch-off the work. > > Tool length offset is just that - a length - and to measure a length > you need to find the difference between two points. If you probe a > tool tip, that's only one. This is problem 2 - I don't quite see a > good way for someone to use G43 in this way, after we solve problem > 1. > > Chris > > > -- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
On Sun, Apr 29, 2007 at 08:27:00AM -0700, Dave Engvall wrote: > Hi Chris, others. > > Really tool length is just part of the problem. A tool number is > associated with both a tool length and > a tool diameter which may or may not be nominal. > So far I just grit my teeth and work thru the process. I have > considered (briefly) a procedure to normalize > the measured lengths against the reference tool and write that > to the tool table. > > Dave Dave, I think you and I have tool holders with tools in them pretty much permanently, and I agree it's a complex matter to measure them well, but no matter how we get it done, we can end up with the right data in the tool table and the current scheme in emc can work for us. There is another setup where the user has something like a dremel tool collet or jacobs chuck and a bunch of loose tools. I used to have this, and emc doesn't work very well with it. For this setup, using lengths from the tool table is useless. For radius, it's still possible to use the tool table though. For lengths, the user really wants to be able to stick in the tool and tighten it down, and have emc measure it and cut at the right height. I think we can do this pretty well with the probing, it's just a matter of details. Chris - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
Hi Chris, You are quite correct in assuming I have a series of tool holders; however I do a lot of one-off stuff in which the tooling outruns the number of tool holders I have. With the right probe and program we ought to be able to gage both length and diameter in a manner analogous to the laser setups that measure both length and diameter. Gaging the diameter is going to be the most difficult. After that as someone on this list once said: "it is simply a matter of software". Dave On Apr 29, 2007, at 8:35 AM, Chris Radek wrote: > On Sun, Apr 29, 2007 at 08:27:00AM -0700, Dave Engvall wrote: >> Hi Chris, others. >> >> Really tool length is just part of the problem. A tool number is >> associated with both a tool length and >> a tool diameter which may or may not be nominal. >> So far I just grit my teeth and work thru the process. I have >> considered (briefly) a procedure to normalize >> the measured lengths against the reference tool and write that >> to the tool table. >> >> Dave > > Dave, I think you and I have tool holders with tools in them pretty > much permanently, and I agree it's a complex matter to measure them > well, but no matter how we get it done, we can end up with the right > data in the tool table and the current scheme in emc can work for us. > > There is another setup where the user has something like a dremel > tool collet or jacobs chuck and a bunch of loose tools. I used to > have this, and emc doesn't work very well with it. For this setup, > using lengths from the tool table is useless. For radius, it's > still possible to use the tool table though. > > For lengths, the user really wants to be able to stick in the tool > and tighten it down, and have emc measure it and cut at the right > height. I think we can do this pretty well with the probing, it's > just a matter of details. > > Chris > > > -- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
Hi Chris, After thinking about it a bit. Are you proposing a tool referenced against the zero tool after every (manual) tool change? That would take time but would work for non-tool holder machines i.e. collet on the spindle as well as those of us with tool holders. Might make a really nice option. Dave On Apr 29, 2007, at 8:44 AM, Dave Engvall wrote: > Hi Chris, > > You are quite correct in assuming I have a series of tool holders; > however I do a lot of one-off stuff > in which the tooling outruns the number of tool holders I have. > With the right probe and program we ought to be able to gage both > length and diameter > in a manner analogous to the laser setups that measure both length > and diameter. Gaging > the diameter is going to be the most difficult. > After that as someone on this list once said: "it is simply a matter > of software". > > Dave > On Apr 29, 2007, at 8:35 AM, Chris Radek wrote: > >> On Sun, Apr 29, 2007 at 08:27:00AM -0700, Dave Engvall wrote: >>> Hi Chris, others. >>> >>> Really tool length is just part of the problem. A tool number is >>> associated with both a tool length and >>> a tool diameter which may or may not be nominal. >>> So far I just grit my teeth and work thru the process. I have >>> considered (briefly) a procedure to normalize >>> the measured lengths against the reference tool and write that >>> to the tool table. >>> >>> Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
On Sun, Apr 29, 2007 at 08:57:22AM -0700, Dave Engvall wrote: > Hi Chris, > > After thinking about it a bit. Are you proposing a tool referenced > against the zero tool > after every (manual) tool change? That would take time but would work > for non-tool holder machines > i.e. collet on the spindle as well as those of us with tool holders. > Might make a really nice option. > > Dave Yes that's what I propose would be possible if we allow G43 length specifiation directly in gcode as well as from the tool table. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Unexpected realtime delay
杜少华 wrote: > I made a module named Mlink under HAL,It uses the IRQ 10 and cycle time > is 1 ms. > Every time I start the emc2,it reports that unexpected time delay. > I don't know why it happened?And does it influnce the realtime thread of > emc2? > HAL uses periodic threads, not interrupts. I have no idea how you are using IRQ10 in a HAL based system, but it is probably confusing the time measurements that are used to calculate the "unexpected real delay" error. Regards, John Kasunich - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Gentlemen, I have started getting this message also. I start EMC and as soon as I move an axis I get this message. I haven't tried to troubleshoot this but if someone would like me to try or look at something on my machine, I will. thanks Stuart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
On Sun, Apr 29, 2007 at 11:26:29AM -0500, Stuart Stevenson wrote: > Gentlemen, > I have started getting this message also. I start EMC and as soon > as I move an axis I get this message. I haven't tried to troubleshoot > this but if someone would like me to try or look at something on my > machine, I will. > thanks > Stuart http://wiki.linuxcnc.org/emcinfo.pl?TroubleShooting - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] unexpected realtime delay
Stuart Stevenson wrote: > Gentlemen, > I have started getting this message also. I start EMC and as soon > as I move an axis I get this message. I haven't tried to troubleshoot > this but if someone would like me to try or look at something on my > machine, I will. > thanks There should be a multi-line message in 'dmesg' about that. It will be somewhere in the last 50 lines or so (dmesg can get very long). See section 2 of http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting for the next steps. Regards, John Kasunich - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
Chris Radek wrote: > Even if G43 can take a tool length directly, I couldn't come up with a > straightforward way for the user to use that in gcode. Imagining the > mill case first because it's simpler: maybe you'd store in a gcode > variable the Z coordinate you get when you probe your reference > tool. Then when you probe a new tool you'd take the difference and > pass that to G43. But if someone doesn't have tool holders at all, > I don't know what the reference tool would be, and with no > reference tool I don't know what you'd use to touch-off the work. > > Tool length offset is just that - a length - and to measure a length > you need to find the difference between two points. If you probe a > tool tip, that's only one. This is problem 2 - I don't quite see a > good way for someone to use G43 in this way, after we solve problem > 1. Hmm, I have a small hobby-grade CNC machine (a modified Proxxon MF70 from usovo.de) which doesn't have a tool holder. It came with PC/NC, a DOS program. This program takes the following approach for tool length corrections: It basically assumes that the first tool you use is the one you used to define your coordinate system. (PC/NC allows redefining X/Y/Z origins per g-code file, though this is a non-gcode manual process, which also involves options to define the working space, with an error issued when you g-code exceeds this working space. It also allows defining independent scaling for the X and Y axes, not sure about Z at the moment.) All origin, offset and working area settings are done before the first line of G-Code is executed. Anyway, the process in PC/NC works like this: Define working area in X, Y dimensions (machine coordinates), define origin in X, Y and Z (machine coordinates) for G-Code. This all usually happens with the first tool you intend to use. You need to measure the tool length before setting X/Y/Z origins and that tool length (or rather: The Z coordinate at whicht the tool hit the measurement switch) is used as a reference. Whenever PC/NC reaches another "M06 T?", it will _always_ measure the tool anew, even if it has a known length for that tool number. It then uses the difference in Z to correct the tool length. I would hope that EMC at one time also provides a similar functionality. Especially as manual tool changes are prone to errors with the depth to which a tool is inserted into the spindle. However, PC/NC also has problems with tool changes. Imagine the following G-Code: M06 T02 G01 X1 Y1 Z0 M06 T03 G01 X1 Y1 Z0 Looks pretty simple, doesn't it? Now, what happens in PC/NC? 0) (store current position) 1) move to tool change position 2) ask for tool to be changed (which you confirm) 3) move to stored position 4) move to maximum Z on measurement X/Y 5) measure tool 6) move to stored position 7) execute G01 X1 Y1 Z0 (and store that position) 8) move to tool change position 9) ask for tool change (which you confirm) 10) move to stored position (without correction, since it is not yet measured) 11) move to maximum Z on measurement X/Y 12) measure tool 13) move to stored position (with corrected tool length) 14) execute G01 X1 Y1 Z0 (with corrected tool length) Now imagine what happens it T03 is longer than T02. Right, it either breaks or damages the stock when (10) is done. Regards, Sven - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
Chris Radek schrieb: > On Sun, Apr 29, 2007 at 10:03:29AM -0500, Chris Radek wrote: >> I don't know what the reference tool would be, and with no >> reference tool I don't know what you'd use to touch-off the work. > > Replying to myself! Is it as simple as > > G49 > insert any tool, touch off, set work coordinate system > start program > program probes first tool, THIS is the reference tool for this run > program saves reference Z coordinate in a variable > cut... > program goes up to tool change height, prompts for next tool > program probes this tool, this - reference => G43 > cut... > ... Looks exactly like I would want it to work. It would be nice if this could be automated in M06 handling if no tool changer is defined, but any working recipe would work for me I guess. Regards, Sven - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
Dave Engvall schrieb: > Really tool length is just part of the problem. A tool number is > associated with both a tool length and > a tool diameter which may or may not be nominal. Right, but a tools diameter doesn't change, no matter what you do while you insert it. However, it's "felt" length might change if you don't insert it to the same depth each time. Though I could imagine a machine setup where even the tool diameter could be measured: Just first measure the length, then move the tip horizontally against a second switch. If you already measured another tool, you can take the horizontal difference between the two moves to detect the tools radius relative to the first tool. Regards, Sven - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
I guess I don't really see the issue here with tool length and diameter probing. Years ago now I wrote a little tickle script that allowed me to turn the probe switch over, pressed it with the tool and from the known height of that switch, wrote those values to the tool table and then reread the table. This could easily be done again from any of the guis. Tickle's automated menu would allow a user to add just the tool probe code to a directory and it would be useable from tkemc or mini. As for setting work offsets, that is easy enough now. You'll be hard pressed to find the correct xy location for a tool length measure because it really depends upon the tool being used. Imagine a drill vs a face mill or fly cutter and you should be able to see that a single xy location will not probe them both properly. Manual tool probing is really easy and is the way most of the commercial machines work anyway. I suppose there are some "lights out" shops that have a tool hive that replaces dull tools where the new ones require an automated tool measure but that is quite a way from where EMC is now. HTH Rayh On Sun, 2007-04-29 at 18:49 +0200, Sven Mueller wrote: > Chris Radek wrote: > > > Even if G43 can take a tool length directly, I couldn't come up with a > > straightforward way for the user to use that in gcode. Imagining the > > mill case first because it's simpler: maybe you'd store in a gcode > > variable the Z coordinate you get when you probe your reference > > tool. Then when you probe a new tool you'd take the difference and > > pass that to G43. But if someone doesn't have tool holders at all, > > I don't know what the reference tool would be, and with no > > reference tool I don't know what you'd use to touch-off the work. > > > > Tool length offset is just that - a length - and to measure a length > > you need to find the difference between two points. If you probe a > > tool tip, that's only one. This is problem 2 - I don't quite see a > > good way for someone to use G43 in this way, after we solve problem > > 1. > > Hmm, I have a small hobby-grade CNC machine (a modified Proxxon MF70 > from usovo.de) which doesn't have a tool holder. It came with PC/NC, a > DOS program. This program takes the following approach for tool length > corrections: > > It basically assumes that the first tool you use is the one you used to > define your coordinate system. (PC/NC allows redefining X/Y/Z origins > per g-code file, though this is a non-gcode manual process, which also > involves options to define the working space, with an error issued when > you g-code exceeds this working space. It also allows defining > independent scaling for the X and Y axes, not sure about Z at the > moment.) All origin, offset and working area settings are done before > the first line of G-Code is executed. > > Anyway, the process in PC/NC works like this: > Define working area in X, Y dimensions (machine coordinates), define > origin in X, Y and Z (machine coordinates) for G-Code. This all usually > happens with the first tool you intend to use. > You need to measure the tool length before setting X/Y/Z origins and > that tool length (or rather: The Z coordinate at whicht the tool hit the > measurement switch) is used as a reference. > Whenever PC/NC reaches another "M06 T?", it will _always_ measure the > tool anew, even if it has a known length for that tool number. It then > uses the difference in Z to correct the tool length. > > I would hope that EMC at one time also provides a similar functionality. > Especially as manual tool changes are prone to errors with the depth to > which a tool is inserted into the spindle. > > However, PC/NC also has problems with tool changes. Imagine the > following G-Code: > > M06 T02 > G01 X1 Y1 Z0 > M06 T03 > G01 X1 Y1 Z0 > > Looks pretty simple, doesn't it? Now, what happens in PC/NC? > 0) (store current position) > 1) move to tool change position > 2) ask for tool to be changed (which you confirm) > 3) move to stored position > 4) move to maximum Z on measurement X/Y > 5) measure tool > 6) move to stored position > 7) execute G01 X1 Y1 Z0 (and store that position) > 8) move to tool change position > 9) ask for tool change (which you confirm) > 10) move to stored position > (without correction, since it is not yet measured) > 11) move to maximum Z on measurement X/Y > 12) measure tool > 13) move to stored position (with corrected tool length) > 14) execute G01 X1 Y1 Z0 (with corrected tool length) > > Now imagine what happens it T03 is longer than T02. Right, it either > breaks or damages the stock when (10) is done. > > Regards, > Sven > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _
Re: [Emc-users] Probing
On Sun, Apr 29, 2007 at 12:04:25PM -0500, Ray Henry wrote: > > I guess I don't really see the issue here with tool length and diameter > probing. Years ago now I wrote a little tickle script that allowed me > to turn the probe switch over, pressed it with the tool and from the > known height of that switch, wrote those values to the tool table and > then reread the table. This could easily be done again from any of the > guis. Tickle's automated menu would allow a user to add just the tool > probe code to a directory and it would be useable from tkemc or mini. This sounds like a good way to configure a tool table if you have holders, but is not useful for changing tools (a different depth every time you insert them) during a program run. > You'll be hard pressed to find the correct xy location for a tool length > measure because it really depends upon the tool being used. Imagine a > drill vs a face mill or fly cutter and you should be able to see that a > single xy location will not probe them both properly. True enough. This wouldn't be useful for a machine using tools like that. With end mills and drill bits, though, it would be fine. On my small machine I don't think I've ever cut with anything but end mills, engraving cutters, and drill bits. They can all be measured at the same point. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] probing
Gentlemen, Tool length offsetting is BIG subject. It is difficult to get people to agree on what it is and where it should be measured from. You must determine how you are going to do it in your shop and then be consistent with it. I have two machines that need the tool lengths set to the programmed tool length. These are 5 axis machines with controls that do not have 5 axis tool length compensation. I have a tool setting station to determine and set the tool lengths. I have two 5 axis machines that have 5 axis tool length compensation. I can set a tool length in my tool setter and use it in any machine. We have determined the tool set gauge point for every machine and adjusted the parameters. I said all that to make this point. The most flexible way is the best. My machines with the newest controls have tool change subroutines that are called by the main gcode program. This allows calculations and comparisons and the writing of tool attributes to the tool table(file). All gcode programs program the center of the spindle and the pivot point of any rotary axis the spindle moves on. The tool length compensation adjusts this to the machine and each particular setup. Three axis machines and multiaxis machines in which the tool axis spindle does not rotate are much simpler to set the tool length. You can set the tool length as a minus number from the z axis home position to the tool set zero position or the program zero position. A machine that tilts the spindle will have a different tool offset requirement. To use a 4 or 5 axis tool length offset you will need to use positive numbers in the tool length table. This tool length value and the pivot length value in the control will have to sum to the length from the pivot point to the tool tip. When the tools lengths are set in this manner you will be able to use the same tools and tool lengths in a 3 axis or 4 axis or 5 axis program. There is on gotcha in this. You WILL have to deal with it. When the tool length offset is cancelled the machine will try to move the gauge point down to the programmed Z point. I have a couple machines that will offset the machine as soon as the offset is changed. These machines respond in the same manner for g54 work center offsets and tool length offset. I don't like this type of response. I much prefer the machine to read offset register and adjust during the next commanded move. BTW, does EMC have 5 axis tool length offsets? Does EMC have 5 axis tool radius compensation? thanks Stuart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] probing
On Sun, Apr 29, 2007 at 12:17:56PM -0500, Stuart Stevenson wrote: > I have a couple machines that will offset the machine as soon as > the offset is changed. These machines respond in the same manner for > g54 work center offsets and tool length offset. I don't like this type > of response. I much prefer the machine to read offset register and > adjust during the next commanded move. EMC doesn't move when you change the tool length offset. It adjusts the end of the following move. >BTW, does EMC have 5 axis tool length offsets? Does EMC have 5 axis > tool radius compensation? No, no. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Proper implementation of Estop - was Effects of mode changes
Chris (and John), Thanks for the replies, I have rather limited internet access at the moment, so I am a little slow in responding. > I don't quite understand what you're saying. When in "machine off" > state, the commanded position tracks the actual position so > you can (for instance) use handwheels and not get a jump when > you go to "machine on" state. If this is not working > correctly for you please say how we can reproduce it (and in > what version of emc). The EMC version is EMC2 2.2 pre-release. Here is the sequence of events I am getting. I am using a banner estop module which requires two inputs within 100ms to arm, and then a one-shot to enable (clear estop condition). Once this is done, the only thing remaining to run the machine is a "machine on". Thus, once I am at machine on, I start a program, which initially does a plunge followed by XY motion doing the routing. If I hit the estop at this point, the machine of course stops. The program step is also set to the end of the program. I then repeat the arming sequence by releasing the estop push button, arming the banner module, and sending the one-shot. Again all that is remaining is the machine on. When I do a machine on, the head will jump to a new position, often significant away from where it stopped. I have not figured out yet what position it is going to. But if I actually had a tool and material, it would likely break the tool or damage the material. This should be the relevant parts of the hal file handling the estop: # This activates the banner estop module newsig EstopWrite bit linksp EstopWrite => m5i20.0.out-13 linksp EstopWrite => m5i20.0.out-14 linkps iocontrol.0.user-enable-out => EstopWrite # This is the estop sense logic newsig EstopSense bit linkpp debounce.0.3.in <= m5i20.0.in-04-not linksp EstopSense <= debounce.0.3.out linksp EstopSense => iocontrol.0.emc-enable-in Regards, Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Probing
On Sun, Apr 29, 2007 at 06:52:13PM +0200, Sven Mueller wrote: > Chris Radek schrieb: > > On Sun, Apr 29, 2007 at 10:03:29AM -0500, Chris Radek wrote: > > > > G49 > > insert any tool, touch off, set work coordinate system > > start program > > program probes first tool, THIS is the reference tool for this run > > program saves reference Z coordinate in a variable > > cut... > > program goes up to tool change height, prompts for next tool > > program probes this tool, this - reference => G43 > > cut... > > ... > > Looks exactly like I would want it to work. It would be nice if this > could be automated in M06 handling if no tool changer is defined, but > any working recipe would work for me I guess. Hi Sven, I've added this scheme to the emc2 cvs trunk. I can't test it right now but maybe I can set up something one of these days. G43 with an H index -1 is now a "transient" tool whose offsets are specified on the G43 line. The length offset is specified with the K word (and X offset with I word for lathes). So G43 H-1 K0.5 would do the same thing as G43 H3 if tool 3 has a length of 0.5 in the tool table. Like I described above I think this will let you use probing to measure and set up length compensation for a newly inserted tool in a fairly straightforward way. (Since H-1 was previously disallowed, this will not break any existing programs.) Chris - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
