On Sun, Nov 09, 2008 at 03:46:58PM +0000, Leslie Newell wrote: > Thanks for the responses. > > > In the upcoming EMC 2.3 there is a "spindle at speed" HAL input, so > > EMC will pause motion to let the spindle speed up or slow down before > > starting a feed, if in CSS mode > > So what happens with this signal if you are using CSS when facing? In > that case the spindle speed is changing with the cut diameter.
In CSS mode, at every rapid->feed transition, it waits for the spindle to be at speed. Once a feed is started, it does not wait anymore until after the next rapid. So for the facing situation where you feed in to the center, rapid out in Z a bit, rapid to X=big radius, rapid over in Z a bit, then do the next feed in -- it will pause to let the spindle slow down before each feed. In non-CSS mode, it waits for the spindle to be at speed at the first feed move after the spindle speed or direction are modified. So on a mill, when you start the spindle after changing tools or whatever, the machine can rapid into position while the spindle spins up, but it will not start the actual cut until the spindle is ready. > Is there any timetable for diameter mode or is it a case of finding a > volunteer? I do not think anyone is working on it. I would happily review a patch if someone submits one. > 0.75kW brushless motors for X and Z - not sure if I'll use s/d or analog > control yet. It depends if I can re-use the existing Fanuc drives. My understanding is that AC motors are matched to their drives and you really must keep them together. If for no other reasons than to get index pulse homing and smart following error (i.e. crash) detection, analog control with encoder feedback to EMC is far (far) superior to s/d. > 7.5kW inverter spindle, driven with an anlog output > 2x electronic handwheel (high res MPGs) > high resolution spindle encoder. > Touch screen. > Analog inputs (modified joystick) for FRO + spindle override. Is there > an option for separate rapid speed override? In EMC you will need to use encoders for your overrides. Then both sets of controls (the knobs, the GUI) can work together. There is not a spearate rapid override (%). Instead I recently added a configurable velocity limit. I think this is better because it protects you when testing a program in several ways that rapid override % doesn't. For example one problem I had recently was when I forgot to switch out of feed-per-rev mode and programmed F10. That looks and smells like a rapid to me, but not the control. Also I think a percentage is a poor substitute for what I really want: limit the velocity to some rate. The rapids on my lathe are only 200 ipm, but 1% of that is probably still too fast for me to stop the machine if the "rapid" from the tool change position doesn't stop where I expect (which is quite near the work). With a fast machine, using a percentage gets even more silly. For feed override where you often really do want to scale feed rates to 90% or 110%, a percentage interface makes perfect sense. But not for rapids IMO. Hmm, considering how much I typed, it looks like I don't expect everyone will agree with me. The velocity limit caps all moves except those with position sync to the spindle (threading). > Front/rear tool posts - Can EMC handle a rear tool post without using > negative coordinates for the rear post? No, there is no provision for reversing the X axis. > Probably interfaced with a 5i20 card. That's what I'm using, with the machine's original servos and amps; I'm quite happy with it. 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-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
