Hi, Art
The previous Indexing code needed a very large window to allow Mach to see the change of state of the index pulses.
Was just checking that, In fact this new way of getting Index and Timing values are the same in Scope/Code structure now gathering the Data.
As I stated in previous Post, "Hear are 3 pic's, First is my cpu with puls ferq issues it seam's to thread and not have issues".
( The snap shot was taken with a cut in progress and with a Stable Pulse Freq. During the Scope Data gathering Time ).
( Simulated, Signal Source is a 555 timer for "Timing" with a Divide by 10 Decade Counter/Divider (MC14017BCP) IC used, Both computers sharing the same Data.
The Index Base RPM, Threading Lock RPM and Slot Base RPM are the Same and quite stable on this computer.
"the other cpu still has issues." Pic's 2 & 3. With the Main PCI time base being Large and the Scope readings off Scale as before, But you can see the "10" Number of Slot's & Index Base RPM's are consistent & the Same on Both Computer's.
As you know all this information takes allot of time to gather and keeping it sorted out, So please let me know if it doesn't make Sense.
More to follow in a Bit, A comparison with Index/Timing pin's set the Same.
Edit: Well as usually happens, Had 2 "Comp. 5" opto's sensor's to test with, ( Go figure, "Art" ), It dose appear to be an issue with the "Index" opto's.
( Digging the potting compound out to see what "Emco" did to make them so different in response Time ).
Any way for the computer that threading works with (Pic 1), The values are very close if not write on the money, Other computer, (Pic 2) is still not threading and showing bad data,
If I can find the other MC14017 chip's buried on my desk, I'll do some 100 to 1 comparisons with the 100 slot disk on the Compact 5 while I find another couple of opto's, If the Digging isn't a Success, Eating some "Chile" to see if I can make the Heartburn Worse.
Thanks, Chip