Ed Nisley <[EMAIL PROTECTED]> wrote: > On Tuesday 28 November 2006 21:41, Chris Radek wrote: > > Have you also observed these incorrect direction changes > > on halscope hooked to the parport pins (at the HAL > > level)? > > Nope... I figured the first thing you'd ask is whether I > could hitch up a real scope and verify the actual pins. In > any event, I'm an oscilloscope kind of guy and don't trust > this software-monitoring-software stuff.
Understood (I'm a scope guy too), but in this case halscope is the best way to see what is going on inside. > HALscope can capture only the leading edge of a move, > because I must set it to sample at the BASE_PERIOD rate in > order to capture the step pulses. Alas, the post-trigger > half of the buffer doesn't have enough samples for anything > but the shortest of moves, much shorter than a doink on the > keyboard. The sample rate is going to be a limitation, but there are a few things that can improve that. 1) you can move the trigger point closer to the beginning of the record - use the "position" slider in the "trigger" sub-panel. If you set the trigger point at the far left, you can double the amount of post-trigger storage. 2) if you use only two channels you can double the record length. However, four channels will probably be needed to see what is going on. 3) it will probably be possible to switch to the slower servo thread not too long after the serious troubleshooting starts. The code that runs in the high speed thread is quite simple, and is also (if I recall correctly) incapable of reversing. The decision about what direction to move and how fast to go is made in the slow thread, and the fast thread just generates the pulses. If there is a bug, it is almost certainly in the slow thread code. > I think the "Multiplier" setting should solve > that, but the up-down arrows are grayed out and changes to > the numeric value don't stick. Hmm.. that's not right. I should investigate. > I set up both HALscope and the real 'scope to monitor > the Z axis, loaded the cam milling code (with the mill > disconnected), and will let it run. > > [time passes] > > Worked perfectly, of course. Wish I had the mill running, I > might have gotten a good cam out of the deal. Figures. > That suggests turning on the HALscope thread futzes with > the timing just enough that the direction-setting code > either won't misbehave or misbehaves -much- less often. I'd be rather astounded if that was the case. I spent quite a bit of effort making sure HAL in general and stepgen in particular are free of non-atomic operations and race conditions. Nothing is impossible, but such a timing condition seems very unlikely. > I did, however, see one anomaly. The cutter moves upward at > one point during the milling and the direction signal went > high - low - high before the step signal started, on both > the HALscope and the real 'scope. It was up for 1 ms, down > for 1 ms, then back up again. About 25 ms later, the step > pulses began ramping up for the Z axis move. That kind of thing can happen. I'd expect to see it more at the end of a move than at the beginning, but both are probably possible. The code in the servo thread that decides how fast the base thread should generate pulses needs to enforce the velocity and accel limits, and with an arbitrary input signal that is non-trivial. Minor (one step or less) overshoots followed by reversal back to the original position are not out of the question. An overshoot of less than one step could result in the direction output changing while the step output does nothing. > Manual jog toward -X. The direction signal went high for 2 > ms, low for 11-ish, then high again. The first step pulse > is smack in the middle of the low glitch; it's the first of > many that appear to be ramping up normally for the X axis > move. I won't be able to take a close look until tomorrow evening. Any additional information you can provide before then would be appreciated. In particular, halscope pictures at a fast sample rate showing the following: stepgen.N.step stepgen.N.dir stepgen.N.rawcounts stepgen.N.frequency rawcounts is the value used as feedback - if it is wrong, then everything else will be wrong. It is updated in the fast thread - you should see it change for every step pulse. It should always increment or decrement based on step and dir, and nothing else. Even ff there is a step in the "wrong" direction, if rawcounts correctly records that step, then the higher level position loop will correct for it. But if rawcounts misses a step, or records it going the opposite direction, then the error will accumulate. frequency is the command from the slow thread to the fast thread. It should not be changing except at the slow (servo) rate, and the results on step and dir should be consistent with the value of frequency (which is in Hertx). Also, halscope pictures at the servo rate showing the following: stepgen.N.pos-cmd stepgen.N.pos-fb stepgen.N.frequency (actually, having the difference between cmd and fb at an expanded scale would be even better - that could be done by adding a sum block: addf blocks sum2=1 connecting its inputs to the relevant signals: linksp (whatever the X pos command signal is) sum2.0.in0 linksp (whetever the X pos feedback signal is) sum2.0.in1 connecting a signal to the summer output: newsig Xposerr float linksp Xposerr sum2.0.out and inverting the feedback so it is subtracted from the command: setp sum2.0.gain1 -1 The value of frequency should always be such as to drive the error toward zero, while still obeying the maximum velocity and accel limits. > Screen shot attached. I think it'll get scrubbed from the > bulk list, but the CC to Chris should work. Actually I got it on list. Unfortunately without more of a "big picture" view its hard to say much about it. > I'll try returning to 2.0.0, I doubt that is worth the effort. There have been very few changes to the step generator since 2.0.0 Versions 2.0.0: known bug 1: while a channel is disabled, its internal data is not updated, resulting in a possible following error when it is re-enabled. known bug 2: if channel N is disabled, channels after N are also disabled even if they are not supposed to be. (usualy invisible, because the most configs disable all channels at the same time) Version 2.0.1: fixed bug 1 (we were still unaware of bug 2) Version 2.0.2 and 2.0.3: no change from 2.0.1 Version 2.0.4 (the latest): fixed bug 2 > but it'll be a while before > I have anything more to relate: some -real- work's gotta > get done before I can play in the shop again! Understood. I'll see if I can replicate the problem, but any additional info you can provide would be helpfull. 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
