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
