I have PCNC 770 #70101, and I'm enjoying the heck out of it, except for an intermittent problem with jogdial response. I'm hoping that somebody else may have seen this, and found a fix or workaround.( Please, let "many eyes make all bugs shallow" be true in this case. Yeah, I know, Mach3 is not open source, but still....)
DISCLAIMER: I've worked for many years in software development (including device drivers), systems integration, customer support, so I have complete sympathy for whoever at Tormach or Mach is in charge of dealing with these issues. I've been in that barrel meself. (More on this below.)
The specific problem is that the jogdial inner WHEEL stops responding occasionally, and nothing I can do (short of system restart) will get it back to normal. The jogdial RING can also lock up, but pressing the <esc> key will clear that problem. The jogdial is such an awesome tool, I'll go nuts if I can't at least find a workaround.
GORY DETAILS
=======
a) I am running the Tormach control computer, as installed with "PCNC770M3 R1.1 SRev3.4d" . I have not added ANY software to this system system. (And I probably won't until I get this issue resolved.)
b) All axes are Referenced
c) I will USUALLY see a message "Nothing to Feedhold" when the system gets into this error state.
d) At this point, jogging from the keyboard and jogdial wheel stops responding. Pressing the X, Y, Z, or Step buttons on the jogdial IS recognized. (The corresponding LEDs on the display will become illuminated.)
e) If I then press <Esc> on the keyboard, I can jog all axes from keyboard or jogdial ring. However, if I move the jogdial at all, the jogdial ring and keyboard jogging again become unresponsive. I can repeat this cycle forever.
I have heard from reading the EMC2 forums that USB traffic can cause timing problems, and the recommendation over there is to disable USB and use PS/2 keyboard and mouse instead. I suspect that Windows Embedded may deal with things differently. (Polling as opposed to interrupts,perhaps?) I know that guessing about these kinds of problems from OUTSIDE the system is a futile activity: the best results are often found by instrumenting the system so that it can tell you what is REALLY going on. (And the answer is usually something you'd NEVER guess at successfully.) Nevertheless, if I were a gambling man, I would bet that there's something in the Kernel that is
responsible for capturing the state of the various USB devices, and that somehow this mechanism gets into a state (finite state automata?) where it ceases to check on all possibilities at the jogdial.
Regardless whether my guess is right or wrong, I think it would be very beneficial to add a field on the Diagnostics screen, showing the last value /character /stimulus brought in through USB. I'd also show any flags (such as "MDI in progress" ) that are in a position to lock out software jogging. In a PERFECT world I'd add a button on the
Diagnostics screen that would allow me to reset the USB input status to a known (beginning) state.
Sorry for the length of this. If there is any other information I can capture, please let me know.
Best regards,
- Marty Swartz