[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

[zephyr9900]

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!!!

If you are talking about the "Regenerate Toolpath" onscreen button, as Gary said, parsing the file to generate the graphics is not the same as generating actual motion from the gcode. They are currently pretty independent, and there are discussions over on the Mach forum about that subject, and the differences between the depicted and actual toolpaths, and how Mach4 might integrate them better.

For a grin, on a multi-tool gcode, put different tools from your program in the Tool box and regenerate the toolpath. In my experience, the only toolpath that shows up is for the tool currently selected.

You know, this whole discussion is really a side tangent to the task you really want to perform. I have set up the postprocessors for the CAM programs I use, to add CutViewer stock and tool comments in the gcode. I preview all my code in CutViewer. For v-tool work it is a matter of seconds to change the cutting depth and preview the results. On engraved panels etc. it is a great way to see how the engraving depth changes the stroke width on the text, and not just individual lines. And it works equally well for previewing ball-mill engraving.

EDIT:Bevin, I just did some testing with my Shuttle. I can arrow-jog either the X or Y axis, and twiddle the jog dial in Z simultaneously. I've removed all the keyboard jog controls in my screenset redesign (I was serious about not keyboard jogging any more!) so the arrow jogging is at rapid rate and I can't change that so I don't have a lot of time to play. I stop turning the Z dial before letting up on the X arrow (any other sequence would indeed be user error, because in that case the moves could be sequential in the first place) and nothing untowards happens. Both arrow jogging and dial jogging work normally afterwards.

Randy

[bevinp]

Randy,
I was off line for a few days but am back on now. Yes, I did mean to say regenerate the toolpath, not recalculate.

And just to summarise when the unexpected behaviour occurs, it happens only once and only after any of the following:
1. start up of PCNC 3, (without a program loaded).
2. loading of a program
3. selecting Regenerate toolpath.

Once it has occurred, and all motion has stopped, all subsequent simultaneous arrow key and dial jogging performs normally; ie, both the selected axes will move simultaneously exactly as per the inputs.

So the computer and Mach can handle the simultaneous manual inputs as I would expect. The problem seems related to the shuttle dial input but only after any of the three events listed above.

As I said before, I will be interested in what the authors of PCNC 3 and shuttle driver have to say.

By the way, how did you redesign new Mach screens?

Bevin

PS. Gary, thanks for the comments re compilers etc. The difficulty with forums is that the experience level of the respondents is unknown. I was trying to keep things simple and not detour into the technicalities of programming, in which I worked for ten years (including a few realtime systems). But on re-reading my post I see should have made it more simple.

In regard to Mach operating on only one block at a time, I recall reading somewhere that the control program must be aware of what Gcode is in the next block to ensure it can correctly transition between the current and the next. That seems a necessary function to me, but are you saying that is not the case?

[zephyr9900]

So the computer and Mach can handle the simultaneous manual inputs as I would expect.

Yes, you are right, Bevin. That did surprise me a little. But I'm always glad to learn new things!

As I said before, I will be interested in what the authors of PCNC 3 and shuttle driver have to say.

It looks like John's PCNC shuttle driver might be a subset of the Mach Shuttle Pro driver. You might want to try that one out as an experiment. The latest version (customized by Scott/"poppabear" of this forum) is at reply #11 of this thread. After you unzip it rename from .m3p to .dll and put that dll in the PCNC plugin folder, remove or rename the PCNCShuttle.dll that is already in that folder (I just put a .bak extension after the dll) and restart PCNC. You'll need to go to Configure Plugins to set up the driver. Select the "Express" model at the lower left and configure the five buttons via the pulldown menus. That driver won't light the "LED's" showing the active axis, but when you select an axis a message shows up in the error/message area to the right of the reset button.

By the way, how did you redesign new Mach screens?

I use Screen4 from this page. It is WYSIWYG and pretty easy to use.

DISCLAIMER: None of this is condoned by Tormach. Once you stray from a stock OEM Tormach software installation you're on your own.

Randy

[bevinp]

Hi Randy,
I received some info from Matt Doeppers from Tormach regarding the simultaneous use of arrow and shuttle dialing.

His testing showed their systems perform correctly with both axes moving as per the inputs. He did not experience the unexpected behaviour that my system displays. However, he did say that their shuttle driver was not designed to handle simulatneous inputs.

So I would say that the cause is the configuration of my PC. I use a dedicated computer running XP but it is not connected to internet and has no updates beyond the SP2. And since I now expect the unexpected behaviour I can safely work around it. Once again, thanks for your inputs.

Matt also told me they are close to releasing their new version of Mach3.

And by the way, since you "roll you own controller" or at least modify it, could you recommend a book or other source that could give me insight on design of controllers generally or Mach in particular? Not that I intend to fiddle, it is nice to understand how your equipment works.

Regards,
Bevin

[zephyr9900]

Matt also told me they are close to releasing their new version of Mach3.

Yes, I just found that out within the past couple of days myself. This past week, I installed Mach3 version 3.042.029 (the current lockdown version) and have been using it (the released PCNC version is Mach3 version 2.42). The performance improvement on contouring moves (lots and lots of small angled 3D lines) is amazing. A file that took 1:19:59 to machine with 2.42 takes 46:06 with 3.042.029--the identical file, with identical motor tuning, with identical CV numbers. The machine movement is much more fluid and less resonant--almost like having a new machine! The new PCNC release will be a major improvement for people who do 3D contouring.

And by the way, since you "roll you own controller" or at least modify it, could you recommend a book or other source that could give me insight on design of controllers generally or Mach in particular?

Oh goodness no! All I've done is to modify the GUI a little--reproportioning dialog boxes and readouts, adding a button here and removing one there. I know nothing about the inner workings of Mach. My own programming experience dates back to Microfsoft Basic on a Mac Plus, and writing VersaCAD macros. Sorry, I don't know where to point you there other than the Mach forum (and obviously the published documentation). What I know about Mach I've picked up by browsing the forum (along with a lot of searching for information on specific topics).

Randy

[kprice1658]

Yes, I just found that out within the past couple of days myself. This past week, I installed Mach3 version 3.042.029 (the current lockdown version) and have been using it (the released PCNC version is Mach3 version 2.42). The performance improvement on contouring moves (lots and lots of small angled 3D lines) is amazing. A file that took 1:19:59 to machine with 2.42 takes 46:06 with 3.042.029--the identical file, with identical motor tuning, with identical CV numbers. The machine movement is much more fluid and less resonant--almost like having a new machine! The new PCNC release will be a major improvement for people who do 3D contouring.
Randy

Randy,
Thats impressive time savings for that file. Have you seen similar results on other 3D files? Thats about all I run - and this could be major for me if that much time can be trimmed out.

Might even convince me to get the spindle upgrade for the extra RPMs.

Kevin

[zephyr9900]

Kevin, the other work that I've been doing since installing 3.042.029 has all been 2.5D. I am doing another contouring job this evening, but I don't have a baseline for that one. I haven't actually been keeping records on my jobs (they're mostly for myself), but that job I did time I had to go back and run it with 2.42 just so I could believe the difference!

I would love a 7.5-10 krpm primary spindle myself. Greg Jackson has hinted that the current spindle and bearings are good for 7 krpm with no modifications so I would be very tempted to combine a new spindle pulley with the new VFD (I have a Series I machine) and go to 7 krpm. I just had a job last week that needed from .250" down to .078" endmills, but the workpieces were too large to machine with the primary spindle plus Proxxon (not enough machine travel to accomodate the 5-inch offset between the spindles) so I was stuck with using the .078" tool in the primary spindle at 4500 rpm and 2.5 ipm in aluminum... I really want a significantly faster primary spindle!

Randy

[justgary]

Randy -

The main spindle bearings just might be good up to 7K RPM, but they definitely won't last as long as they do below that. I have run mine up to 6200 RPM, and the bearings got warmer than the normal 5140. Not hot, but just warmer. Of course, each machine will run differently, and one may run cool above 6000 while another might be very warm at the Series II max of 5140. Others have reported replacing the bearings with high-speed ones, so that is always an option I suppose.

I think I'd rather have a bigger table with more travel first, then a faster spindle... but I understand that I would have to pay for what I get. With a bigger table you would still have room to use the Proxxon...

I'm also very curious about the performance of Mach 3.042.029. Speeding up contouring will help a lot.

Regards,

- Just Gary

P.S. And at the risk of a hijack, I'll answer MichaelHenry from several days ago: When I am milling very small details, SprutCAM will create a command for an arc, but will put zero for the radius. Mach will load the program and display it just fine, but will stop on that block and croak when I run it. The fix (for me) is to edit the program and replace all occurrences of zero radius with a small number (like 0.0001). The saddest part is that I usually find out after the part runs for a while, so I usually start from that line after I fix the problem. It's always a nail biter to restart like that, especially with very small tooling.