> I see what you're talking about now - and I agree that an at-speed > input which EMC checks at the "right" times would be a nice addition. > > I think possibly the "right" times are: > > 1) before the first feed move after each spindle start, AND > 2) before the first feed move after each spindle speed change, AND > 3) if in CSS mode, at every rapid->feed transition > > I propose this as the spec -- please tell me if you agree or > disagree with it. (I do not know how to implement it yet, but > that's secondary to agreeing on the correct behavior.)
Yes I agree I assume spindle speed change means S code change . > >> For instance for the spindle reverse I would monitor spindle fwd and rev >> If they switch I feedhold to do the brake and reverse. > > If we have the above behavior, is it true that using feed-hold for > waiting for the spindle to do various things, and all the issues about > feed-hold that arise when we think about using feed-hold that way, > are moot? No matter how long ladder takes, and what it does, to get > the spindle to agree with motion's requests (fwd, rev, speed), it > asserts at-speed when it's ready. If EMC's motion waits at the > "right" times (above) I think we've solved all the problems. Not the same thing. With your proposed behavior EMC would feedhold AFTER the direction change. This guy wants it DURING direction change. These are two different scenarios. With EMC waiting for a spindle_has_stopped pin this would be easy. If you don't want it to stop between changes connect spindle_has_stopped to spindle_brake (which should be called spindle_stop) and it won't. A non override able feedhold would be a good edition for other scenarios. It allow the greatest freedom to do what I want with out having to guess what the G code is doing nor Having to write a complicated ladder/hal component. > I agree with Steve here. The bridgeport-specific behavior hardcoded > in EMC had brake delays, "go faster"/"go slower" to be hooked to the > varispeed air motor, etc. I think it was the right decision to > remove that stuff from EMC proper and let the hardware abstraction > layer handle it. That really was the whole point of HAL. My point exactly. what we have now is locked in behavior that is difficult for a new person to get around. Now if I was talking about something really obscure then no problem Buddy has to work a little harder. but stopping between spindle direction changes and having CSS check that the spindle is up to speed are not obscure and without a feedhold pin that cannot be overridden by the end user, not safely possible. Thanks for discussing this I like debate ! Chris Morley _________________________________________________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
