On Dec 20 2015 11:48 AM, Gene Heskett wrote: > 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 <ghesk...@wdtv.com> >> > >> > 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.
I've heard it said that common sense is not so common, but in all seriousness if you are running a machine at anywhere near its max having a limit checker would be nice and useful. As for checking the business end of take a tap look at things like these (note I have not used them, but seen stuff like them in the past): http://www.amazon.com/Jacobs-0065644-Tapping-Collet-System/dp/B001LDJ9PW I have also seen drills and taps which have three flats on the shank to allow a standard chuck to grab them well. Befor doing that to my taps I would probably cut down a standard tap handle and precision grind fats on one of them. I have used a floating tap chuck in the distant past as well as a tapmatic. The floating tap chucks would probably be the best place to start. EBo -- ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers