runaway

[blighty]

hi all,

my cnc mill has been up and running a few weeks now and 9 out of 10 times i will get a runaway. but i cant think of why I'm getting them.

what happens is......... it will follow the tool path, then for no apparent reason it goes of and does it's own thing. it's not loosing steps because when i home the head it's spot on. plus the DRO's on mach are saying where it is when it runs off. it's not the G code, as when it did it today i re-run the code from 3 or 4 lines before the line it had the runaway on and it finished the part fine.

any ideas?

[LongRat]

Strange - I was going to suggest that something on your computer might be corrupting the pulse stream to your parallel port, but that's not the case if the Mach DROs are all reading correctly. If you have a MPG pendant or anything check that, possibly detach it and run again. Also, might sound stupid, but make sure there's not a problem with your keyboard causing it to send jog commands to Mach. When it runs away, is this a randomised path in 3 axes, or single axis movement only?

[LeeWay]

Something ain't right!
I know I have a knack for stating the obvious in the case. This isn't really a run away. Not if it's keeping position.
I have experienced a run away a couple of times on my router and it runs all three axes at full rapid just where ever it wants to. Right through clamps, parts and limit switches. Estop did not work in these instances. I didn't have a real one hooked up. Just simulated in Mach. I now have a hardwired Estop.
The problem in my case was the laptop would just suddenly hibernate. No reason at all for it really, since I had messed with the mouse just prior to running it, so it should have reset to whatever time it was set at internally.
I had thought that I had disabled all that stuff, but there was a little power item in the Bios that was over riding the other settings.
It hasn't ran away now for several months. I can leave it on all day now and it is always on.
Sounds like your problem is somewhere else though.

[blighty]

hi longrat,

not sure what a MPG pendant is, so i cant check that.

i some times have problems with the keyboard, every now and then when the pc boots the keyboard doesn't work properly. all the keys are all over the place. if i take out the USB for the keyboard and put it back in a gain, it works fine......... but maybe you have something there. i'll get another keyboard just to make sure.

it's not a random path. it's like it has an off set and continues with the tool path and feed rate, but over to one side.

i'll try and explain what it did the last time.....

the line of g-code was (lets say)
g01 x100 y20 f100
g01 x100 y-10 but instead of going here it went 45deg in a +X -Y direction
and when i stopped it the DRO's read X120 Y0 witch was exactly the position of the cutter.

hope the makes sense

[LongRat]

If you are using backlash compensation (best avoided really but works for some) check you haven't got a HUGE backlash value set. If you have, any axis reversal would preceded by a move of that size.
MPG is a manual pulse generator - in this context I'm talking about a 'jog wheel' that is hooked up to your PC to jog the machine manually, a kind of electronic handwheel. You clearly don't have one of these so that's not your problem. Check your keyboard, and apart from Lee's advice above, I'm pretty short on further ideas...

[The Blight]

What software are you running? It almost seems like the interpreter is missunderstanding the code. The fact that you said "the leys are all over the place" could also point in that direction. Never heard about a problem like this before except in MS-DOS.

[blighty]

longrat...... you would be right in saying i'm not using MPG and i haven't got any backlash comp set.


Blight,

the software was mach3 R2.63. today i upgraded it to R3.041 but as yet not had the chance to play with it.

as for the keyboard, i got it from a mate who said it was doing funny thing's, but didn't say exactly. when i plugged it in for the first time it worked fine. then every now and then it would go funny. when i told him he said that's what it did when he had it. think i will change it.

would it help if i posted a pic of the parts and the code?

[Alex_Cole]

I ran into this several times with my mill. I tracked it down to the look ahead setting in Mach3. I am not sure if you are using this but I had mine set to 1000 lines... I think this must have been too much as it would act like you are describing.

When I set the look ahead to 100 lines then everything is happy.

Not sure if this is your issue but worth looking at.

AC

[blighty]

hi Alex,

yes, you could be right.

i had a look at that last night. i think by default it's set to 20 lines. a mate of mine said set it to 200. but i cant remember if he said any thing about "if you get problems knock it down to 190 etc,etc"

i'll fit the new keyboard, set the look ahead to 100, check the backlash comp, have a look at the Bios and hopefully it should work, if not i'll set it on fire

[blighty]

update.........

well i fitted the new keyboard, set the look ahead to 100lines,checked the backlash comp and now running mach 3.041.

i then (using a pen in the chuck) run all the g-code that i had runaways on several times. no problems to be had at any time..........yhaoooooooo.

thx to all that help with this


this is where the but comes in......

i have found a new problem that didn't exist before. Now when ever there is a G90 G28 G0 Z0 it will send the head to the machines Z0 and not the jobs. luckily i found this out with a pen in the chuck as it rammed it 2 inches into the job at 4500mmpm (177ipm).

this is some of the code.......

%
O5000 (PROBE1.TAP)
( MCV-OP ) (05-NOV-2008)
(SUBROUTINES: O2 .. O0)
G90 G17
G80 G49 G40
G54
G91 G28 Z0 THIS IS WHEN IT SENDS THE Z TO THE MACHINES ZERO
G90
M01
N1 M6 T1
( TOOL -1- DRILL DIA 2.0 MM )
G90 G00 G40 G54
G43 H1 D31 G0 X-3.5 Y-9.9 Z50. S1000 M3
M8

when i set the tool zero, there is a now a difference between the job zero and the machines zero. so when the code says G91 G28 Z0 it will send Z to the machine zero, but that is now -10 below the top of the job. this did not happen with mach R2.63

once again, any ideas

[LeeWay]

You might try the safe Z coordinates. Mine is set to work coordinates and not machine coordinates.
This is under config, safe Z setup.

Under the general config tab, there is also a persistant DRO check box. If that is checked, it will use machine coordinates. Unchecked, then when you set the DRO to 0.00, then that is the new setting.

[ataxy]

update.........

well i fitted the new keyboard, set the look ahead to 100lines,checked the backlash comp and now running mach 3.041.

i then (using a pen in the chuck) run all the g-code that i had runaways on several times. no problems to be had at any time..........yhaoooooooo.

thx to all that help with this


this is where the but comes in......

i have found a new problem that didn't exist before. Now when ever there is a G90 G28 G0 Z0 it will send the head to the machines Z0 and not the jobs. luckily i found this out with a pen in the chuck as it rammed it 2 inches into the job at 4500mmpm (177ipm).

this is some of the code.......

%
O5000 (PROBE1.TAP)
( MCV-OP ) (05-NOV-2008)
(SUBROUTINES: O2 .. O0)
G90 G17
G80 G49 G40
G54
G91 G28 Z0 THIS IS WHEN IT SENDS THE Z TO THE MACHINES ZERO
G90
M01
N1 M6 T1
( TOOL -1- DRILL DIA 2.0 MM )
G90 G00 G40 G54
G43 H1 D31 G0 X-3.5 Y-9.9 Z50. S1000 M3
M8

when i set the tool zero, there is a now a difference between the job zero and the machines zero. so when the code says G91 G28 Z0 it will send Z to the machine zero, but that is now -10 below the top of the job. this did not happen with mach R2.63

once again, any ideas

ah ha, similar problem as me the only thing that solved it for me was to use the mastercam tormach post processor for mach kind of a bad compromise since now the machine does not home itself in between tool change but as long as you are not missing step thing are fine

little gcode problem i guess