Hi John.... speaking of Brits, when does Paul get back? dunno, I thought he was saying about 6 weeks in the states I think Paul said he was out here for 2 months or thereabouts? so early June probably Gee, you may have EMC2 up and running by the time he returns. 8-) SteveStallings: I actually "ran a g-code program" with it yesterday So John....been tackling the traj planner eh? gave up, for now ha...well it is kinda splattered all over the place just copied over the code that calls it I know the math...but certainly not the code but it is on my list - I hate that mess John, don't give up, just jank out more "cruft" and it will run. 8-) my problem is that sometimes I yank too much, then I gotta put some back hard to do when you can't understand how it works The cvs head should give a choice of the old tp or segmentqueue now lack of comments? dpending on the motion program I did yank out the homing cruft, gonna re-do that part so far only the old one is in emc2 Yours is still the best approach, John. That way all the old stuff is validated as necessary and you begin to learn how it works in the process. makes sense I'm very slowly starting to understand things, and as I do I see stuff that was put in there in an attempt to be "general" I have to use segmentqueue for high speed machining, but I can just use emc1 for now what it winds up meaning is that there are multiple layers of stuff in there that get in the way of comprehension yup Sort of like the shell companies that the corporate bandits set up to confuse the IRS. les: are there jobs where the old tp is better than segmentqueue? or should emc2 simply use segmentqueue and be done with it Well the old tp would break into exact stop mode often due to math errors that were never really found on a bridgeport at 5 ipm one can live with it on a router at 200 ipm it will tear the machine apart so why keep the old one at all? Les - Is exact stop mode still working in the new one? A fully debugged segmentqueue should be pretty much universally good I would still keep the option for G61 exact stop though does segmentqueue do exact stop? so G64 segmentqueue, g61 exact stop Actually segmentqueue does an exact stop and sharp corners It is a cubic spline with corners so it can do both, depending on how you set it up? Kind of like a true type font...it is a quadratic spline with corners well as a spline it creates a different shape slightly but it does pass through waypoints it does not miss them it does that by creating in zone pseudo waypoints for internal calcs there is an emcmot command EMCMOT_SET_TERM_COND that sets the termination condition to stop or blend - that is how G61/G64 is implemented at that level (G-codes don't exist there, they've already been processed) I have not tried g61 lately... I don;t use it Les - I would expect there to be a way so suppress the "pseudo waypoints" when running in exact stop mode. but someone else might need it for something well g61 ideally should turn off all the contouring I don't know that it does though Last time I tried it (pre segmentqueue) it appeared to do nothing AFIAK, the flow is "G-code -> (interpreter) -> canonical commands -> (task) -> emcmot commands -> (traj planner) -> coarse positions -> (interpolator) -> positions -> (PID) -> motors in an ideal world, all those interfaces would be documented I'm working at the level of emcmot commands and lower yes the cannonicals result in a list of third order polynomials that change at each original waypoint nope - canonicals just result in ADD_LINE or ADD_CIRCLE commands to emcmot... so at any time the servo loop can query "where should I be at time t" then the traj planner (after much farting around) generates the polys yes of course arcs are a subset of a third order function believe it or not, I _still_ can't find the code that actually generates the coarse positions.... I know it's in there somewhere (tp.c or tc.c) tc.c and tp.c mostly haha the person who wrote that code had a mental image of it, and if you have that image I'm sure it makes perfect sense (maybe) but that image isn't written down anywhere Well fred wrote it and we have talked a lot the problem with Fred is he is too smart he thinks everyone else is as smart, so he doesn't spell out things He never found out why the original planner failed dramatically when waypoints are close together well emcmot can only process one ADD_LINE or ADD_CIRCLE (or any other command) per servo cycle they are queued, but the queue is only 200 deep... so if you have a string of 201 moves that can each be made in one servo cycle or less, it will run out well at least in segmentqueue lines and circles are all cubics hmmm in reality the processing rate is probably less that servo rate segmentqueue can look ahead an entire program John - I think you stumbled onto something, queue starving.... because the queue is in the wrong place (IMHO) yes the planner has to go slower if it is in rt due to nyquist stuff the interface between task (user space) and command processor (RT) is _not_ a queue - it holds only one command funny thing is that it is causal... one could plan the trajectory last week the processor takes that one command and queues it on a queue that is internal to the RT code, then the tp takes it off the queue later as long as it is stored I wish I knew more about writing code for a rt kernel another thing that is frustrating is that the tp is used for homing and jogging as well The math for this stuff is simple hmm if it were _only_ used for "normal" motion, things would be more decoupled Well all I could do was to get Fred and Rogier in the same room at the same time for the first time since 1999 for instance, your idea of pre-planning motion - won't work, because the RT planner code (today) needs to be able to plan jogs and home moves that are issued within the RT code I see if homing and jogging were independent of the planner, then you could queue cubics or splines or beziers, or whatever unless they were a separate motion category yup I'm leaning that way sounds like the way to go homes and jogs are separate commands to the emcmot block so the "planner" would only deal with ADD_LINE and ADD_CIRCLE right the motion controller would handle HOME and JOG_INCR, JOG_ABS, and JOG_CONT itself How we doing? ran 3dtest.ngc with emc2 yesterday ;-) so 3dtest ran? moving iron? yes, but 3D-Chips.ngc did not... still a lot to be done no, I used HAL to jumper position-cmd to position-fb (perfect PID/servos, eh?) Glad to hear about g-code running with emc2 still needs a lot of work - homing is completely missing right now, I had to bypass estop, lots of other stuff joint coordinate display didn't work (using tkemc) But emc2's starting to work. That's great. So...the only two motion cannonicals are straight line and arc? as I was working I had bunches of questions for you ray, but now I can't remember most of them ;-( les: yep You have to have integrated a whole bunch of code to get that far, John. hacked, chopped, and duct-taped integrated is far too refined a word for what I've been doing I've only got a few minutes <30 here this morning. les: look at emc2/src/emc/motion/motion.h, line 85 for the list of emcmot commands there is a similar list for emc1, I've changed a few, but none of the motion ones ok, so I can hit you with questions? ;-) do you know if JOG_ABS is used anywhere (absolute jog)? I know JOG_INCR and JOG_CONT are used I know nothing about the innerds of JOG. well in tkemc you have buttons for continuous, 0.0001, 0.001, etc jogs We do use both cont and incr but in essence they are the same because jog cont is a command to jog to the soft limit in the direction of travel. those issue either JOG_CONT or JOG_INCR commands to emcmot at the emcmot level, cont is EMCMOT_JOG_CONT, and an EMCMOT_ABORT is sent when you let go of the button hi john the incremental ones are EMCMOT_JOG_INCR, with no abort these commands probably come from task?, but are sent by task in response to things sent from the GUI That's my understanding of how it works. In tickle we use a command defined in emcsh to create the NML which is sent to task. so you (the GUI) _always_ send things to task, and it then parcels them out to io and motion? or do you send things direct to motion or io? iosh can directly manipulate pins but emcsh goes through task -- I believe. OK... if it becomes critical to know later I'll go looking, but I'm trying to keep my sanity by staying localized for now I can appreciate that. wow is there a lot of stuff in there emcmot commands are a relatively clean interface TO emcmot (better if they were documented better) the interface from emcmot is ugly - about 190K of shared data, most of which doesn't really need to be shared The way that iosh manipulates pins is through two c programs inb and outb. but I have no way of knowing which parts are used by higher level code and which are just in shmem for debugging These MUST be replaced by HAL things in order for us to keep sanae. iosh is gonna see some radical changes with hal This shared stuff will need to be sorted out. I'm ignoring iosh for now,I thought it was used only for things like ioshow, not for "normal operation" I'd think that a lot of it can be kept at a local (namespace) level so long as we have a process that can look at it if we need. does tkemc use iosh to control spindle and such, or nml messages to iotask? iosh is completely separate. All of emcsh is direct to task in manual mode. I'm not at all clear on where the NML is directed in AUTO or MDI. ok, good. Paul wrote something called simioControl.c for emc2, it is an iotask that received io related NML messages and just prints out a line to say they were received. that will become the core of the HAL io task instead of printing it will access a HAL pin My impressions are that this stuff is broadcast on the NML and whomever needs it reacts. I think Paul's approach sounds right. As long as it is able to retain the sent, received, done sort of relationships. could be, I'm still working mostly at the level of emcmot commands (lower than NML messages, but I think there is (almost?) a one-to-one correspondence between emcmot commands and motion related NML commands Yes. That is my impression as well. I'm just starting to understand the emcmot commands Seems to me that there can be a "fanout" where a single NML command from the interpreter can cause several messages to be generated by task. I believe so Some of these go to motion, other to IO, etc. from what Fred was saying at Fest, I'm not sure that NML is really a broadcast... maybe I just didn't understand what he was saying You're work at the motion level is a big, good step up. That may just be my impressions of it. but he drew a picture with task/interpreter in the middle, and _separate_ cmd/err/status buffers between it and GUI, MOT, and IO just had a thought... I think I'm gonna take the debug structure out of shared memory and see what happens... in theory, all the status info needed is in the status structure.. but I'm afraid of this comment (Fred, I think): /* FIXME - this has become a dumping ground for all kinds of stuff */ I'm looking at that drawing now. Those kinds of comments are a source for consternation. a little ot question.... the debug structure is 184K! (most of that is the motion queues) shoot les: Did Jon Elson demonstrate a full servo interface for emc that is $250? at names I think so.. I didn't see the demo, but that sounds about right he generates PWM in an FPGA, applies that direct to an H-bridge, and closes the loop with encoder feedback and software no separate current or velocity loop Well one of my primary interests is creating a low cost high performance servo tabletop mill People want this... people even want to give me money to do this it's always good when people want to give you money... I wish I could find somebody who would give me money for working on emcv but it hinges on EMC working and no $900 i/o cards or $300 servo amps it can be done I am a machine designer really... Les - Jon's PWM controller runs from parallel port, $250. The PWM servo amps were $100 each. Then add power supply etc.... Full servo emc with say 10 amp servo amps for...$1000? that is what I need to make a viable product Several years ago, I saw Bert Eding from NL demonstrate system very near what Jon is doing. les: does that $ include motors and encoders? jon's page lists pwm servo amps @ 100 ea ...pwm servo controller at $250 no not the motors the servo controller is the same HW as his universal stepper controller, just differnet FPGA program People want the performance of a $30,000 mini mill for....under $7500 tough nut to crack he counts encoder pulses in hardware and reports that to emc, emc then commands the PWM duty cycle and he generates that in hardware that's what the $250 gets you impossible without emc and custom hardware hmm the $100 gets you an H-bridge with gate drivers (and I think some overcurrent protection), but no inner loops (that's why it's so cheap) The electronics and software can come down in price, the motors and metal will still cost $$$$ for quality. Well my task would be to deal with motors and metal for sure But that metal price is a nearly level playing field for these companies. if the volume was there, you could combine 4 H-bridges and part of the power supply parts on one board for less $, just add transformer Well it is a question of structure design...how to get precision with out overconstrained construction space frames etc And motors...yeah they cost too much even in quantity but....accuracy is not a real requirement of a prime mover so that could be dealt with anyway we think about this...and it hinges on EMC without it we're dead before we start what kind of timeframe? haha YOUR timeframe I guess seriously, weeks, months, half a year, a whole year? I know of a guy that's designing an ethernet connected stg equivalent. and a revived economy...It's gettin better ethernet? got an email? emc2 moves the PID loops to a separate HAL component, so a customized one for Jon's PWM controller or something like that should be no big deal jmkasunich: On the NML buffer and broadcast. Since it can be read from any nonrealtime process, it can be used as broadcast. les: Me. jmk: a year design cycle thanks, rayh, I obviously have much to learn about the higher levels les: in 3 months, emc2 will be "working", in a year it will be working well (unless I get hit by a bus or something) I think that a lot of the higher levels have been bastardized so badly by us that we could just as well start over with a design spec. cool emc3? If it were me I would be tempted to start over... I'm all in favor of re-writing things, and that's exactly what I'm doing where I'm competent to do so... but my area of competency is only about 25% of emc No. I think that as long as we are able to keep emc2 flexible we can adjust the parts. I just don't know enough about coding rt multitasking systems The math of dynamics and kinematics I know I've got Fred's drawings here and much of the spec is in them. I wish a few core folks could meet face to face every month or so, to hash out such things. I'd love to be able to spend a day talking to Les with a pencil and paper and computer handy The frustrating thing for me is that cartesian motion control is just not that complicated (or shouldn't be) exactly I've got a side question, John. If PID is in HAL, how does coordinated motion planning happen above hal? Granted some inverse kinematics can get...well.. a little fussy motion planning is all about saying "here is where you should be" PID is all about "ok, I'll go where you tell me" 12 numbers that's a natural dividing point, in theory you have only two interfaces, position command going out, and position feedback coming back. But suppose that you have one axis with very low accel? you have to tell the planner that well axes with low acel are taken care of by the math the PID will do it's best to keep feedback = command, but if command asks for the impossible, you will get following error But math at what level? now if an unrealizable motion is planned something has to give In emc that is velocity max accel and max velocity info needs to be available to the planner so it won't plan things that the motion system can't do the math is in the planner Ray: math at the level of Rogiers paper posted on sourceforge Or the book "Robotics" that Fred and I both had as a college textbook So PID is separate from motion planning completely? yes motion planning is : ok it's time t I need to be here Not only is PID separate from planning, it is independent by axis. to test emc2, I just connected a HAL signal from command to feedback - no PID at all (and no motors) What about electronic gearing? PID is You are not here and I will do something about it gearing would be handled in the planner Ray - my guess is that they are saying "separate" and you are hearing "Traj-planner will *know* nothing about PID" PID is KINEMATICS... it has no knowledge of even F=MA or other dynamics That's what I'm hearing. Now... feedforward IS dynamics But I think they *are* saying that traj-planner will *understand* the PID limitations... and calculate within them. traj planner will say "here is where you should be" and leave it to PID to actually get there how the PID does that is irrelevant to the planner The TP understands the vel and acel limits and axis limits? And those limits... are expressed/defined in PID, is (what I believe) Ray is saying. But a g-code program does not those limits start as numbers in the ini file, they can be conveyed to _both_ the PID and the TP usually the PID knows nothing of physical limits that's it, Chris. I think of the PID as the embodiment of the accel, and maybe the velocity limits. jmkasunich: IMHO we do need to account for all of those parameters at the coordinated motion planning level. depends on the system... for steppers, it is better for the PID to know - that way instead of generating step sequences that cause lost steps, it generates ones that the motor can follow, and lets following error happen if the commanded position is impossible PID does not define velocity and accel, it just has to try and live with them. the planner MUST know the limits, the PID MIGHT know the limts right Yes, I won't necessarily say that PID *defines* them... but it is the expression of them..it is supposed to be a model of "what the hardware is capable of", yes? Many PID routines are perfectly happy to saturate th I or peg the velocity if you have true closed loop servo, the limits are defined by the motor as far as I can tell pid just tries to force actual-command to zero...and everything fall by the wayside yep, exactly it may or may not be able to, depending on physical limits like amp current limit, but it will try a properly tuned PID will do the best it can, even if it's given impossible commands. If you tell a PID to move from 1.000 to 2.000 instantly, it would (should) make that move as fast as the motor/system limits let it Ok, let me restate this... Every time I try a move w/ EMC, it shuts down due to following error. I know the hardware is capable of more than the 5 inches/min I can currently get. My understanding is that I need to tweak PID in the .ini, so that the computer "knows" what the hardware is capable of. Note I am stepper & open-loop. of course 1mS after you issue the command, the following error will be 1.000... thinking of les's problem again....and assuming that ac motors "might" be cheaper...do we have computational power available to control three motors using an encoder for both angular position and axis position thalx: what is your min following error in the ini file? if zero, you will have problems dave-e: control of ac servomotors is not something we would do in emc FERRROR = 1.000 And I'm doing inches... MIN_FERROR=? Dave - The issue with AC servos, and even Brushless DC is that motors are not well standardized. Drivers tend to be matched to motors. Works fine for OEM machine builders, but tough on hobbiests. Lemme go look (that machine is in the next room) one can actually set both FERROR parameters high enough to do a battery box and plot velocity Les - can you give us a thumbnail sketch of what FF1 and FF2 actually do? ah - min_ is 0.010, ten thou. tnx for the ac comments yes thalx: ok, that's not it ther are actually 3 ff0 ff1 ff2 thalx: try setting FF1 to 1.0 and P to 10 or so... ff0 applies an extra force based on position I've bumped P up bit by bit, currently at 5000. that works for emc2/hal's PID loop, might not work for emc1 tho started at... whatever the generic default was.. thalx: you need to check input and output scale too, I think if they don't match you'll get following errors ff1 applies an extra force based on velocity But sure, I will try it. ff2 applies an extra force based on acel They match; just rebuilt from scratch (generic.ini) last night again. les: I disagree with calling it force I can be other things So ff0 would likely stay zero on a "balanced" mechanical system? Fred walked me thru some stuff on the way to the airport ff0 is of little use usually ff1 is used to help out when friction increases with velociy les: I tend to think of nested loops, current (force) on the inside, wrapped with velocity, and then position, so the output of the position loop is a velocity command, and the output of the velocity loop is a current/torque/force command and if I understood it ....if you plot drive V vs velocity and extrapolate to 0 V that is ffo, i.e. ff0 the the voltage needed to just move the axis How does ff1 interact with "stiction" of the machine ways? ff2 is used to correct some for say a machine part that lags behind due to deflection likewise ff1 is the driving force... and ff2 is the accel term Steve: the I term is the best stiction control Ouch, the I term is so weird in other ways! jmk: My system send actual force commands torque mode? yup and you don't use the tach? emc works in velocity too if you wish pid doesn't care I wonder if some of the confusion is because different amps use the output of emc for differnt things What is the impact on stablility of using torque vs. velocity commands? I use the tach in a separate estop system IMHO it harder to tune a torque system vel cmd with vel and torq loops in the amp can perform better (loops in the amp can have much higher bandwidth) Velocity commands can give smoother motion for slow speeds with a given encoder resolution right, because the inner loop helps Jon E's older amps had analog velocity and current loops but his new cheap system doesn't In torque mode the P term is simply the stiffness of a spring connecting the motor to the tool the new system isn't torque command either though - PWM is voltage, torque is current the d term is a shock absorber the I term is a product of error and time sum error over time the I term is adjustable air springs (sort of) ;-) drop load in a truck, the bed sinks until the springs take up the added load (P), the shocks (D) damp out the bouncing, and you can add air to the air springs (I) to bring the bed back up to its original height exactly...good analogy High speed machines like mine generally use torque mode so the servo amp is a voltage controlled current source (for dc motors) ok, so you do have an inner current loop, but no inner speed loop No I don't voltage controlled current source = current loop to control current so it matches command yes...dac outputs 5v...force =1000 lb dac outputs 10v...force=2000 and so on so dac outputs 5V, amp outputs 20A, and the amp must have a current sensor and loop to do that yup sure does so there is your inner current loop (analog, fast) analog until the PWM part Jon's servo amps have analog current loop and analog vel loop with analog tach feedback actually PWM is analog too really I was gonna say that I can run that way too by setting jumpers it is discrete time, but not discrete amplitude but an arbitrarily high encoder pitch can do similarly and the sample rate is 2 x PWM freq - pretty darn fast maybe we need a chapter in the LyX docs about PIDs and the difference between velocity and torque commands, etc? Now with pid in current mode it says: I am not where I am supposed to be so I will push harder right - potentially harder to tune than velocity mode, but also potentially better performance too. With nested loops, each loop needs to be slower than the one(s) inside it in pure velocity mode but with position encoders is says "I am not where I am supposed to be so I will go faster" exactly about the docs : waht are you thinking about a emc wiki ??? dunno about wikis... I think everybody can much faster put information in than in a Lyx document and you don't have to install something true - LyX is more polished - each has it's purpose the "official" docs should be LyX, but a wiki would be good to gather knowledge when a chapter is good it can be copyed to a good formated Lyx document are you volunteering to set up a wiki? ;-) a wiki can be used like a cvs I don't know how to do it (nor can I host it) if there is an interest i can do so some german guys have started something on linuxwiki I like the idea - we can link to it from Linuxcnc.org http://www.linuxwiki.org/EMC they wanted to make a german translation i can try to put in the english version SteveStallings: we should have a link to that from linuxcnc.org (and to the english one later) ok hmmm, everybody else got quiet suddenly.... maybe i can also ask if i can put our own wiki on one of the servers at the lab i am working in the university :-) still here hehe...wondering if I could do a better writeup on pidff than all the other stuff out there torque mode, velocity mode, tuning of both, etc, would be good stuff. I can make dwgs of nested and non-nested loops, etc Without getting in to a lot of laplace and stuff like most sites do hmm stick with the pickup analogy ;-) (I like laplace stuff but that tends to confuse I think) I could try see the PID diagram in http://www.linuxcnc.org/Hal_Introduction.pdf John - The wiki link has been added and published. looking... page 48 cool - that's why you were so quiet - busy jmk: very nice document thanks So did you go stepper or servo, steve? ;-) les: if you'd like any drawings done for a doc, let me know (I do those with easycad, then export using a postscript printer driver - they import beautifully into LyX of course if you have autocad or something you could do the same sounds good...already thinking about what to write I like your drawings I think in pictures, that's why I like docs with drawings and why HAL is related to schematics/netlists I think about good questions like: If D is a shock absorber why does the machine go crazy if I crank in a whole bunch? heheh analogies only go so far yup that's an interesting point - I think I can grasp the reasons, but can't put them into words I think of it in terms of nyquist plots and such...but that would not be the way to describe it a shock generates a force that opposes velocity, and applies that force directly to the velocity. D term generates a force that opposes velocity feedback, but applies it to the output perhaps the lag between output and feedback contributes the other difference is that a shock is passive - it cannot supply energy Well that is the crux.... but terms in a PID are directed thru the motor, which can supply energy ...and is an integrator right need other analogies... hmm active suspension? KISS nah...no one is familiar with them yup kiss the analogies need to be simple, not perfect Ahh well something good to think about while in the loo... Ok John... the conversation seems to have lost its steam... I'm ready to report my results. w/ P=10, FF=1.0, I can get up to 12 in/min. @13 I get following errors again. My assumption is that I should be able to get up to 20 in/min. (Sherline, stepper drive, open loop) well with steppers, the real limit is lost steps... Right, and that is something one can usually hear. My belief, anyway. following error doesn't mean the motor can't keep up, it means PID isn't keeping up All the PID FF stuff there is for a virtual machine anyway right? Ok. I remember the presentation at EMC fest for PID tuning... to be honest I don't know what steppermot/freqmot do, and I don't want to know But that's for closed loop only, I believe. I have only found a bit in the Users guide about PID tuning for steppers.. les: in emc2, PID works in velocity mode, and it's output becomes the frequency command for the step generator I'm sorry, thalx, you have the two worst folks here to help you - les does servo, and I don't use emc1 ;-( I am trying freqmod, as there was a note in the user guide that it was simpler to get going. *shrug* well....open loop stepper guys are tuning a servo loop...so it has to be virtual, right? I believe it's done that way because EMC was orig. built for servo systems, and handling steppers was just a kludge thrown in at the last minute... the output of the PID determines the step rate, and a count of the generated steps is the feedback position Thalx has it right I think well yes, but it's a pretty decent kluge The issue is how to control maximum accel (which is what steppers care about most) when the "feedback" is instant (as best I know). hmmm in my case I have an accel limiter at the input to the stepgen MAX_ACCELERATION? so the PID can ask for an instantaneous accel, but it won't get it, and the feedback (counted steps) will reflect that right but it will be stable but I don't know how (or if) emc1 handles max accel I know it works evn on jogs and homes might do it at the planner level (the "never ask for the impossible" approach) thalx: do you have backlash comp? jogs are how I'm testing it. It slows to keep from violating the max acel haven't touched it, so whatever the default is from generic.ini. I dunno the default, probably BACKLASH=0.000 if not, make it zero Checking... yes, zero is default. ok Ok, well, I have more to learn, so don't feel like you gotta step me thru anything else. I'm more from the school of "read the manual THEN tweak with knowledge", rather than "just tweak and see what happens and maybe you'll learn something from it" usually wise, especially when working with things that can physically hurt you. the problem is when the manual is lacking It only took me one argument with a flycutter to learn who has the right-of-way... Lacking or nonexistent. Or too scattered. I have, I think, 10-15 different PDFs, all about various aspects of EMC. And I come from the digital side of the tracks... thought I was safe w/ steppers. Heh. But anyway, thanks, one doc I read said just up P until you get what you think is right... but you got me much more in the ballpark. I will find out...you guys should not be having to to servo tuning les: I'm thinking of doing a stepper module for HAL that integrates the PID and step generator, and is "pre-tuned" based on the max_acc and max_vel limits it would take in pos-cmd and emit pos-fb and steps, and thats it I guess ideally the TP for a stepper might like to know a torque curve.... nothing like a servo of vourse no need to get that sophisitcated course just specify max_acc and max_vel such that the motor can handle anything inside that envelope ha I typed about the same thing there might be some unused performance at low speeds, but so what makes sense I used steppers on machines a long time ago loved the sounds servos are cheaper on industrial machines I would like to make them cheaper on hobby/small shop machines as well Cost of power tronics like you do are a big factor what power level are you aiming at? V/A? gecko is 80V 20A, jon's thing is higher V, but about the same A (or maybe only 10A) not a lot....no more than a couple hundred VA/axis it isn't really _that_ expensive an H bridge is only 4 fets and 4 gate drivers I know...like the H-bridge power chips out there I don't - I'm an old dinosaur and would rather use discretes But I am not seeing a product in the right market niche that reflects this chips are single sourced if you want a volt controlled current source you need current feedback too I am working on moderate power servo drives, but due to market forces, the step/dir input style will come first. Cheaper tronics, space frames, EMC, kineamatic construction, put together that can get messy, either source resistors and complex circuitry to deal with the pulsed nature of the feedback, or series resistors and very good diff amps, or isolated sensors like hall effect Steve: Is the hobby market stepper because of the many surplus step motors that we industrial users had to change out? Mostly because hobby users ASSUME that steppers will be simpler. They are intimidated by all the connections to servo feedback. it's stepper because it's easier (less wiring) and cheaper (motors only, not motors and encoders) hmmm....the guts of the encoder I just designed are $2.50.... the difference in cost becomes very apparent as you get smaller just an example nobody will actually sell it for $2.50 though haha It sells for $20 in large quan compare servo costs to stepper costs at the NEMA 23 size What one knowledgable OEM can do, and what hundredes of independent hobbiests do are two very different things. yes there is kit/componet vs plug and play too component there will always be a size/power breakpoint, larger = servo, smaller = stepper. That point is moving down, but it's still a little higher than NEMA 23 in the old days even NEMA 42 was stepper (BOSS) Well I think of moving that point down further now 42 is all servo, 34 is mixed, 23 is mostly stepper Too many years in the Auto business...constant cost pressure What I am waiting for is brushless motors available from distribution stock at reasonable prices instead of everything custome built to order. yes...we are all waiting for all portable power tools to be brushless Why aren't they? cost tronics vs commutator? Quotes I am getting are $100 each in hundreds for large range NEMA 23 and $200 each for 10 of same. Some price slope!! brushes and commutators are pretty damn cheap I guess and even for servo control, it takes more transistors to control a brushless - 6 vs. 4, and 3 current sensors vs. 1 I see for things like tools, the diff is bigger, zero transistors to control brush motor (maybe a triac for speed control on a drill or something) Les - it's "what will the market bear", not "what does it really cost". Until the market gets defined with a couple orders magnitude in quantity, we won't get the factories to crank up output. But we are getting closer, many washing machines now have VFD's or brushless DC motors. hmm true - we have looked at that market, but stayed out - no margins Well we try to pull tricks to get ahead of the curve...like my using computer fan ball bearings in a car part My next question was gonna be, "who is going to go first", meaning, which market? Hammacher Schlemmer hand power tools? the bottom end VFD price is somewhere around $100 But... if some appliances are going there, hope is not lost!! tup yup factory cost on those appliance VFDs is probably around $40-60 they make it up by simplifying gearboxes, eliminating run caps, and offering features to the high end of the market. the generic washing machine will stick with a conventional motor for many more years though, cause of cost Think of the day when a brushless DC motor can be gotten at any auto parts store as a 'starter motor'... I hope it comes before I die! don't hold your breath starters are very high torque, very high current, so the silicon cost will be higher wiper motors, window motors, etc, will come first hmm before that the computer may fire up the motor with one compression stroke with no starter! switched reluctance motors are being examined for those applications Don't forget steer by wire.... or hybrids where the generator is the motor oops where the generator is the starter Well, I was thinking 30 years... but maybe not. There are already cars on the market with electric assist power steering. I bet those are brushless or AC (or maybe SR) motors, because good control of speed and torque is important In the automotive market we went PWM about 15 years ago...it was too early and a total disaster Help me out, describe the configuration of a SR motor. discrete coils in the stator, salient poles in the rotor rotor pole count != stator pole count energize a stator coil, it attracts the nearest rotor pole, before it arrives, energize another stator pole you might have a three coil stator and a four pole rotor, for example usually need absolute position feedback like brushless DC, but no rotor magnets, so they're cheap Great session today Matt, get the log. judt thought i'd drop in for a minute or 2. been really busy trying to become a re agent & haven't had time to work on emc stuff... btw, I'm on a cable modem connection through a wifi link, so I may last more than a minute now! is this a one time thing, or have you come into the 21st century? aha...so what are the stepper guys pid tuning? jmkasunich: it's permanent! unless my neighbors move... welcome to the internet! Or the tree sways too much! 8-) I'm serious, the difference between dialup and always on is that big more than just bandwidth les: they're pid tuning their loop. I know that doesn't make much sense in a stepper system,,. no it does not...feel free to use your new connection to explain Problem is PID is a lousy way to try to limit acceleration, and that is what steppers really care about. les: not sure I _can_ explain it ;) , all I can say is that the freqmod module acts like a servo drive. It accepts velocity commands and returns position data. There's no differnece between how the pid is used (it's the same code). I guess the main thing to remember is that there's no delay in stepping, when steps are issued, they are assumed to have occurred. so somewhere in freqmod there is a virtual servo...but it does not use the .ini components les: so as long as P is greater than 0, the main term that affects steppers is ff1 (or so I think anyway). hmmm what source file is this stuff in? Matt, Les - I think the is is that there is no intentional servo model, just the implied one with perfect response bacause feedback is instant. OK, I take it back partially, the response is from the "voltage" to "frequency" convertere. les: What Steve said... the code is in emcmot.c... I will look at that now les: emcmot.c line 3973 freqfunc() les: position is returned in emcmotDebug->stepperCount[axis] (line 4087) I see...so it is an idealized instantaneous virtual encoder les: nice phraseology! yes, an "instantaneous virtual encoder". les, now, whether our current pid algo is suitable for this type of system is debatable (by people who know more than me about control stuff). The algo seems ok to me...could use another real pole in D and a notch filter but digital filters do eat up processing time les: it runs at the servo rate, so we could probably add code without running overtime. les: also John's making the pids a separate hal module so in emc2 we can easily experiment with new implementations... Many controls put a low pass on the d...and ideal differentiator is unrealisable OK, so the acceleration is limited by the PID loop how? les: I hope that cleared up your understanding of whaat happens in freqfunc. steppermod did some pre-conditioning (or something, I don't really understand what it did) to the pdmult value. yes thanks Steve: if full servo torque mode low P=low force=low MA Les - I was referring to the unique case of Freqmode. What limits acceleration in that case? SteveStallings: Accel was limited at the traj planner level by the global Max Acceleration variable. FredP just put in per axis max accel I would think that would also happen in freqmod but I am not a stepper guy of course matt: when did he do that (I'd like to copy it to emc2) So maybe all those struggling to "tune" Freqmode should start by looking at their Max Acceleration variable instead. and just put in some P value only? jmkasunich: about a week (or a few days) after NAMES Les - I think that would model what other step pulse generator do. Per axis acel is cool. My X does 1 g but my lighter Z could do 10g les: should still have FF1 = 1.0 jmk: I don't understand the velocity feedforward requirement just a quirk of the algo? I do use FF1 and FF2 in my full servo machine works great IFF the output of the PID is the frequency(velocity) command to the step generator, then FF1=1.0 is in theory all you need a little goes a long way I understand It's just so it can see it FF1 lets the stepgen start moving the motor as soon as the commanded position changes, instead of waiting for an error to develop. Since steppers are by definition perfect (they always move exactly as commanded), in theory FF1 is all you need and error should never develope So your'e saying that without FF1, movement is derived only from the developed error?? right basic PID _always_ needs an error before it moves "I should be here, but I'm not, guess I should move" And the amount of error developed is due only to the time lag required to generate the pulses. right For FF no error is needed...it's like " I will go faster than i'm told...period" Or are the acutal pulses not counted, and the feedback sent immediately. dunno... now I'm getting confused - I know how emc2 does it, but emc1?? or "I will push more as I go faster" for torque mode Perhaps it would be useful to compare Freqmode to Jon Elson's hardware pulse generator. yes Jon's feedback does indeed have the delay as his feedback tracks the actual pulses issued. Well Matt mentioned velocity loop in freqmod but for me I use FF1 to model the increased friction force at higher speed and compensate then PID only has to deal with errors of the model les: you are doing force mode, freqmod, Jon, and emc2 stepper all use velocity mode =better phase margin right I understand there is no vel loop - steppers either move at the commanded freq or they stall Oh I remember all too well mid band resonances and slipped steps