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.
Whew! It has been a while since I jumped up on a soapbox. No disrespect intended, just strong feelings about how things need to be done. Now where did I leave my coffee? Steve Stallings > -----Original Message----- > From: Chris Morley [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 30, 2008 2:28 AM > To: EMC developers > Subject: Re: [Emc-developers] spindle brake > > > > First off let me apologize for being unclear with my thoughts and If > my wording seemed overly strong. > > >> IMHO -CSS should always wait > >> for an up to speed signal before STARTING feed otherwise the surface > >> feed might not be even close. > > > > Are you talking about constant surface speed or feed per rev? > > Talking about surface speed - now :) - as you pointed out Feed per rev > will be right no matter the speed of the spindle! > 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. > > > When radius changes abruptly you have the same problem with speed. I > > don't think you should stop feed in all these cases. That could be a > > disaster with some materials or tooling. It is often better to cut at > > a slightly wrong speed than to stop feed and rub the work with the > > tool. It's a compromise either way. EMC's current solution to that > > compromise is "let the user control it" (even if he just programs G4 > > once in a while). > > I agree about cutting at a slightly wrong speed. I am talking about a > BIG lathe where it takes 3-4 seconds to come up (or worse down ) to > speed but takes a second to rapid to the next feed position. > I'm also talking about only at the start of each feed line. > A small radius cut will not ask the spindle to change very fast. > A facing cut will ask a fairly slow change. > A feed at 4" od then rapid up to 10" diameter will ask for a huge fast > change, if the rapid speeds are fast. > It would be up to the integrator to decide that -50 rpm is ok but -200 > is not and lets EMC know by toggling the described pin. > Again G4 is a crutch for something that should be handled by machine > logic not by a programmer. > > >> The threading should only feed hold when it's not synced in my > >> opinion. Thats they way the Okuma was- If you hit feed hold (in the > >> middle of a pass) it would hold after the current thread pass was > >> finished. > > > > EMC2 already does this. > > perfect I didn't see this in the docs (I didn't look hard either) > > > > >> As for the spindle brake/reverse problem sort of the same thing- EMC > >> should not go from m3 to m4 (or vice versa with out stopping first and > >> it should know if it did stop. > > > > I disagree. Many spindle controls (all VFDs??) handle this perfectly > > fine. My lathe is one. > > That is really the point- for you all is good for the other guy he wants > something different. When would you want to go from m4 to m3 > without stopping? Your VDF does it for you. Fast enough for EMC > or else you feed hold till it's done. > > > > > For machines with reversing contactor spindle control, you may want to > > stop before you reverse. I agree with Stephen that you can handle > > this in HAL. I have all sorts of machine-specific stuff in classic > > ladder on my lathe. You cannot open the collet or change gears with > > the spindle running, etc etc. I think it's an adequate way of > > handling these machine-specific peculiarities. > > I guess I just disagree- I think the behavior is fundamental and > common. > I also agree that it can be done in other ways. You can do it, I can do it > but can the ordinary ( just from MACH :) ) guy do it? It's a lot of work. > > > > >> What we need to do this safely is a feed hold that cannot be > >> by-passed . the current feed hold can be overridden. > > > > This seems contrary to what you said two paragraphs up. Can you > > clarify? > > Yes If I am going to use feed override to do some of the things we talked > about I need one that cannot be overridden. It will be up to me > to not use it > when say threading. > 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 the programmer overrides feedhold with out thinking then I'm > in trouble! > So either we have one that cannot be overridden by the user but does > not feedhold for threading/tapping (works for me) or one that cannot be > overridden at all and the integrator has to be careful (is there away for > HAL to know when threading/tapping?. > > > > > Chris > > > > P.S. Please wrap your text at 70 columns; it is very difficult to > > quote and reply to your messages with unwrapped paragraphs and have > > it remain coherent. > > Sorry hope thats better is there away to make Hotmail do this > automatically? > > > _________________________________________________________________ > > > ------------------------------------------------------------------------- > 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 > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
