On Sunday 20 December 2015 12:15:25 EBo wrote: > On Dec 17 2015 11:55 AM, Brian wrote: > > On Thursday, December 17, 2015, Gene Heskett <[email protected]> > > > > wrote: > >> On Thursday 17 December 2015 10:40:41 Viesturs Lācis wrote: > >> > AFAIK it has been few years since Araisrobo and Yishin Li have > >> > >> done > >> > >> > it; take a look here: > >> > >> https://github.com/araisrobo/linuxcnc/blob/master/src/emc/kinematic > >>s/t > >> > >> >p.c > >> > > >> > I found some threads from 2012 on developers mailing list, where > >> > Yishin discussed their work on that. This one seems even older, > >> > hopefully it would get you started on finding some more useful > >> > information: > >> > http://sourceforge.net/p/emc/mailman/message/27376772/ > >> > IIRC it has not been implemented in LinuxCNC, because it would > >> > not work for spindle-synchronised moves, but I might be totally > >> > wrong > >> > >> on > >> > >> > that :)) > >> > > >> > > >> > Viesturs > >> > >> Early on, in playing with G76, I found that the actual lockup phase > >> relationship was quite spindle-speed dependent, wrecking a few > >> threads > >> because I thought I could crank the speed up once the motion was > >> verified. > >> > >> And was advised that this was the Z accel lag, and that as long as > >> the > >> spindle speed was maintained, it would not be a problem. Doing > >> that, it > >> hasn't been but I now restrict the spindle rpms to <300 also. I > >> assume > >> the same caveat applies to G33.1, rigid tapping, so I don't crank > >> the > >> revs up there either. > >> > >> But I have wondered why, in the grand scheme of things, that delay, > >> which > >> can be obtained in degrees without a huge hassle, is not turned > >> into a > >> pre-start, that based on the rpms, puts the actual start z point > >> that > >> fraction of a turn ahead of the index, which would result in the > >> lock > >> being obtained such that the index to spindle phase was within an > >> encoder count (or closer) of zero. Doing this on every Z restart > >> would > >> allow us to run it one or two cycles at 50 rpms to check clearances > >> etc, > >> then crank the spindle up to 500 revs and get the job done, without > >> wrecking the threads cut because the phase lag is a fixed time at > >> that > >> rpm. Obviously it would need stretching because of the higer speed > >> Z needs to accelerate to at a higher spindle rpm. > >> > >> I haven't tested recently, perhaps this is something that Robert > >> Ellenburg has addressed? > >> > >> Call me "Curious". > >> > >> Thanks. > >> > >> Cheers, Gene Heskett > >> -- > >> > >> Theoretically, Z acceleration and jerk limits shouldn't be a major > >> concern > > > > in spindle sync moves, because the Z motion is being derived from a > > physical moving body (the spindle). The natural occurring physics > > of the > > spindle motion should result in compatable motion for the Z axis. > > > > This breaks down if Z motion is to synchronize with an already > > moving spindle. In this case, Z axis jerk and accel limits need to > > be observed. > > This shouldn't be an issue though because it is expected during the > > beginning of such a move that the Z axis will need a small amount of > > motion > > to lock phase. > > > > Another edge case is a spindle that can out accelerate the Z axis. > > IMO, The likelihood that the spindle is able to out accelerate the Z > > axis > > is so unlikely that I wouldn't make handling it a priority. > > > > Regarding Gene's statement regarding the phase relationship changing > > with > > spindle speed, that shouldn't be. This is what the I term in a PID > > controller is there to do. This may be a bug or a significant > > shortcoming > > of the code that should be looked at. > > Having any axis's acceleration or speed violate another's is something > we can check for. The only time I have ever seen that to be possible > is on a machine that had a 5C collet head and would go from 0 to 6,000 > RPM in almost an instant. That would likely violate the z-axis > acceleration if you had it set to try to tap that fast. > > Do we have, or should we have, some code to verify that a given bit of > g-code does not violate any of the machine parameters? I think the > most common will be you asked it to turn at 4,000RPM but the machine > can only do 1,400... > > EBo -- > > I think thats already handled by common sense. I've never calculated what my z axis, the slowest of the 3 on the new mill would need to follow a 2500 rpm spindle, mainly because I haven't programmed the spindle for more than 300 revs while doing rigid tapping with fairly fine thread taps, in low gear. Low gear spindle is about 1250-1300 wide open. So it likely does not exceed the 42.3 ipm speed limit of my Z regardless of the tpi of the tap in the chuck.
On the lathe, its less of a problem as z can move at or slightly above 60 ipm. Cutting air with that toy, I've had it positively dancing a jig while running a g76. In either case, a far greater danger is the tap slipping in the chuck, and that I have not found a solution to other than bending the chuck key tightening it, all the way around the chuck, several times. We seriously need a tap chuck that grabs the square butt of the tap. Unfortunately, there does not appear to be a set std size for the butt end square. I probably own 50+ taps, and no two are within 30 thousandths of the next one. If someone knows of such a tool, toss me the URL, please. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Some mill pix are at: Genes Web page <http://geneslinuxbox.net:6309/gene/GO704-pix> ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
