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/kinematics/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 -- ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
