Messages

81

General Mach Discussion / Re: Yet another limit switch problem.

« on: April 08, 2009, 07:00:16 AM »

While Hood has a look at you XML (which I don't understand) - I take it all you switches are wired in series (not parrallel).

What you need to do is turn to the diagnostics page  and check the LEDS are working properly (i.e. the signals are getting into the computer from your switches.

Each input is marked. If you have your switches all wired in series, then all will come on at once, so it doesn't really matter, but without jogging, or anything else, open and close the switches by hand. Each one should respond by lighting all three limit leds.

If you are not getting the leds to light, then your switches are not being "spotted". Check there is no other input assigned to Port1 Pin 11, or try one of the other inputs - pins 10,12 13 or 15. When you have assigned the pins - have you activated them?

If they all come on when "not" switched, changes the "active low" column on them all

82

General Mach Discussion / Re: Which first - part or program?

« on: April 08, 2009, 04:24:07 AM »

Bill - I'll put my pennyworth in here - I don't know how relevant it is (or, to be fair, how much you already know of it, so forgive me if I repeat a lot you already know), but it might jog you memory.

The machine keeps it's position in Machine Co-ordinates. The only way this cam be altered is by homing you axis, which I think Graham  and others have mentioned.To this the machine adds (or subtracts) various offsets for programs, tools etc.but the display is always in the "raw" machine position.

This is no good for machining, and difficult for us to understand, because it contains data we do not need to know, therefore you then jog your machine to the position where you wish to start your program (usually the 0.0.0 position of the program) and then you zero the X Y and Z of the axis in Program Co-ordinates

The two sets of DRO's are the same DRO's, they just change function as you press the machine co-ords button. If you are saying you cannot zero your DRO's. you are probably looking at the Machine Co-ords (which you cannot zero except as in para 2) and not the program co-ords, (which you can). I have altered the display on my machine. The main display shows Program Co-ordinates, and underneath, I have put a small second set of DRO.s which display Machine Co-ordinates, so I do not need to swap between the two.

Once you have zeroed the program co-ords, the "offset" between the machine position and the program position is recorded. The default offset is G54
, and if you check the fixtures list (Config/fixtures), you will find that G54 now shows the difference between the program co-ords and the machine co-ords. If you are to use this offset in a program, then you should select a different  offset, before you zero the program co-ords DRO's - e.g. G56. If you then enter this in your program at the begining, the machine will always to to the correct start point for that program.

E.G. G56
G0 X0 Y0 Z0

The way to start is then "home the machine" which sets the machine co-ords at their zero position, and then run the program. The G56 runs in the correct offset and the G0 move moves the axis to the correct 0.0.0 position for that program.

(The co-ordinates shown in your program are always "Program Co-ordinates" unles they are particularly specified to be absolute co-ordinates, for example, tool change positions for automatic tool changers)

In this way, each program can have it's correct offset programmed in (there are 256 to choose from). If for instance, you use some form of workpiece holder, then one offset might suffice for several different programs.

Running the program without homing will not make any difference (providing the home position has not slipped) since the last offset the machine enters is the one it follows.











 

83

General Mach Discussion / Re: G31 what is it for

« on: March 27, 2009, 04:17:15 AM »

As implemented in Mach 3, G31 is the command for use with - well anything, since, although it is " a straight probe" you can with a little bit of thought use it for all sorts of position finding.

The basic command line is "G31 X1". With that the X axis will move towards position 1 at a low speed. If a pin designated as "straight probe" (on Config/Ports and Pins) is earthed in the time the axis is moving, it will immediatly stop. The command can be applied to any axis with the same result.

On my machine I have a two pin din socket on my control box - providing an earth lead and a connection to the "probe" pin. I have a lead with a two pin din plug at one end. The other end, the earth wire is fastened to a dog clip and the "pin" wire is soldered to a piece of copper clad board.

If I want to use G31, then I plug in the lead. and clip the dog clip - usually onto the tool or drill - the copper clad is then placed as a target. The thickness of the copper clad is known, so when the axis stops I know it's position and can adjust the DRO's accordingly. In actual fact, my machine is earthed in any case, and I can do away with the earth clip.

If your question is should you have it or not, I would suggest it is one of the most useful and "quick" methods of position finding for any machine.

84

General Mach Discussion / Re: End VB ! (script that is)

« on: March 21, 2009, 06:05:33 AM »

Henry - All the DRO's and LEDs used on Mach 3 have an associated OEM number - and Hood provided a list of these at the top of the main page. It is very useful, and you need to copy it.

The way I approached the problem was - when you press the E Stop what happens - the reset LED starts flashing.
The code for the reset LED is 800, so if you look at that you can tell whether the machine is stopped awaiting reset or not.

The line "Stillgoing = Not GetOEMLed(800)" means look at the reset led, and if it is NOT on, then we are stillgoing (stillgoing (a variable) becomes true), if it is on, then stillgoing becomes false. This is the key to the whole program, the rest is just counting and displaying on the screen, so I can see if it is running or not.

"While stillgoing" and its associated "Wend" encompass the whole program, and as we found, stillgoing is checked on a regular basis, and if it becomes false, the program drops to the bottom of the page, and shows the legend "Reset pressed" so we know the VB script has stopped.

Code generates GCode for Mach 3, as you probably know, but inside the code asterisks, anything in () is printed on the display line of Mach 3. I use this on a fairly regular basis to let me know where the VB script is, becasue (if it is a long, or repetative script) I like to know how far through the program is.

85

General Mach Discussion / Re: strange problem

« on: March 21, 2009, 05:46:24 AM »

This really is a continuation of Hoods comment -

Are you making allowance for the diameter of the cutting tool instead of the radius. If your dimensions are the same on Mach 3 e.g. the pockets are 1 inch square, and the inlays are one inch square, then to get the pockets consistantly short, and the inlays consistantly large, it would seem that the code is making allowance for the diameter of the tool and not the radius.

Hence it makes too much allowance.

86

General Mach Discussion / Re: units per min vs units per rev

« on: March 21, 2009, 05:39:47 AM »

Am I missing something here, or is my maths all wrong.

If you want your tool to advance by 0.0002 (I assume this is the tooth dimension) on a two flute cutter, then at 6000 rpm the feed should be 2.4 units per minute - whether inches or mm does not matter - or am I way out.

In answer to the post, yes, it is possible to change the feed from units per min to units per rev, but this will involve you changing the GCode.
This might not be as difficult as it sounds, with the search and replace facility, but depending on who wrote the wizards, whether he (or she) would be willing to sit down and add it in would be up to them.

I think, however, if you work out accurately what movement you need, if you are fairly accurate with your spindle speed, and it does not vary overmuch (as in Constant Surface Speed work), then using this as a units per minute feed should not make any difference.

87

General Mach Discussion / Re: End VB ! (script that is)

« on: March 20, 2009, 05:10:20 PM »

I have just knocked up this script to prove the theory.

The program counts in the message window, and as soon as the EStop is pressed it stops the VB.

I cycled it in 10's to see if it would count to the nearest 10, but VB seems to check the condition after each line.

I couldn't see the message on my Mill xml - I used my lathe xml

I used three lines of GCode to run it - G21 - M1100 - M30

88

General Mach Discussion / Re: End VB ! (script that is)

« on: March 20, 2009, 04:24:50 PM »

Yes!

The way I understand VB to work  (and I may be wrong if some of the lads tell us differently) VB is not part of Mach 3, in that it operates a little independently of the standard GCode program. It sort of stands apart, and feeds in lines of GCode into the system, until it's program is finished, and then hands you back to the standard GCode program reader.

Hence, for instance, you can have a bit of trouble on certain moves, and you have to include a "while IsMoving" line, to make the VB wait until the last line it sent to the machine has executed, and then it sends the next line.

It may be that the whole of your VB script can be included in a "while not EStop" condition so that the program will stop, if EStop trips. This would automatically drop the program through to the end of the script, and return you to the GCode program.The only problem with that is, I don't know whether VB checks the condition after each line of it's own program, or finishes the chunk of program before checking the condition again.

I am only thinking aloud here - and may be way off the mark. I will try and write something e.g. a counting program, and see if I can get that to stop when EStop is pushed.

Keep on with Scripts - they are very useful and a great assett to the Mach 3 capability. The majority of my maching uses scripts, particulary the lathe, where a lot of time is spent on repetative thinning down of shafts, wheels, etc. i.e. the same cut, just repeated many times.

89

General Mach Discussion / Re: Problem with repeatability????

« on: March 20, 2009, 04:01:04 PM »

As Hood was asking - we need far more information to advise you what your problem might be.

1. Is your machine properly set up. are your steps per unit correct. is your motor tuning in respect of speed and acceleration at a speed where it performs reliably, and finally as Hood said - have you any backlash on your system, have you measured it, and is backlash compensation on.

2. What GCode are you trying to run. Is it a small program, or is it just an MDI line of commands.

3. To achieve repeatability, you must ensure that your machine is "homed", all offsets are reset, and your 0.0.0 position is the same each time you start. 

90

General Mach Discussion / Re: New Bee - Help! Drawing spiral - getting oval instead of circle!

« on: March 19, 2009, 01:08:10 PM »

Dan - when you say a spiral, do you mean a circle - i.e. a G2 (or G3) command on the MDI window. As Chip says. this is possibly backlash.

You do not say, however, what you machine is, or how the axis are controlled. Is this a milling machine, or a router, are the axis controlled by a threaded rod, or a toothed belt, or what.

You must first set up the steps per unit correctly, which you probably have done. Your motors should then be tuned to give you the best speed for reliability performance, and then your machine should be checked for backlash.

Once you have done that, you can draw a circle - the big problem with a circle is that the direction of each axis changes at least once, and more than likely twice, and it is when your machine changes direction that problems occur.