Messages

91

General Mach Discussion / Re: Motor Tuning Issue

« on: March 19, 2009, 02:47:24 AM »

Now you have got this far -

The steps per unit is a fixed number - it is nothing to do with tuning. It is the number of "pulses" the computer has to put out to move the axis by one unit - eg mm or inch. This is usually quite a large figure - eg.
In inches - my motor require 200 steps per rev, my drives also do 10 micro steps per step - so that is 2000. I have step down gearing to run my leadscrew - 3 to 1 - that is 6000 and my leadscrew requires 10 turns per inch. = 60,000. So my steps per unit is 60,000. That is a fixed number of pulses and is not negotiable, otherwise you machine will not be accurate. You must do your own calculation for your machine.

Modern motors seem to be 200 steps per rev, drives give 4,8,10 or sometimes 16 microsteps and this you can set. Gearing - if you have a direct drive ignore it. The only thing is the leadscrew - and this should be clearly set out in the lathe/mill  documentation.Beware someone saying you have inch screws, when infact they are metric - i.e. 25mm.

Once yu have the steps per accurately set, you can start tuning. Set the speed of the axis about 10 per minute,acceleration at 1 and jog. If it takes that, increase the speed in chunks of 5 until the steppers clearly baulk and miss steps. Back off the speed until you get reliable movement again.

Repeat this with the acceleration and you are set.



 

92

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

« on: March 19, 2009, 02:26:17 AM »

Henry

I use VB quite a bit, but usually only in Macros, in that I write the VB script ( eg thinning down a rod in the lathe, taking finish dianeters and lengths from a DRO's page that I have included) but to get round your first point, I then include then macro in a GCode script.

This might be very simple e.g. G21  M2001 and means when I restart, the GCode picks up the VB script again.

The trouble with VB is that when you start it, the program runs, right through, so if you stop, and then restart, unless you have something to pick up the VB script again, it won't start.

The second point is fairly easy, and would be a matter of altering the button script, to include a call to read the present tool number OEM dro. The DRO's remember the information, even when the machine is switched off.

Your VB would read something like  - prestoolno= GetOEMDro(***). What you choose to do with that is dependent on your tool change routine - I assume it is just to let your tool changer know where it is. You could have this printing a warning on the screen, or moving the tool changer to the correct "slot" if it not there.

93

General Mach Discussion / Re: 'offline' Simulated Run

« on: March 17, 2009, 05:51:37 AM »

Bill = I'm not sure what you mean when you say a simulated run.

I load GCode into my office computer, and run it there - there is no machine attached - and the computer will run the code and show me the output on the tool display.
Or are you meaning the "simulate program run" on the toolpath display screen.

If you are saying that you run a program, without a machine atached, (which I suppose would be fairly simple if you were using "smooth stepper" or similar) and when you re-attach your machine the actual position does not correspond to the dro's, well, I don't think it will, or can do, because Mach is not controling the machine if it is only a simulation. To keep accurate position, Mach 3 needs to start at a known point, and then it adds, or subtracts all moves from its Machine Co-ordinates position.The program display which we tend to watch, is the same display, but with all the offsets disregarded, so it bears a resemblance to the GCode program.

You could write down your Machine Co-ordinates before and then type them into the DRO's afterwards, which would put the machine and computer back at the right "place" so to speak, but the problem would be that Mach would have different offsets, etc in it from the program you simulated - so although your Machine Co-ordinates were OK, your Program Co'ordinates could well be off.

94

General Mach Discussion / Re: Motor Tuning Issue

« on: March 17, 2009, 05:25:26 AM »

The thing is, without a machine attached, you can't have a proper go at motor tuning - which depends on your motors on your machine, not on Mach 3.

I have Mach installed on two computers - one in my "office" - front room - where I do all my programming and GCode work, and the other in the workshop.

The one in the workshop attached to my lathe/mill is tuned to that - i.e. rapids 40 ipm acceleration at 3. This is the fastest my machine will move reliably - because it is reliability that you must aim for when machining.

The one in my office, I have the rapids set at 160 ins per minute (my lathe bed is only 20 inches long) - four times faster, so that when I am running a test program, it speeds things up a bit, when I am watching. A G1 move does not matter, because the speed for this is specified in the GCode anyway.

The only way to reliably set the motor tuning is to attach the machine. If you ony have the one computer, keep the machine attached, but do not put any tools in so nothing gets damaged.

95

General Mach Discussion / Re: home position problem

« on: March 17, 2009, 05:12:23 AM »

I'm sorry. I know very little about Lazy Cam. I had a look at it , and what seemed to be the tool (the circle with four quarters in) responded to the shift draw (blue box) instruction, and with that you could move it round the screen.

Had you been running the program somehow - it might be at the position that it was left when the program ended.

I don't think this will affect the 0.0.0 position of the whole system, though. Your point of origin will still be in the same place.

96

General Mach Discussion / Re: home position problem

« on: March 15, 2009, 05:51:59 AM »

Alex - I will explain how it works, although it might not actually help you directly.

When you say "home" the machine, this is a term that refers to the machine going to a certain place on its own - usually to switches set in that position. The machine is then "home". The machine co-ordinates - displayed when the "machine co-ordinates" button is pressed and the led is lit is turned to zero (usualy automatically) see Config/Homing. If you do not have switches fitted, you can make a home position - one to which your machines goes accurately, and then zero the machine co-ordinates by pressing re"RefAllHome"

This position is not the "program position" As you have found, programs have different 0.0.0. positions for which you can make jigs to hold the workpiece.

What you do to bring the machine to that position is apply an offset to the machine co-ordinates 0.0.0. position by using one of the offsets G55 to G59(then 250 others on G59.***). These offsets are entered into your fixtures table (see Config/Fixtures). If the offset is then entered at the beginning of the GCode program, the machine will home to it's home position, then will move to the new 0.0.0 position determined by the offset.(or any other point referenced to the new 0.0.0 position).

So - select a set position to home your machine to, then for each program jog the tool to the 0.0.0 position of the particular program you are doing. Type in an offset e.g. g56 on the MDI line, and then zero the Program Co-ordinates. If you check the fixtures table, G56 will now show the offset for this program. Enter the line "G56" at the beginning of the program, and that is it.

Your program will now run from your "home" position, and then move to the correct start position. If you then have a new program, with a different start position (or 0.0.0 position) you use a different offset. Then for each program you run, the machine automatically moves to the correct start position for that program.

It is useful to keep a note of the offsets (I usually put a message line is the GCode program) so that, if I loose any settings, I can always set them up again.

As I say, this might not be a direct answer to you question, but it explains how it works, and I am sure you will be able to work it out from that.

97

General Mach Discussion / Re: Is CV my Friend?

« on: March 13, 2009, 06:06:55 AM »

The units surely are the units that your machine is set up in - in your case it would seem to be inches - so I don't see the difference betwen 180 and 50 would be noticeable. Whether this changes if you then use millimeters, I wouldn't know, i.e. does Mach 3 take a setting in inches and convert it to millimeters, or does it use the raw numbers.

If you want sharp edges, then you must use exact stop, but as you probably know, this will shake your machine about. You can, of course, introduce GCode to change from one to the other in your program, using CV for the wavvy bits, but using exact stop for the sharp bits.

On CV the next line begins to accelerate up to speed, as the previous line is slowing down, therefore the faster you go, the sooner the "blending" starts. However, if you limit the distance at which this starts, the machine will begin to slow down for the end of the line (depending on your acceleration setting on motor tuning), then it will blend the corner, then it will accelerate back up to speed, but you should get a sharper corner.

I don't think Mach 3 (or any CNC program for that matter) can be all things in all circumstances, and you will have to adjust settings to get the best results for what you are trying to achieve.

98

General Mach Discussion / Re: Debugging stepper stall on specific command

« on: March 12, 2009, 03:51:31 PM »

I keep re-reading this to try and make some sense of it. I do not understand what you are trying to do. As far as I can understand you appear to be using a rotational axis as a spindle for a foam block. I can understand the use of your own units, which you say require 2000 pulses per unit - this I take it, means that 2000 turns the foam block 1 rev. You then say you have this set at 750 per minute. That would mean 125 per sec, which means that your A axis needs 250,000 pulses per sec to turn your foam.

You do not say how many pulses your other axis require per sec other than they are conservative.

The way I understand Mach 3 works on multiple moves (although you do not say what all the other axis are doing) is that Mach takes the lead from the axis that is travelling the furthest distance, then adjusts the speed of all the other axis to finish at the right place at the same time.

It may be that whatever instruction is causing you the problem, and I do not see it mentioned in the post, means that the speed of rotation of the A axis which is traveling 80 units means that the resulting speed required of the Y axis (although it only has to travel one or two) is beyond the capablilities of the stepper - and it stalls.

I have a feeling it might be that your acceleration figure for your A axis is 4 to 1 (roughly). For your Y axis to keep position accurately, it will need the same acceleration rate. You have set that at 7 to one (much slower) It may be that this particular motor will not meet that higher criteria.

99

General Mach Discussion / Re: Very weird crash/problem

« on: March 12, 2009, 02:56:23 PM »

You do not say what output from the computer you are using - LPT1. smooth stepper or what.

I will agree that it would appear that the dir lead on your z axis has failed - and I assume you could test and find out if it had failed high, or failed low. You do not say what breakout board you are using, and whether or not this inverts the voltages from the computer output. What pin do you use for the Z dir lead.

The fact that this rectified itself when you restarted the computer means that the chip set in the LPT1 was also restarted, and so it could have been just a blip in the software, a blip in the LPT1 chipset, or a blip in the breakout board.

I don't see a way of testing, unless you run the program again without a tool in, and see if it re-occurs. Even if it does, you will have a bit of a time tracing it unless for instance you G Code has been currupted and the machine is reading a - command instead of a +.

100

General Mach Discussion / Re: Toolpath Display

« on: March 12, 2009, 02:42:22 PM »

I don't see it as a problem - if you get the display originally, before you start, you get a good idea that what you get is what you want.

I think there have been some alterations to the toolpath display recently, because it takes a lot of computing power, this might be one way to cut down on what is required.