Possible jogging bug or misuse?

[bevinp]

The following is a copy of my email to Tormach who replied they had not seen this before and could not reproduce it. I am posting this here and on the Tormach forum for any comments.

******
I experienced a fault while manually stepping both X and Z axes simultaneously but don’t know if it is a bug in the controller or if I was doing the wrong thing. The fault occurred a few times but with slightly different behaviour.

The first time was after I had held down the keyboard arrow key to slowly move the X axis in positive direction while stepping the Z axis lower using the shuttle jog. After I released the keys, all motion stopped but when I subsequently attempted to slow jog the Z axis, it would move only in the up direction whether I used the shuttle or the keyboard. Manual movement of the other axes was normal. I Reset the machine but Z axis still would only move up when slow jogging (I did not try fast jogging). I powered off the machine and computer and restarted. Individual manual movement of all three axes was normal. I ran a short program without an error.

I again tried to induce the error by repeating the keystroking and this time I noted the sequence of first releasing the X arrow key and then the shuttle inner ring. After release, the X axis kept moving in the same direction. I was able to stop the movement by holding down the X arrow for about 5 secs then releasing it. The X axis stopped but the Z axis then stepped down about 0.5mm and stopped. I repeated the same keystroking but the subsequent behaviour was normal. I tried a few more times varying the key release sequence but all behaviour was normal.

I once again powered off and on but could not induce the problem. I have since machined parts without a problem

This was the first time I have held an arrow key down while shuttling. Is this misuse or a bug?
*********

Bevin

[zephyr9900]

Is this misuse or a bug?

Probably so, Bevin.

On occasion, when jogging Z downwards with the Tormach shuttle ring (no arrow keys involved) the Z axis will reverse direction when I release the ring. Speed of jogging doesn't matter, and I can twiddle the ring back and forth without effect (which also confirms that it isn't a sticking ring). Only hitting the [esc] key stops the motion. Fortunately the unintended Z motion is upwards. Subsequent jogging is normal, ring and dial both.

Edit:Since I bought the Tormach shuttle I don't use the keyboard at all for jogging. The shuttle is too convenient.

Randy

[RTP_Burnsville]

Bevin,

No shuttle here, but I had the system lock a couple of times while jogging with the keyboard. As you note, I was never able to repeat the issue after resetting and starting again. It is certainly a bug, but one that may be very difficult to find. Issues that can't be repeated are the hardest to find and fix. Thanks for posting as I had forgotten about the issue.

Robert

[bevinp]

Thanks Robert and Randy,
I spent about two hours today experimenting and can now repeat the fault. I have emailed the following details to Tormach for their comment.

With a G code program loaded, the following steps will cause the “unexpected” axes movement:
1. Select one of the axes on the shuttle, and to make description easier here, I will use the Z axis.
2. Regenerate Toolpath.
3. Select and hold one of the keyboard keys to move one of the other axes, say X, in either positive or negative direction. The X axis will move correctly and DRO will display correctly.
4. While still holding the keyboard key down, rotate the inner dial of the shuttle in either positive or negative direction in an attempt to move the Z axis. There will be no stepper operation or movement of the X axis, or change of the DRO.
5. Release the keyboard key and stop rotating the inner shuttle dial. The X axis will immediately reverse direction to return to the position from which it started when the keyboard was pressed and the DRO will display correctly. During the return to the starting position, the Z axis will make one or two steps to follow the previous movement of the shuttle dial. Once the X axis returns to the starting position, then the Z axis will seem to follow the remaining steps commanded by the shuttle and the DRO will display that movement.
6. Once all movement has stopped, axes movements are all normal and the fault cannot be repeated unless the Regenerate toolpath is performed again.
7. The listing of the program will usually jump from the beginning to the end line as soon as the shuttle dial is rotated, but not always.

I tried most of the combinations of axes (but not all) and found that the behaviour was the same. Even if the same axis is held down and is selected on the shuttle, the same sequence will occur; ie, once the axis returns to its starting position, then the same axis will follow the prior shuttle dial movements, be they in the same or opposite direction, or a combination of positive and negative rotations.

If the outer ring of the shuttle is used instead of the inner dial, all motion is normal.

While I wait for their response, I am checking the code in the two programs I used to investigate the problem. I may have an unclosed modal instruction that is leaving M3 in a funny state.

Your comments appreciated.
Bevin

[zephyr9900]

Bevin, I guess the fundamental question is what kind of event trapping Mach3 has for user input. In all user interfaces I know of (word processor, CAD, etc.) the only keys used concurrently with a mouse or tablet are modifiers--shift, ctrl, alt--that are held down during a mouse click or drag.

Keyboard controllers, I know, have (or at least used to have) internal electronics to detect inappropriate key presses, such as overlapping two non-modifier keys, where it would only send the last-held keypress to the PC.

If Mach is not designed to handle simultaneous disparate user inputs, I'd say that your use is a misuse. If it is supposed to handle them, then it's a bug.

I tend to be very conservative in how I deal with Mach. There is a half-ton piece of machinery standing in front of me that I don't want to let get out of control.

If I want to do a large positioning move in simultaneous axes, I'll use the MDI line to do a G0 to the approximate position (within a couple of inches, being safe especially in Z) and then use the pendant to do the final positioning.

But I'm rarely in that much of a hurry. Compared to the time spent CAD'ing, programming, preparing and fixturing the part or rawstock, a few seconds here or there positioning the first tool is pretty miniscule. I have the center dial fixed at 0.0001" increment (whole table filled with 0.0001") to avoid accidentally doing a large incremental jog when I'm near the workpiece. I "ring" to within a few thousandths of the final position, then "dial" in the final position.

Randy

[bevinp]

Randy,
I agree with you that the time saved is minimal and not worth the risk of multi-finger mistakes; one finger has enough risk.

But I would not call simultaneously pressing two axis keys "disparate user inputs" in a CNC machine. After all, don't the three axes operate as three separate channels as far as the machine and the controller are concerned? And as I found in my testing, moving the shuttle outer ring while depressing another axis key works as you would expect... totally independent.

When the unexpected behaviour occurred, I was setting up for engraving text. I had a Dremel mounted on the Tormach spindle arm and using a very fine bit. I was attempting to determine the Z setting for the width of groove I wanted. So I touched off with paper, switched on the Dremel, moved the X axis with the keyboard, while slowly dialing the bit down. That's when I had the uncommanded movement.

Anyway, Tormach have all the details of my testing now and perhaps their investigation may find the cause of those uncommandd moves using the shuttle that other people have had in the past.

Thanks for your comments.
Bevin

[zephyr9900]

After all, don't the three axes operate as three separate channels as far as the machine and the controller are concerned?

No, Bevin. Electronics, yes, controller not necessarily. There is no reason to expect to be able to jog two axes at once. On commercial machines, you choose an axis and use the jog dial (MPG) to jog that axis. I just talked to one of the machinists in the prototype shop at my last employer, and in 20+ years he has not seen a commercial control that allowed two-axis jogging (except by typing in single lines of gcode), even their recent Haas mill. His specific comment was "that would be scary".

I think you may be expecting too much of Mach. Gcode is itself an interpreted language, and inherently doesn't allow "overlapping" motions. That is another reason why I suspect that Mach may not be set up for jogging as you describe trying. Mach is overall a gcode interpreter, so I think that the "manual" capabilities will mirror what can be done through the gcode itself.

You may get more comprehensive answers by asking on the Mach forum. After all, Tormach is using a standard (older) copy of Mach3 (R2.42) that John Prentice has set up for the hardware.

Edit:OK, I'll provide my own counterargument. Look at this thread on the Mach forum. It is possible to jog more than one axis simultaneously with at least specific hardware (analog joystick running through an auxiliary card). Whether that can be extended to the keyboard and shuttle (both digital devices) you really need to ask over there.

Randy

[mactec54]

Hi bevenp

It seem what you have explained everything is working correct, I no some people have & can move 2 axes at once, but in reality you should only use 1 axes at a time if you have a supper computer set up, then I'm sure you can do it, but I would say your computer is not up to the task of moving 2 axes at the same time & will lock up if you try to do more, I think your system will be just fine if you just use one operation at a time

[bevinp]

Gcode is itself an interpreted language, and inherently doesn't allow "overlapping" motions. That is another reason why I suspect that Mach may not be set up for jogging as you describe trying. Mach is overall a gcode interpreter, so I think that the "manual" capabilities will mirror what can be done through the gcode itself.

Randy,
Yes Gcode like all computer languages is interpreted, in the general meaning of the word “interpreted”. But in computer jargon, as I suspect you know, an interpreted language (such as BASIC) has each line of code converted to CPU code and fed immediately to the CPU. And as you say, consequently it doesn't allow "overlapping" since each line is read sequentially. In comparison, most computer languages (eg C++ or Pascal) are translated into executable code by a compiler and usually saved as a separate file (eg Word.exe) for later running. I suspect that you are aware of all this and of my description being rather simplistic.

But my point is that Mach actually performs the function of a compiler in that it reads all the Gcode file before it will respond to a Cycle Start selection. This enables Mach to correctly allow for deceleration/acceleration or change of direction or combined movement etc, that may follow the current instruction. Hence it doesn’t simply perform each block of instruction in sequence. Similarly, Mach reads the full line of MDI input as if it is a program before it performs those instructions.

Where the keyboard/shuttle inputs differ from MDI and Gcode program inputs is that the operating system (Windows in this case) is the source of the input to Mach. Clearly, Mach keeps checking if a key is pressed because of the importance of some of the keyboard inputs (eg AltS), and probably the frequency of checking would be the same as the high frequency of setting the signal on each of the 16 or so wires of the cable to the mill, at least 10KHz. And since the mill responds correctly when I press and hold two arrow keys then clearly, the keyboard input is equal to an MDI input or a program.

What I think the cause of the behaviour that occurs when pressing an arrow key and dialing the shuttle, is that the shuttle dialing inputs to the computer are not being immediately read by Mach and thus being queued by the operating system. When the arrow key is released the queued shuttle inputs are then followed.

What confuses me is that before the queued shuttle inputs are followed, the mill returns to the position it was at the time when I selected recalculating the toolpath!!!

It seems to me to be an issue with the shuttle driver. But I will leave it to the experts.
Regards,
Bevin

[zephyr9900]

What you say is very reasonable, Bevin. But the fundamental question that still requires an answer, is whether Mach is written to proceess your desired type of user input in the first place. Until that is answered, all other questions are moot.

[justgary]

Hmmmmm. The jog dial, mouse, keyboard, etc. are all "Human Input Devices" to Winders. I don't own the jog dial, so I can't perform this test, but I suspect that the jog dial shows up as a keyboard. Someone already mentioned opening a text editor and playing with the jog dial to see what it "says."

Pressing keys at the same time on a keyboard will not always do what you think it should. A few of the keys are made to double (or triple) with other keys, but most are not. For example, open a text editor and press four keys in a diamond pattern on your keyboard (awsz, sedx, etc.) at the same time. On my keyboard, sedx through jikm show up as the four keys in sequence, but awsz and kol, through ;['/ miss at least one character. What happens when you press keyboard keys and jog at the same time (essentially using two keyboards at once)? Only Bill (the guy inside your Winders box) knows.

Combine all of this with the fact that Mach3 hijacks Winders so that it can perform in "real time," and who knows what great features got added...

This thread reminds me of the old saw about the doctor and his patient:

Patient: "Doctor, it hurts when I do this."
Doctor: "Then don't do that."

Regards,

- Just Gary

P.S. Bevinp, don't confuse a compiler with an interpreter. You are using the word "interpreted" where you mean "parsed." All languages use a parser to determine what the line or lines of source code mean. An interpreter attempts to run the line after parsing it.

Mach is an interpreter, and although it prescans your whole file when you load it, it is mostly just drawing a picture of the motion and looking for blatant syntax errors to save you from yourself . I have had Mach stop in the middle of a running program and declare an error many times (it is always a zero radius on an arc, thanks to SprutCAM). The initial scan does not catch it, but the program stops when Mach reads that line and declares the syntax error.

[MichaelHenry]

I have had Mach stop in the middle of a running program and declare an error many times (it is always a zero radius on an arc, thanks to SprutCAM).

Hi Gary,

What causes that error?

Mike