Jeff Epler wrote: > A few of us have also been able to reproduce these glitches > in the stepgen component's output. > > http://www.electronicsam.com/images/KandT/headjog.png Timebase is too slow to be sure about the previous one...
> http://www.electronicsam.com/images/KandT/headcom.png > http://www.electronicsam.com/images/KandT/oops.png But the dir glitches on these two are at least one servo period long... > http://emergent.unpy.net/files/sandbox/halscope-stepgen-bug.png And its even more clear here - they might even be two servo periods long. > so far I've only seen it happen at the start of the very first > jog, and the step pulses issued (including the "glitchy" one) > seem to occur only at low speeds Yes - all of the cases shown are well under one step pulse per servo period... more like one step pulse every 10 servo periods. The problem is almost certainly in "update-freq", NOT "make-pulses", so troubleshooting should focus there. Might have to add some HAL params so we can see some of the internals. I have a feeling this is caused by the "pretuned" algorithm that attempts to meet the velocity and accel limits without a real PID loop that needs manually tuned. > and are recorded properly by stepgen in its position > feedback, so that position should be maintained As expected - that code is pretty darned simple, and I'd be shocked if it was broken. > That said, I sure want to get to the root of this problem. So do I. We're visiting some friends thie evening, so I probalby won't have time to try much tonight, but I'll certainly dig into it tomorrow. > I'm about to try again but this time using the setup and > hold times you mentioned in your earlier. That sounds like a good idea. I don't expect them to make a difference, but a negative result still tells us something. The setup and hold logic is in make-pulses. If changing the setup or hold or pulse width _does_ change the result, then maybe I'm wrong about the problem being in update-freq. Ed Nisley <[EMAIL PROTECTED]> wrote: > Although the screen shot showed a single step pulse in the > middle of the direction glitch, this is not necessarily the > case. What pointed me toward the problem was watching the > stepper motor knobs spin the wrong way: up to half a turn > before the motor goes THUNK and abruptly spins the correct > way with (obviously) no decel or accel ramping. OK, I _thought_ you were describing something far more radical than your scope picture showed. I also think that what you are describing has absolutely nothing in common with what Jeff has been able to reproduce. The only way the motor can turn a half turn the wrong way is if the direction signal is wrong AND the software doesn't know it. If the direction signal is wrong and the feedback is working correctly (as Jeff's last plot seems to show) you would _very_ quickly build up a lot of error, since the command is going one way while the the feedback is going the other. That would either result in the control loop correcting the problem long before a half-turn, or a following error. Please make sure your following error limits are set to well under a half a turn of the motor. Usually you can set the limit to maybe a 50th of a turn. If your limits are tight and you aren't getting a following error even when the motor goes backwards, that can rule out a lot of things. If the motor is turning a half turn backwards, and stepgen block thinks its going forwards, then the problem has to be between the outputs of the stepgen block and the actual motor driver. Could be the hal interconnect, the parport driver, the actual parport hardware, cabling, or drives. I understand that you've observed the signals with a real scope, which tends to rule out the drives and cabling. > So, in general, this is not a subtle problem where the > direction signal is off by a smidge, no big deal, just one > step the wrong way. Not at all. Unfortunately I have a bad feeling that says I'm not gonna be able to reproduce this - if it was easy to make it happen, somebody would have seen it before. > Unfortunately, it's also not very frequent and capturing > all that HAL trace data will take a while. Worse, the > data probably won't all be from the same oops. We just need to capture one event. The trick is triggering on it. Does it seem to happen more on one axis or another? Could you wire the step and dir pins of the worst axis to a couple of input pins on the same parport? If so, you might want to read them back and compare to the output values, and use that result to trigger the scope. You could use the the match8 HAL component to do the comparison. Make sure it runs in the base thread, after reading the parport, and before running stepgen.make-pulses. Use the output of the match8 to trigger the scope. Note - you can have the scope configured for 4 channels, with one of them being the desired trigger channel, then turn off the trigger channel (which turns off data acquisition only, not triggering) to allow you to add one more viewable channel. So you can capture 4 "usefull" signals while triggering on a 5th (the match output, which isn't all that interesting itself). If you see one of these half-turn reversal events and the match8 doesn't say there was a mismatch, then I'd look closer at the hardware. If there is a mismatch, we've narrowed it down a little more. So we can review it, can you paste your ini file and you hal file(s) on www.pastebin.ca, and post a link to the list? 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
