On Thu, Oct 30, 2008 at 07:28:16AM +0000, Chris Morley wrote: > > What I am saying is that while using CSS , before STARTING a feed line > EMC should know that the spindle is up_to_speed . I suggest that a HAL > bit pin (say spindle_up_to_speed) would suffice. Then an integrator could > connect that pin to what ever logic he wants to confirm that the spindle is > up_to_speed (and how close up_to_speed should be). It can be done in > other less direct ways but I think that such a fundamental behavior > should have a direct, clear pin for it.
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.) > 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. > Sorry hope thats better is there away to make Hotmail do this automatically? Much better, thanks. Sorry - I have no clue about hotmail. On Thu, Oct 30, 2008 at 09:16:21AM -0500, Steve Stallings wrote: > Regarding pause when reversing spindle (direct M3 to M4 transition), > this is a behavior that will differ from machine to machine. All such > behaviors should be accommodated with HAL setups or Classic Ladder. > Early implementations of EMC had Bridgeport specific behavior > embedded in the C code such that an edit and compile was needed > to change the behavior. This severely inhibited progress in adopting > EMC because many users were not able to accomplish this task. > HAL and Classic Ladder are much easier for machine integrators > to work with and are the right place to address machine specific > behaviors. 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. Chris ------------------------------------------------------------------------- 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
