Am 13.02.2008 um 11:41 schrieb [EMAIL PROTECTED]: > On 12 Feb 2008 at 18:03, [EMAIL PROTECTED] > wrote: > >> EMC can do PID just fine. It's steppers that can't. Steppers lose >> torque as the speed increases. There is no way around this, it's >> just >> the physics of the motor. > > > Did someone rewrite the spec for PID?
No, but steppers are different ;-), normally, PID works with a output signal from 0 to +-100%, but steppers are working as steppers, this mean, they "only" can do steps and not power. (I hope i can explain it clearly). The only way i could think to overcome this problem, is a logic in between EMC and the stepper driver who convert the PID output to more (and faster) or less (and slower) steps to the stepper driver. But still, if the stepper motor looses steps, the stepper is running out of sync, and would not come back, especially if you tries "harder" (more and faster steps). I could only recommend use servos with digital scales, or steppers without. I have seen some steppers with resolvers and feedback logic integrated, they could also behaves like servos, but still, then I would go to "real" servo drives. Hansjakob > > used to be a way of correcting a system or process in just the same > way that an operator > would, and it certainly didn't require any more torque, just a wait > state. > >> PID loop will attempt to correct for a >> lagging motor by requesting more "effort" from the motor. > > When did this become the *only* option PID had, more torque and > overspeed? > > I'm not trying to be funny here but I've used a lot of these > technologies in the past, and yet, > when it comes to EMC I'm starting to get the impression that some > things are done > differently. > > I'm not quite sure why, I'm not even sure they are, but it is the > impression I'm getting, and I > hope I'm wrong. > > >> Even if the motor just loses a step or two which is >> detected by the scale, you can't get it to catch up - it's already at >> the limit of its power envelope or it wouldn't have fallen behind >> in the >> first place. > > So, wait state, you surely aren't telling me that EMC will simply > carry on thinking it is > machining a part if the coupling between a motor and leadscrew > fails??? > > >> >> You had an incorrect assumption in your original email: that using >> linear scales will eliminate backlash issues. > > NO, it won't eliminate it, but it will eliminate it from > calculations, as it gives true position, not > estimated position, then add fudge tables. > >> This isn't true at all. >> Backlash is an uncertainty in machine position. If you're climb >> milling, the cutter will tend to pull the table "ahead" of the motor. >> When conventional milling, the cutter will resist motor motion. It's >> not possible for the control to know which type of cutting is taking >> place at any given time, and it may even vary within a move, so >> there's >> no way to "compensate" for it. > > eh, it is working from a tool path with a defined depth of cut and > cutter overlap from last pass, > direction of beds is also knows so "knowing" whether you are > cutting on the climb or the chip > is as trivial a logic problem as it is for a human operator. > >> Additionally, de-coupling the feedback >> from the motor, especially through a drive with backlash, will >> make the >> system very hard to tune. The PID integrator will "wind up" as the >> motor starts to spin to take up the backlash, but the feedback won't >> change until the motor is already moving. The motor will slam the >> table >> into motion, at which time the PID starts to wind up the other >> way. The >> result is - you guessed it - oscillation. This is very hard to tune >> out. >> >> There has been some discussion recently about using both encoders and >> linear scales, but there isn't any software to do that yet. I think >> this is the "different method of machine control" that Kirk is >> talking >> about. >> >> As for redundancy, since EMC takes encoder feedback, there isn't >> really >> any need for a DRO - the EMC display is actual position. > > Listen, I know from experience that my words have a tendency to get > people's backs up, and > I don't want to do this, members of this list have been extremely > helpful and extremely nice. > > But. > > I'm getting an awful suspicion here, and that awful suspicion (and > I dearly hope I'm wrong) is > that EMC is going to suffer the same problems of many open source > projects, it's crap. > > For example, you've got the gimp, and you've got photoshop. > > It isn't about whether one is free as in beer or one can be > modified, it is about which one is > actually productive for those who wish to edit images only, and > have no interest or talent in > coding. Photoshop creams the gimp. The gimp is only free if my time > is worth nothing, eg > editing images is a hobby, not a job of work and not competing with > a job of work for my time. > > I'm starting to suspect that EMC is a project that started out, not > to emulate the commercial > equivalents, but built bit by bit to do various things on the > cheap, I'm starting to suspect that > EMC is not a realtime machine control system, but rather an offline > (non realtime) simulator > that relies on assumption (I sent signals to move X 1.01 mm, > therefore I shall assume it has > moved 1.01 mm) > > I hope this is not so and I'm wrong, because if not EMC is no use > to me. > > Please don't do the "well that's open source buddy and you can > always code your own > solution cos after all it is free software" thing on me, I'm not > actually here with my primary > concern being paying as little as possible or preferably nothing > for software, I'd be quite > prepared to pay for EMC, and as a long lime linux user I dig open > source (can't code myself > but there we go) but at the end of the day when it comes to all > forms of software I'm looking > for a tool to do a job, and I don't mind paying for a good tool. > > For example, you say "As for redundancy, since EMC takes encoder > feedback, there isn't > really > any need for a DRO - the EMC display is actual position." and I'm > sort of, what??? encoder > feedback is only actual position if it is measuring actual > position, eg linear scales... > > Is this simply a case of linear scales used to be frighteningly > expensive so the EMC coder > ignored them and went with the cheap option, and then started > fudging around to try to fix the > problems associated with going the cheap route? > > I'll grant you that rotary encoders on the leadscrews can be pretty > accurate, emphasis on > "can", if you retrofit with class 5 rolled ballscrews and scrape > the ways, but if you're using > trapezoidals fuhgeddabadit... > > Again, I'm not trying to give offence, but I'm wondering what sort > of people are members of > this list, how many are turners, how many are coders, how many are > hobbyists, how many > think that an encoder set up that displays numbers accurate to a > few micron is suddenly > going to allow you to make chips to that same level of "accuracy"? > > Yesterday I bought the DRO and sino scales as I said, the whole > package with everything > (extras) thrown in and a couple of other items was just under 500 > quid, an hour later I > ordered a sheet of 10mm 5083, it cost just about as much as the > basic dro and scales, for > me my time is money and for me materials are money, if EMC isn't > going to save me time > then I'm better off paying money for commercial closed source > software, and if EMC is going > to try to force me to work wihin arbitrary parameters like you > can't use linear scales and > steppers because of the way the code is written then EMC just did a > kcad and gimp on me, > which is a shame, but this isn't a hobby when you start spending > hundreds of pounds on > materials. > > Again, many thanks to all who have replied to my queries before, > much appreciated. > > cheers > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
