Hi Chris,
> 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. > With CSS, the spindle speed should change as the X feeds. So for instance if I am facing the end of a bar, the spindle may be doing 1000RPM when I start and 3000RPM by the time the cutter gets near the middle. Does EMC do this or does it only change before the next move? > I do not think anyone is working on it. I would happily review a > patch if someone submits one. > I have been looking into it. As far as I can see, to get a basic diameter mode working the interpreter needs to halve the X and I values in the two relevant read functions. R mode arcs can be really confusing (Mach falls over badly on R arcs in diameter mode) but probably the best approach would be to treat R the same as with radius mode. The GUI needs to double all X values on it's position displays but not on the backplot. Making tool tables handle diameter would be nice but not essential (for example Mach always uses radius for tool tables). I have some previous experience with the RS264NGC code so I might have a play. I haven't any experience with tcl/tk so the GUI side may be more of an issue. Is Axis the only GUI that handles lathes correctly? > My understanding is that AC motors are matched to their drives and you > really must keep them together. > To a large extent this is true. However there are some universal drives available, such as the VSD series from <http://www.granitedevices.fi>. These drives do not need the proprietary position signals supplied by the motor. The only disadvantage I can find is that when you first apply power to the drive the motor will jump slightly as the drive calibrates itself. > 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. > I agree completely. This is one of the things I like about EMC. It depends what drives I end up using though. The VSD drives can handle PWM input which is handy. > In EMC you will need to use encoders for your overrides. Then both > sets of controls (the knobs, the GUI) can work together. > I read somewhere that you can get around this. Basically you end up sending the override signals directly to the GUI (axis). I'll try to find the link again. I don't like encoders for FRO because the machine loses the encoder position when you shut down. > There is not a spearate rapid override (%). Instead I recently added > a configurable velocity limit. > The velocity limit caps all moves except those with position sync to > the spindle (threading). > Sounds good and makes perfect sense. > No, there is no provision for reversing the X axis. > Pity. I've had a couple of nasty crashes due to forgetting to get the sign right before. Thanks, Les ------------------------------------------------------------------------- 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
