Well, I was afraid of this - maybe this is another strong
indication of a software cause for my problem with the ppmc
driver. I uncommented 3 kernel message writes in the encoder
section of the driver (enabling index reset, clearing it when
the index pulse is seen, and cancelling it if somebody else
were to clear the hal signal.) Well, I ran it for an hour
without a single bobble! Hmmm, now that I think about it, I
probably had those debug writes active during all my testing,
and turned them off before one final test and then committed the
driver changes. Sheesh, I used to have to track down junk like
this in people's Fortran programs where they had mismatched
array sizes in common blocks. I was hoping that was a bad memory!
So, is this the typical mess where things get moved around in
memory when you put in debugging statements and that fixes the
problem? Or is it a timing change due to the added kernel
writes? These rtapi_print_msg commands are only executed on a
change of state of the index-en pin, so there are 2 messages for
every threading pass.
Or, is it the convoluted if-thens that are somehow being changed
by the print statements? That doesn't seem likely, as they are
just another statement between { } braces.
I'll have to comment those lines back out and see if the
procedure fails like it did at the show.
Jon
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
