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.

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. 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.

Evidently, the Lords of Cosmic Jest have taken an interest 
in this project, as I can't get it to fail this morning. My 
esteemed wife, who spent many years doing software testing, 
reminds me that this is typical behavior.

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.

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 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 would not have caused a motion error, because no step 
pulses occurred during the direction glitch, but it's the 
same type of misbehavior as when the problem occurs.

Another datum that may help. The errors tend to accumulate 
as though the direction signal were erroneously low. I have 
seen a few high glitches, but the tendency is definitely 
the other way. The bad bit doesn't come from the Great Zero 
Ocean, but that's the way to bet.

[time passes]

AH-HA! Caught one!

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.

Screen shot attached. I think it'll get scrubbed from the 
bulk list, but the CC to Chris should work.

I vaguely recall that something like this was corrected a 
while ago, but don't remember the details. I'll try 
returning to 2.0.0, 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!

Onward...

-- 
Ed

Attachment: Direction glitch.png
Description: PNG image

-------------------------------------------------------------------------
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

Reply via email to