I am still new to milling and PathPilot. Today I was trying to use conversational programming to create a circular boss (nothing complicated). However, I noticed that when I tried to enter a decimal place, it was instead changing the A-axis for the microARC 4. I tried to enter “0.9 in”, and could only enter “9.0 in” because of the binding being grabbed by the actual hardware jogging. The same is true if I tried to move the cursor in an entry for data, e.g., moving the cursor left or right while editing the “9.0000” to become “0.9000” fails because the left and right arrow keys were jogging instead of moving the cursor in the text entry widget. Text editing has no method of entering certain keystrokes it seems. What am I missing?
I tried to exit that tab and go to a new tab and then back to conversational, but the same problem was still occurring. The only reason I was able to enter “0.9000” is because the “/” for division worked, and I could enter “9/10” which converted to “0.9”.
Is this an issue with yesterday’s update to v2.12.3? I don’t remember having issues entering a decimal place or moving the cursor before.
I’m going to say number lock, but I could be wrong. Hopefully because moving the machine while using the number pad is danger! If your keyboard uses the number pad as arrows you should get a keyboard that has separate keys immediately as jogging into the table is almost certain.
That’s definitely not expected behavior. I rarely use conversational and haven’t upgraded to 2.12.3 yet so I can’t speak to any possible issues but rolling back to an earlier version is a simple enough process. Might be worth a try to see if the problem goes away. If it does, definitely submit a support ticket.
PP 2.12 was a pretty major update and introduced a lot of bugs, unfortunately. So far Tormach has been very responsive in getting them resolved so if this is another software issue, I suspect a .4 version will be released quickly to resolve it.
There is no number pad on the waterproof keyboard for this model: waterproof keyboard
(and I was trying to enter a decimal place or move around in a text entry field to enter a floating point number)
I’m not positive, but I think maybe it is related to trying to get the hover over mouse help to go away with the ESC key. However, if (and that is very iffy™) that is the case, then no future mouse action, nor keyboard action, can fix it without reboot.
If I figure it out I will save a video and bug report. For now I think I need to disable mouse hover over help (one can still get it to show up, I think with a control key or something…not sure) because I think it was related to this. And it broke text editing and decimal places in all text entry widgets.
For the technically curious who program: When the cursor is in those widgets, there is a “finite state machine” which should prevent the “period” and “arrow” key change events from falling through to the movement of the machine (including A-axis). Instead it was the text entry widget which was excluded from arrow and and period keys (inverted).
Dan,
I’m curious about this one. When you posted this the other day I spent a bit of time trying to reproduce it to no avail. The tool tips (hover over help) is an interesting point. I’ll experiment some more but it would be worth reaching out to our support staff if you see this again.
I have worked with a few ‘waterproof keyboards’ and they tend to fail either with keys shorted internally or going open circuit, so maybe borrow a different KB temporarily and see if the error follows if you haven’t tried that.