Topics

31

General Mach Discussion / Possible bug with jogging

« on: October 17, 2011, 05:27:07 AM »

I was setting up cutters on the mill and got hit with this bug TWICE in two days.
CPU: fairly new Dell Vostro box, good keyboard, SW load stripped down.
Mach - latest version, running into Smooth Stepper, fairly recent driver (2.08.02)

Load cutter, bring to near registration point
PageUp to bring tip to registration point (slip 0.25 mm feeler guage between cutter and face)
Nearly there, so tap CTRL/PageUp a couple of times  for the last tiny bit.
OOPS!
I am not touching the keyboard (and the keys are not sticking), but the Z axis is jogging up slowly all by itself! 
Tap the opposite key (PageDown) and it stopped.

Has anyone else met this?

Cheers

32

General Mach Discussion / What NOT to do with an XML file

« on: October 14, 2011, 05:18:19 AM »

So the vendor sent me an updated XML file for my lathe. OK, very nice.
So I tried using it ...
That has got to be one of my more stupid mistakes!

Fortunately, nothing broke, but equally, nothing worked. All my motor tuning, all my settings (including radial/diameter mode), ... I think even my choice between imperial and metric had changed.

I knew there was a good reason for the XMLBackup folder :-)
No real problems apart from a few hours wasted, just thought I would mention it.

Cheers

33

General Mach Discussion / g15/g16 problem

« on: May 02, 2011, 06:04:41 AM »

As some of you may know, i have been having a problem with the interaction between polar coordinates and the g83 drill with peck operation. At that stage I thought eh problem was in the g83 code.
I now think the problem actually lies in the g15/g16 code - and possibly with its interaction with subroutine calls. To explain:

I have a production system making a grid of units all together, in one batch. It saves hugely on tool changes.
One of the steps is to drill a ring of holes on each unit. I have been doing this using polar coordinates for the actual drilling. There were problems with the g83 instruction, which I resolved.

However, I have since found a much harder problem. I was testing out a new version of the program and hit Feed Hold and then Stop while the machine was drilling the holes. This left Mach3 in the polar coordinate state.
So I manually issued a g15 command to put it back in the cartesian coordinate system. It stayed in polar coords.
I unloaded the program and restarted it, with a g15 instruction at the start. It stayed in polar coordinates.
I killed and restarted Mach3 and all was well.
However, several development cycles later ... I was still having the same problem. It seems that once Mach3 gets into the polar coordinate state and is interrupted, it does not want to get out of the polar state.

I THINK that if I issue a g16 command and then a g15 command it does sort itself out. That is, I have to tell mach3 to go into polar cords even though at least part of it already is, then tell it to revert to cartesian.

Has anyone else had this problem?

Cheers

34

General Mach Discussion / g16 / g83 interaction ??bug??

« on: April 25, 2011, 09:07:25 PM »

Hi all

I am machining a lot of objects in a grid, so the code is quite parametric.
Each object has a ring of N holes around the middle.
So I have parametric code to go to the centre of each object, then a subroutine to run a ring around to drill the holes. For the holes I want to use g16.

If I code thus it fails with really wonderfully weird results. I have deleted non-critical parts of the program of course.

#3=[360/#36]   % define the angle step
#4=0         % zero the angle register
g0 x#1 y#2      % go to centre of this object
g16                 % GO INTO POLAR COORDS
g0 x#28 y#4      % GO TO 1ST HOLE POSITION AT RADIUS #28, ANGLE #4
m98 p192 L#36   % DRILL THE RING OF HOLES
g15                          % kill the polar angle bit
m99

% this routine drills one hole at a polar position
o192
g0 x#28 y#4                       % GO TO THE POLAR POSITION
g0 z1                                    % prepare to drill
g83  z[0-#29] q3 r1             % DRILL THE HOLE
#4=[#4+#3]                       % next angle
m99

The first hole is drilled correctly. Motion to the next position by g0 X#28 y#4 is also correct. But the g83 command moves to a different XY position even though no XY values are given for it. The manual implies that omitting XY values should use the current position, but clearly the Mach3 code for g83 is using a different XY position from what the g0 command created. Subsequent holes are all over the place.

But if I change the g83 command to explicitly include the polar XY values thus, it works smoothly every time
g83 x#28 y#4 z[0-#29] q3 r1 

It seems that the g83 command is not able to handle the polar mode when it is in a subroutine. The examples in the manual do not use subroutines.

Has anyone else had this problem?

Cheers
Roger

35

General Mach Discussion / Tool offsets and long delays vs Work offsets - help

« on: February 14, 2011, 05:39:06 PM »

I am using a lathe with a custom multi-head tool holder.
Mach has a nice system which lets me position each tool to the job, hit Touch X/Z, and set up the tool table. This works well.

However, when changing tools (T202 etc) in the program, I have to M3 after each tool change, So there is a very long delay while the chuck stops, and then spins up again.  So, questions:

Is there any way to tell the system to just change the tool table entry used and NOTHING else? ie, no long delays. (Yes, I know I have to clear the job first!)

Or, is there any way to set up work offsets automatically, tool table style? I could juts as easily flip work offsets for this job.

Thanks

36

Mach Screens / Radius/Diameter mode - how to display

« on: February 08, 2011, 06:18:51 PM »

Hi

In 1024.lset there is a label for radius/diameter mode. It works, changing the display according to what mode the system is in. But I am blowed if I can see how it is done!
It's a label, not a LED, and there does not seem to be any OEM signal attached to it. Well, it works in 1024.lset.

But I would like to be able to have a similar display in a custom screen. I can create a green LED and turn it on when the system is in diameter mode (code 92), but I can't find an OEM code for Radius mode.
I can create a red/green LED which changes colour for the two states, but that really does not do what I want (and is just confusing anyhow).

Is there an OEM code for radius mode?
If not, can I somehow negate an OEM code, so one LED responds to (code 92) and the other LED resonds to .not.(code 92)?
Or can someone tell me how to flip the label as is done in 1024.lset?

Cheers
EDIT:
It's one of the 'undocumented irregularities' of Mach3. By putting 'RADDIA' in the text box Mach knows that it has to alter the text when the mode changes.
Hum ... I understand the how, but I am not sure this is 'good practice' for screen design.

37

Feature Requests / Subroutine library ability?

« on: August 22, 2010, 11:58:34 PM »

I am machining a number of different bits. I control the dimensions by having a 'data file' external to the main g-code file: it contains just parameter setting statements and is called as an external subroutine. To alter a part I just edit the dimanions in the data file.

I also use several canned routines for many vaguely similar parts. It seems (I may be wrong) that these canned routines must be included at the end of the main g-code file. I would love to be able to put them in a separate library file instead, and invoke that at the start of the main g-code file. However, it seems that when Mach3 reads in a subroutine file during the load process, it does not register any subroutine labels in that file for use from the main code file. On the other hand, it obviously does register all the subroutine labels when it reads in the main code file.

It would be very nice if Mach4 could register multiple labels from within a subroutine file (common library routines) and be able to call them. All it would take is a slight change to the loader. Would this be possible?

Cheers

38

Feature Requests / Logical operators and IF statement

« on: August 06, 2010, 07:00:44 AM »

I know there are some ways to implement a NOT operator and an EQ (or NEQ) operator, but they are messy.
Could we please have explicit NOT(x), a.EQ.b, a.NEQ.b operators? They would be very easy to do.
While I am at it ... in addition to .EQ., how about .GT. and .GE. (etc)?

And PLEASE, could we have an explicit IF THEN ELSE statement? Yes, the effect can be done with macros, but that is obscure and clumsy. Clarity in code is very desirable.

Adding the Conditional could transform the way we write g-code for industrial use. Please?

Cheers

39

General Mach Discussion / M98 Subroutine Directory

« on: August 01, 2010, 07:38:46 AM »

After some hours of frustration, and then another hour of searching here, it appears that any named subroutine I call must be in the Mach3/SubRoutine directory.
This is slightly anomalous as I can load a main routine from anywhere, but I cannot do that with subroutines. That is, the following does not work for me:

M98 (c:\mach3\gcode\sub.tap)

Would it be possible to have the next release allow the full filename string please? That way I can keep projects separate.
If there is another way to handle this, or if I am just wrong, please advise!

Cheers

40

Mach Screens / Combined mill and boring machine - ??

« on: July 13, 2010, 03:29:36 AM »

I have an (Australian) Adept CIM system. This has an overhead mill with an XY table below it, and also a lathe head at the side. The XY table is used as the lathe tool holder for turning. Normally you would not try to run both spindles at once, and as far as I can tell Mach3Mill won't allow this either.

However, I want to put a workpiece on the table, mill parts of it, then use the lathe as a drill holder to bore out a long hole down the middle of the piece - as a boring machine. Doing it this way means I do NOT have the alignment problems you would expect if the workpiece was removed and replaced rotated 90 degrees so as to use the mill head for the boring. Yes, it does mean that the workpiece has to be placed at the right height above the table at the start, but that I can do (and being out in height by 0.2 mm doesn't matter anyhow).

Has anyone managed to do this?
Will it require a custom screen?
Should I treat the lathe spindle as another mill head instead? If so, how?

Any advice or hints (or help)?
(I have many years experience using a lathe and a mill, but CNC is new to me.)

Cheers