Re: [Emc-users] nine-axis changes (XYZ ABC UVW)
On Tue, Jul 17, 2007 at 10:25:08PM -0500, Chris Radek wrote: > > Beware this meant expanding (actually filling in some holes) in the > var file. You may need to update yours from CVS if you're running > the trunk with a customized config. Ask if you need help, and if > you've been waiting for this please report successes or failures! > I've now found that you WILL need to update the var file in any custom configuration. I've updated all of them in CVS now, just grab one. The error you'll get is emc/task/emctask.cc 312: interp_error: Coordinate system index parameter 5220 out of range Coordinate system index parameter 5220 out of range emc/task/emctaskmain.cc 2560: can't initialize interpreter and EMC will fail to start. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] nine-axis changes (XYZ ABC UVW)
On Wednesday 18 July 2007 09:15, Chris Radek wrote: > If you move the knee and quill together to drill a deeper hole (G94 G1 > Z-6 W-6 F8) you DO need to understand that you won't have 8 units per > minute at the tooltip with respect to the work (in this example you'll > get twice that). > Chris you run into this on swiss type turning centers quite a bit the controll knows those two are parallel and opposed so you give a code to lock the motion together ,or it might be coordinated motion with a floating zero anyway they split the feed between them ,so they'd each move at 4 to get the 8 you wanted it gets even more confusing when you have a turning tool in the cut at the same time Z1 is feeding at the turning tools feedrate while Z2 is making up the difference ,it could even be backing up if the turning tools feed is higher ,it looks really odd to peck drill that way Brian - 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] nine-axis changes (XYZ ABC UVW)
At 12:15 PM 7/18/2007, you wrote: >Andre' Blanchard wrote: > > > > The X,Y U,V wire EDM's I run have a set of what they call Z constants. > > Z1 is the distance from the machine table to the point at which the X,Y > > size is held true. > > Z2 is the distance from the table to the point at which the feed rate is > > held true. > > Z3 is the distance from the table to the upper wire guide. > > Z4 is the distance from the table down to the lower guide. > > > > Using this info the control can calculate the displacement of the U,V > > slides from the X,Y to get the taper angle and the part size programmed in > > the G code. >Since these are all constant, there's no need to burden EMC with >that. You could put these values into the CAM software to >calculate the correct XY UV to make the desired part. > >I suppose you could re-do the kinematics so it solves all this >in EMC, but I'm not sure that is necessary or desirable. > >Jon They are constant until you do some maintenance (could be just cleaning the guides) on the machine then you have to find new constants, opening that loop up back to some CAM software is going to introduce more potential errors. Feed rates in wire EDMs are really just starting points for the control, you almost always run in adaptive mode where it tries to go as fast as possible. As such the Z2 constant ends up being the point for which the actual feed rate is displayed to the operator. Reposting and transfer to the CNC machine is slower then having family part macro subs in the control and letting the user simply change some sizes and run the next part. The reason for doing things like this in the control is to keep the spindle turning as much as possible. Break a tool, put in a new one edit the comp offsets and hit the green button. Teaching the average CNC operator how to efficiently run a CAM package is not easy. The chances of them making an error posting a new program are greater then if all they have to do is change an offset. Taken to the extreme you can do everything in the CAM software and simplify EMC to just G0 G1, no need for G2,3 because the CAM can do it all with G1s, no need for tool offsets or cutter comp because the CAM software can do it, likewise for G81, 82, 83, etc. canned cycles. Just telling how it works in controls that are found in machine tools around the world. Yes there are shops that depend on CAM software for everything but they tend to not be running 3 min. or less finish op cycle times on pre-blanked parts with 1 to 5 parts per order, with the operator doing 50 to 100 orders per day. __ Andre' B. Clear Lake, Wi. - 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] nine-axis changes (XYZ ABC UVW)
Chris Radek wrote: > > > You jump right to the hard questions Jon! > > This is the same old problem with G94 (feed in units per minute) mode > being inappropriate when EMC doesn't know what axis motion corresponds > to a "unit" (inch or mm) on the part. > Yeah, I figured. > As you already know RS274NGC says for coordinated motion for linear > and rotary axes together using G94 mode, the F rate is units per > minute in the cartesian (XYZ) axes only, and the rotary (ABC) axes > move so as to start and stop in a coordinated fashion. For one thing > this means that if the rotary is slow, the cartesian move is slowed > down to stay coordinated with it. > > I've done the same thing for UVW and I'll try to describe it as > precisely as possible: > > If any of XYZ are moving, F is units per minute in the XYZ > cartesian system, and all other axes (UVWABC) move so as to start > and stop in a coordinated fashion. > > Otherwise: > > If any of UVW are moving, F is units per minute in the UVW > cartesian system, and all other axes (ABC) move so as to start and > stop in a coordinated fashion. > > Otherwise: > > The move is pure rotary motion and the F word is in rotary units > instead of linear, in the ABC (pseudo)cartesian system, as > originally described in NGC 2.1.2.5(B,C) : > http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_32a.html#1010695 > OK, this is pretty much as before, just with added linear coords. What do other manufacturers do for this? We also have the inverse-time programming, if people need this. It all comes down to what the CAM system needs to know about the job. > > I feel like G94 (feed in units per minute) only really makes intuitive > sense when moving in just one cartesian system. All other types of > (cutting) motion ought to be programmed in G93 (inverse time mode), > and I've been told that this is standard practice. But that being > said, this seemed like a sensible behavior for G94 mode. Yes, I suppose. The only place I think it might make sense to do more (and I think it would have to be an option, because it could get in the way, especially if contrary to industry practice) would be with the addition of one rotary axis to XYZ. If the system were defined such that an A axis would be used where Y=0 and Z=0 would be on the axis of the A, then the control knows everything it needs to compute tool-center velocity in 4 axes. For complex surface profiling on a round part, this could handle the correct feedrate. This would allow someone to write a fairly simple code to convert some data set to a toolpath, and let the control handle the feedrate. Maybe this would be a bad idea, anyway, as there are certain cases like the side of the cutting tool coming up against a wall that would need to be dealt with by reducing the feedrate. So, maybe it is just better to FORCE the user to deal with this at the CAM stage. I suppose one other possible case is ALMOST covered by your above rules, and shouldn't be hard to extend. For a 4-axis XY UV system, you could program it where the UV velocity was higher than the XY velocity. (Cutting a cone with the point up in wire-EDM, for instance.) It might be nice to have a mode where XYZ and UVW velocities are both computed, and the highest one limits the feedrate. If I understand what you wrote above, if the UVW rate exceeds the XYZ rate, the XYZ will still be the one that controls the machine, as long as there is SOME movement of the XYZ. This could cause discontinuities in the feedrate where the UVW is in continuous motion, but the XYZ is sometimes moving and sometimes not. I can imagine parts where that would happen. Imagine the point-up cone again, where the hole at the top of the work is REALLY small, but the XY is moving just a little. It might be hard to set reasonable feedrates for the XY to get the feed you want on UV. Of course, inverse-time will fix it, so maybe that is OK, whenever mixing XY and UV, you just do EVERYTHING by inverse-time to avoid the feedrate jumping around. Jon - 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] nine-axis changes (XYZ ABC UVW)
Andre' Blanchard wrote: > > The X,Y U,V wire EDM's I run have a set of what they call Z constants. > Z1 is the distance from the machine table to the point at which the X,Y > size is held true. > Z2 is the distance from the table to the point at which the feed rate is > held true. > Z3 is the distance from the table to the upper wire guide. > Z4 is the distance from the table down to the lower guide. > > Using this info the control can calculate the displacement of the U,V > slides from the X,Y to get the taper angle and the part size programmed in > the G code. Since these are all constant, there's no need to burden EMC with that. You could put these values into the CAM software to calculate the correct XY UV to make the desired part. I suppose you could re-do the kinematics so it solves all this in EMC, but I'm not sure that is necessary or desirable. Jon - 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] nine-axis changes (XYZ ABC UVW)
On Tue, Jul 17, 2007 at 11:48:44PM -0500, Jon Elson wrote: > > Chris Radek wrote: > > > I thought I should mention that I merged my nine-axis changes into > > the cvs trunk. We now have fully coordinated motion in six linear > > axes (UVWXYZ) and three rotary (ABC). > > Cool! DAMN cool! > > One of the quirks in the old days was how to program the rate of > these mixed-axes moves. For instance, in an XYA move, it is > easy to compute the feedrate of the XY part, but without knowing > the radius the cutter is at from the center of the A axis, you > can't add that component to the total velocity. How is this > handled now? You jump right to the hard questions Jon! This is the same old problem with G94 (feed in units per minute) mode being inappropriate when EMC doesn't know what axis motion corresponds to a "unit" (inch or mm) on the part. As you already know RS274NGC says for coordinated motion for linear and rotary axes together using G94 mode, the F rate is units per minute in the cartesian (XYZ) axes only, and the rotary (ABC) axes move so as to start and stop in a coordinated fashion. For one thing this means that if the rotary is slow, the cartesian move is slowed down to stay coordinated with it. I've done the same thing for UVW and I'll try to describe it as precisely as possible: If any of XYZ are moving, F is units per minute in the XYZ cartesian system, and all other axes (UVWABC) move so as to start and stop in a coordinated fashion. Otherwise: If any of UVW are moving, F is units per minute in the UVW cartesian system, and all other axes (ABC) move so as to start and stop in a coordinated fashion. Otherwise: The move is pure rotary motion and the F word is in rotary units instead of linear, in the ABC (pseudo)cartesian system, as originally described in NGC 2.1.2.5(B,C) : http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_32a.html#1010695 I feel like G94 (feed in units per minute) only really makes intuitive sense when moving in just one cartesian system. All other types of (cutting) motion ought to be programmed in G93 (inverse time mode), and I've been told that this is standard practice. But that being said, this seemed like a sensible behavior for G94 mode. For instance if you move (G0) the knee of a mill for gross positioning and then cut with the quill, or you use the knee to drill a deep hole (G1), you'll never notice and it will be entirely natural. If you move the knee and quill together to drill a deeper hole (G94 G1 Z-6 W-6 F8) you DO need to understand that you won't have 8 units per minute at the tooltip with respect to the work (in this example you'll get twice that). 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] nine-axis changes (XYZ ABC UVW)
THANK YOU GUYS. That's the best news I've heard in years concerning EMC! Unfortunately my big machine has been on hold for too long but that's great news. I hope to get back to making machine parts this winter. It's good to know that Emc will be ready for my W axis. Good Work! Thank you, Dale Chris Radek wrote: > Hi all, > > I thought I should mention that I merged my nine-axis changes into > the cvs trunk. We now have fully coordinated motion in six linear > axes (UVWXYZ) and three rotary (ABC). > > Also, thanks to some work Jeff did, you can have any set of these > defined - whatever is appropriate for your machine. > > This ought to help with some simple things like knee vs quill on > mills (XYZW or XYZAW), as well as maybe being useful for some more > specialized setups like foam cutters (XYUV). > > Beware this meant expanding (actually filling in some holes) in the > var file. You may need to update yours from CVS if you're running > the trunk with a customized config. Ask if you need help, and if > you've been waiting for this please report successes or failures! > > 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] nine-axis changes (XYZ ABC UVW)
At 11:48 PM 7/17/2007, you wrote: >Chris Radek wrote: > > Hi all, > > > > I thought I should mention that I merged my nine-axis changes into > > the cvs trunk. We now have fully coordinated motion in six linear > > axes (UVWXYZ) and three rotary (ABC). > > >Cool! DAMN cool! > >One of the quirks in the old days was how to program the rate of >these mixed-axes moves. For instance, in an XYA move, it is >easy to compute the feedrate of the XY part, but without knowing >the radius the cutter is at from the center of the A axis, you >can't add that component to the total velocity. How is this >handled now? The X,Y U,V wire EDM's I run have a set of what they call Z constants. Z1 is the distance from the machine table to the point at which the X,Y size is held true. Z2 is the distance from the table to the point at which the feed rate is held true. Z3 is the distance from the table to the upper wire guide. Z4 is the distance from the table down to the lower guide. Using this info the control can calculate the displacement of the U,V slides from the X,Y to get the taper angle and the part size programmed in the G code. > > Also, thanks to some work Jeff did, you can have any set of these > > defined - whatever is appropriate for your machine. >Again, definitely cool! > > This ought to help with some simple things like knee vs quill on > > mills (XYZW or XYZAW), as well as maybe being useful for some more > > specialized setups like foam cutters (XYUV). > > >Yes, we definitely had a restriction for foam cutters and wire >EDM, both of which use a pair of parallel X-Y axes. > >Jon __ Andre' B. Clear Lake, Wi. - 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] nine-axis changes (XYZ ABC UVW)
Chris Radek wrote: > Hi all, > > I thought I should mention that I merged my nine-axis changes into > the cvs trunk. We now have fully coordinated motion in six linear > axes (UVWXYZ) and three rotary (ABC). > Cool! DAMN cool! One of the quirks in the old days was how to program the rate of these mixed-axes moves. For instance, in an XYA move, it is easy to compute the feedrate of the XY part, but without knowing the radius the cutter is at from the center of the A axis, you can't add that component to the total velocity. How is this handled now? > Also, thanks to some work Jeff did, you can have any set of these > defined - whatever is appropriate for your machine. Again, definitely cool! > This ought to help with some simple things like knee vs quill on > mills (XYZW or XYZAW), as well as maybe being useful for some more > specialized setups like foam cutters (XYUV). > Yes, we definitely had a restriction for foam cutters and wire EDM, both of which use a pair of parallel X-Y axes. Jon - 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] nine-axis changes (XYZ ABC UVW)
Hi all, I thought I should mention that I merged my nine-axis changes into the cvs trunk. We now have fully coordinated motion in six linear axes (UVWXYZ) and three rotary (ABC). Also, thanks to some work Jeff did, you can have any set of these defined - whatever is appropriate for your machine. This ought to help with some simple things like knee vs quill on mills (XYZW or XYZAW), as well as maybe being useful for some more specialized setups like foam cutters (XYUV). Beware this meant expanding (actually filling in some holes) in the var file. You may need to update yours from CVS if you're running the trunk with a customized config. Ask if you need help, and if you've been waiting for this please report successes or failures! 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
