John Kasunich wrote: > John Kasunich wrote: > > >> I'm not going to go through that >> learning curve again just to try to find a bug in proprietary code. >> > > Perhaps that was a bit too dismissive. I'm not going to try to figure > out the code at home by myself, but I am willing to study it at the > workshop in Wichita (assuming you are there). The difference is that > I'll be able to ask you questions. > > The problem is that I won't have the software to change the FPGA code with me at the Fest. But, maybe I can now use the free version of Xilinx Ise that runs under Linux. I'll see about getting that on one of the computers I bring to the fest. But, I think I have already found a potential bug, while trying to write up how it works. The "index pulse seen" logic is totally separate from the "reset count on index pulse" logic, which seems on the surface to be a "really bad idea"! I just can't explain the sensitivity to a specific thread pitch, or the frequency of ocurrence. It looks to me like it should only fail when a VERY rare number of critically timed events happen just so. I have to go over the driver code again, but I think the logic there was that I KNEW, at the time, of this critical timing sensitivity, and so I required the spindle sync to be turned on for so many servo cycles before it was tripped, to be sure the driver couldn't have gotten the pulse seen signal before the reset counter logic had been activated. > It is one thing to hunt for race conditions, etc, when you know exactly > what the code is supposed to do (because the author just explained it). > > It is another thing completely to have to dig into a large block of code > in an unfamiliar language, then figure out what the author was trying to > do, and then try to find a subtle problem, with no guidance. Your > unsolicited dump of code in my mailbox was asking for the latter. > > I tried to explain in words what was going on there. There are really only about 3 lines of code important to the spindle sync stuff. I just wish I knew how to get the thing to fail here. I'm wondering if Mr. Harris' problem is actually due to a very noisy encoder index pulse that is somehow able to trip the index pulse seen FF but not the reset counter FF. Extremely narrow pulses on "Z" might be able to do that. I have to look at the VHDL again.
Jon Jon ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
