I just want to ask suggestion about what kind of oscilloscope as hardware do you recommend to I can used that to tune up my motor.
I sent two e-mails to list with subject “Problem with Hal Scope use”
Maybe use external oscilloscope can be a solution?
Thanks
aramk
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Wed 11/29/2006 8:58 AM
To: Enhanced Machine Controller (EMC)
Cc:
Subject: Re: [Emc-users] Mysterious direction-signal changes
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
<<winmail.dat>>
------------------------------------------------------------------------- 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
