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