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

Reply via email to