Ed Nisley <[EMAIL PROTECTED]> wrote: > > I would assume the motor(s) in question are being > > microstepped? > > Yup, quarter-stepping. It's a modified Sherline controller > with custom firmware that I described in my Circuit Cellar > magazine column a few years back.
Oh, I didn't realize we had a published author here ;-) I googled for the article(s), found out they're not available online. I used to have a subscription to Circuit Celler Ink back in the 80s and early 90s, but at some point I stopped getting it. I'd like to read about your drive. Is there any way you can post it (or if publishing rules and copyright prevent public posting, can you email me a copy)? > I decided to figure things out from first principles. Thats my favored approach. > The complete INI and HAL files are at: > http://pastebin.ca/266891 > http://pastebin.ca/266894 You have 16000 for the scale in the ini file. At 800 quarter steps per rev, times 20 revs per inch, that is correct. Just checking - first principles and all that. > Here's my reasoning; but check to see if these values make > any sense... > > The controller can run a bit over 8000 quarter-step/sec = > 2000 full step/sec = 10 rev/sec = 0.5 in/sec = 30 in/min. > That's aggressive for a Sherline, although I long ago > captured the end of that Y axis leadscrew in a bushing > block to keep it from whipping around. > > The max step rate means a 125 us period. I set base_period = > 25000, giving 5 ticks per step. The controller firmware > triggers motor steps on the falling edge of the Step > signal, so the timing parameters in the HAL file are: > > steplen = 2 > stepspace = 3 > dirsetup = 1 > dirhold = 3 > I applied a 'scope to the pins of the PIC microcontroller > and found the RC filters knock the rise and fall times to > about 20 us. That means a 50-us Step pulse rises to full > amplitude with no problem. > > Back in the INI file, the settings are: > > default_velocity = 0.0167 (slow enough) > max_velocity = 0.50 (30 in/sec, at best) > default_acceleration = 2 (limited by axes) > max_acceleration = 4 (ditto) > > All three linear axes are identical: > > max_velocity = 0.50 (optimistically) > max_acceleration = 0.5 (see below) > stepgen_maxvel = 0.60 (about 10% up) > stepgen_maxaccel = 0.6 (ditto) If you use halmeter to observe stepgen.0.maxvel, you'll find it is set to 0.5 (inches per second) even though you are trying to set it to 0.6 from the ini file. Your steplen is 2 and stepspace is 3, so the fastest possible step rate is one every 5 periods. With a 25uS period, that means one step every 125uS, or 8000 steps/sec, or 0.5 inches per sec. Since stepgen is constrained to obey your steplen and space parameters, it won't accept a maxvel greater than 0.5 inches per second. That means you don't actually have any velocity headroom, and will lead to following errors if you try to run at 30 ipm. > ferror = 0.015 (seems OK) > min_ferror = 0.002 (ditto) > > In the middle of long jogs the thing actually ticks along at > about 320 us/step = 3000 step/sec. So it seems EMC2 limits > the velocity to 11 in/sec. I don't know why that should be > true, as lots of you folks are running -way- faster than > that. I don't know either. Feed override set less than 100%? Jog speed slider set less than 30 IPM? I can tell you its not a stepgen issue. The EMC motion controller is generating a position command, and stepgen is trying to make the motor follow it. If stepgen fails to do so, you'll get a following error. But if the command itself isn't moving as fast as it should, thats not stepgen's fault. If you run one of the "sim" configurations, there is no stepgen or other motor control at all. We simply feed the commanded position back into the motion controller (as if we had perfect motors). So you never get a following error with the sim configs. Do you get the same slow jog running sim? Which GUI are you using? IIRC, tkemc (and maybe axis) sets the initial value of the jog speed slider to something less than max speed. Are you turning it all the way up before you jog? You might try some MDI commands instead of jogs to see what is going on. G1 moves with an F word let you specify the speed. G0 moves should run at max speed. (Both are subject to feed override, but are not affected by the jog speed slider.) > The max_acceleration value is experimental. Below 0.4 the > motors wind up veeery slooowly, Accel of 0.4 means 0.4 inches per second squared. If max speed is 0.5 inches per second, it will take 1.25 seconds to get there. Yes, that is very very slow. I think most people with Sherlines are using values in the neighborhood of 10-20 for acceleration, but I'm not sure. There are a couple of Sherline users on this list who can probably give us the real dope. > above 0.5 it produces > following errors. That seems to be an unduly small range, > but the raw step pulse parameters shouldn't be the limiting > factor. Did you raise stepgen_maxaccel when you raised the main max_accel? If not, following errors are guaranteed, because stepgen _will_ obey its accel and velocity limits. You can check those values using "halcmd show param stepgen", or by using halmeter. The relevant parameters are stepgen.0.maxvel and stepgen.0.maxaccel (that is for X axis, change the 0 to 1 or 2 for the other axis). stepgen.0.frequency is also usefull, that is the actual frequency in Hz that stepgen thinks it is making. > I based the ferror values on the "under half a turn" > principle, then cranked it down until I got following > errors. > I think these settings are sub-optimal, as G1 moves at 20 > in/sec (actually much less) around a 0.5-in square produces > really nice fillets on the corners: perhaps 1/8" radius. > Obviously, slowing down reduces the fillets, so it's an > acceleration thing. The motors are audibly winding down for > the corners, so I -think- they should be able to withstand > far higher acceleration, but higher max_acceleration goes > into following-error territory. My personal approach to setting up stepgen isn't neccessarily the most popular, but it is rather "first principles" and it lets you really understand what your drives, motors, and machine can do. That method is simple: throw out most of EMC and do the initial tuning with just stepgen and a signal generator. That eliminates a ton of variables, and lets you rather easily see what your machine can do. Once you know the limits, you put them in the ini file and bring up the rest of EMC. > Perhaps this is caused by the internal PID loop tuning for > the steppers? Or maybe it's just another round from my > footgun? You are hitting a limit somewhere. If you are testing with EMC, you need to change both MAX_VELOCITY and STEPGEN_MAXVEL in the ini file, to always maintain some headroom. Same with acceleration. (And of course after each change you need to restart EMC.) If you are testing in a "standalone" mode (just stepgen and a signal generator) you can change the stepgen limits interactively from the keyboard, and immediately see the results. > Anyhow, these settings have completely (uh, so far) > eliminated the "half turn the wrong way" and "completely > wrong direction" behavior, That's good. > but I can still hear the motors > taking an occasional hit from the bogus Direction signals > at the start of some motions. > > I connected a counter to the Step signal and found that it > always squirts out the correct number of Step pulses for > either move, so the Direction signal really is backwards > for a bit. > > When a motor takes a hit, it moves a few mils short of the > command, anywhere from a fraction to maybe 0.007 in). With > quarter-stepping, 0.001 in = 16 steps, so the motors really > do get confused by those Direction glitches. > > These events are fairly rare and I did not have time to > capture screen shots that provide more information that we > already know. > > It's entirely possible the hypersensitivity could be due to > an error in my controller firmware, but this seems to be > new behavior with EMC2 and may be explained by the (known) > Direction glitch and (supposed) motor mechanics. > > I'm off on an unexpected journey, but should be back by this > weekend. I'll try scoping the PIC microcontroller's I/O to > nail down exactly what's going on when the motor takes > those hits. Does the controller sample the step signal at some fixed rate or does it get an interrupt when the step input changes? If sampled, what is the rate? When does it sample the direction input? After it sees a falling edge on step? (I found the source code from the controller, but I don't read PIC assembly all that well, especially without the article or the board schematic for background.) Since we have people using (I believe) the original Sherline controller with no problems, I have to wonder about your mods. Not that they are "wrong", but they may place constraints on the input pulse train that the normal Sherline drive (and Geckos, Xylotex, etc) do not. If that is the case, I'd like to identify the constraints and see if we can make stepgen obey them. Presently the constraints that stepgen obeys are: 1) direction is valid from "dirsetup" periods before the rising edge of "step" until "dirhold" periods after the falling edge of "step". 2) pulses on "step" are always "steplen" periods long. 3) pulses are never closer than "stepspace" periods apart. 4) the pulse train frequency will never exceed "maxvel" times "position-scale" pulses per second. 5) the pulse train frequency will never change faster than "maxaccel" times "position-scale" pulses per second squared. 6) the result position (obtained by counting output steps) will never deviate by more than 1 step from the commanded position, unless that would require a violation of constraints 1 thru 5. As an example, if "position-cmd" makes a step change of hundreds or thousands of steps (say 1 inch, with your scale of 16000), the pulse train (and "position-fb") will accelerate at maxaccel (constraint 5) until it hits maxvel (constraint 4) then cruise for a while, then decel at -maxaccel, and finally stop within one count of the target position. There maybe be a one step overshoot and thus a reversal at the end of the move. During the majority of the move, constraint 6 is violated because its impossible to track a step function. Note a couple of things. First, constraint 1 does NOT prohibit changes on the driection pin. Direction can change state and then return to its original value without a step being issued, as long as setup and hold are obeyed. Second, constraint 6 does NOT prohibit a reversal in mid move. If the actual position gets more than a half step ahead of the target position, it is possible to generate a step the other way to correct that error. This will only happen at low speeds, because the accel constraint makes it impossible to reverse if you are going very fast. When running with EMC, you must limit the commanded accel and velocity to somewhat less than the stepgen limits, because EMC compares the command and feedback and will trip with a following error if the diverge. When running stepgen alone, you can put a step function, or anything else, into its input, and it will do its best to track it. That is why I tune with stepgen and a signal generator. I can put a 3 inch squarewave at 1/60 Hz into stepgen, starting with very conservative values for maxvel and maxaccel. Then I start increasing them until I determine both the velocity and the accel rate that cause lost steps. Knock between 20% and 50% off of those levels when configuring the machine. Regards, John Kasunich ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
