Hello Guest it is April 18, 2024, 05:45:30 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - alkassell

Pages: 1 2 »
1
Galil / Feed freezes
« on: October 21, 2013, 02:07:34 PM »
This was first posted under "General Mach Discussion", but Hood suggested I ask here, as he suspects it may be the Galil plugin hanging ( I'm using V 4.4.0.0 ). Soo.. here it is:

I've got a problem with my CNC / Mach freezing, and can't find any posts for this exact problem:

 I have been running some longer programs (89,000+ lines...), and at random times, the mill will freeze in place. Mach stays frozen on one line in the display, but the PC isn't frozen. I can click on various buttons on Mach. Clicking on 'Cycle Start' has no affect, but clicking 'Hold' turns the highlight off on "Cycle Start". If I hit "Cycle Start" after "Hold", it will not light up again. If I hit "Stop", it stops as it should. I hit "Cycle Start" one time, after I had hit "Stop", and it did start up again, but as the spindle had stopped, it promptly broke my carbide endmill (oh joy... ). This has happened 3 times on the same program, but at different points. I have restarted the computer after each incident, as well as the Galil card. I saw in another post that someone had issues with having a flash drive plugged in ( that's how I transfer my files to the mill ), so I tried transferring the code to a folder on the PC, and running it from there with the flash drive unplugged - same result. I've had this kind of problem before, but only very intermittently - probably just didn't rear it's ugly head in shorter files as often, so I could get through them after one re-start.

Here's my setup in brief - I can give more detail if necessary :

Dell PC with a Pentium 4 processor, 3 Ghz, 1 G ram, running XP SP3, dedicated for use with the mill - no internet connection, no music playing, etc. I have not uninstalled anything, so there may be unnecessary background windows stuff running - I'm a relative novice, so not sure what to look for, but happy do ditch anything that might help.

BOSS 9 bridgeport upgraded to a Galil motion control card, connected via ethernet crossover cable.

Mach 3 ver R3.043.066

I am way behind with my project, so any help / ideas / thoughts would be greatly appreciated!

Thanks, Alex

2
General Mach Discussion / Re: Feed freezes
« on: October 21, 2013, 01:50:48 PM »
Thanks Hood, I will ask there.

Alex

3
General Mach Discussion / Feed freezes
« on: October 21, 2013, 12:48:03 PM »
I've got a problem with my CNC / Mach freezing, and can't find any posts for this exact problem:

 I have been running some longer programs (89,000+ lines...), and at random times, the mill will freeze in place. Mach stays frozen on one line in the display, but the PC isn't frozen. I can click on various buttons on Mach. Clicking on 'Cycle Start' has no affect, but clicking 'Hold' turns the highlight off on "Cycle Start". If I hit "Cycle Start" after "Hold", it will not light up again. If I hit "Stop", it stops as it should. I hit "Cycle Start" one time, after I had hit "Stop", and it did start up again, but as the spindle had stopped, it promptly broke my carbide endmill (oh joy... ). This has happened 3 times on the same program, but at different points. I have restarted the computer after each incident, as well as the Galil card. I saw in another post that someone had issues with having a flash drive plugged in ( that's how I transfer my files to the mill ), so I tried transferring the code to a folder on the PC, and running it from there with the flash drive unplugged - same result. I've had this kind of problem before, but only very intermittently - probably just didn't rear it's ugly head in shorter files as often, so I could get through them after one re-start.

Here's my setup in brief - I can give more detail if necessary :

Dell PC with a Pentium 4 processor, 3 Ghz, 1 G ram, running XP SP3, dedicated for use with the mill - no internet connection, no music playing, etc. I have not uninstalled anything, so there may be unnecessary background windows stuff running - I'm a relative novice, so not sure what to look for, but happy do ditch anything that might help.

BOSS 9 bridgeport upgraded to a Galil motion control card, connected via ethernet crossover cable.

Mach 3 ver R3.043.066

I am way behind with my project, so any help / ideas / thoughts would be greatly appreciated!

Thanks, Alex


4
Galil / Re: Error "Galil can't move toward limit"
« on: August 03, 2013, 01:18:19 PM »
I'm having the same problem, but for different ( and unknown ) reasons. Here's the scoop - any help would be greatly appreciated:

I have a Galil DMC 2142 that has been set up and running for a few years with Mach 3 on a bridgeport mill. I've been having some intermittent issues unrelated to this post ( will probably post later...), so I decided to clone my drive so I could return to where I was, and update Mach 3, the galil plugin and the galil firmware to see if it helped. Now that I've updated Mach 3 and the plugin, I get the error "Galil can't move toward limit!" when I try to jog any axis towards the "+" position. It will jog towards the "-" position, and if I use MDI it will move fine with a G0 command in any direction. It also references home fine. I didn't have this problem before the updates, and all settings transferred when I updated.

I'm a novice when it comes to the electronics / programming that makes my machine run ( it was setup by someone else ), so small words please  ;) - it's probably something obvious, but I haven't found it yet.

Thanks, Alex

5
Thanks Mike, I'll check into this some more - seems like very good info ( I'll see if I can get my friend to help - I've run cnc's for a while, but new to figuring out what makes them go - onsite, real time help will be a huge plus, and might save me from catastrophic mistakes). I always intended to post more, but since I didn't have any real resolution, or even progress, I thought I'd wait. I guess I should've been more impatient - I'm getting some good info. Thanks again, Alex

6
Thanks Rich, any input is welcome. If the macro allows me to change the height at which it changes from rapid to feed, it should cure all my ills ( at least for pecking ). Whatever the reason, .010 isn't enough room for my quill to decelerate to the feed speed. My workaround has been to drill a few cycles of air above the surface first, making it start feeding higher up - obviously a waste of time if it can be cured. I'll check out the macro when I get some time - I've got a few glitches to work on anyway ( VFD speeds with cone pulleys, soft limits, etc. ), so I'll have to make some time.
Thanks, Alex

7
Thanks for the interest Mike - I haven't had a whole lot of time to spend on it - have to make those widgets, and I have a workaround. Here's what I have done:
I ran a program peck drilling 80 holes, with 10 pecks per hole, and touched off on an indicator before and after to see if it's losing position, and it was roughly .0006" off (from memory) - considering my quick set up, that the tool's not flat and the machine was made 20 years ago, I consider that to be no error. A friend of mine who is a lot more knowledgeable than me ( that's most people ) said "We should probably stop calling our term "bounce" and call it servo following error on rapid moves...as I understand it all machines have this, and that is why a programmer never rapids right to the start of cutting, or even .010" close!". He also told me on the phone that Mach 3 has a closed loop feedback with the galil motion control card I have so it knows in real time what the encoder shows, so indeed, it can overrun its mark, and then correct without losing position, unlike most other systems ( hope I got that right ).

Anyway, I think that motor tuning can cure it, but since it doesn't lose position it would mean that my rapid would be slower for everything else, and I don't do that much peck drilling, so I've been reluctant to slow it down. I probably shouldn't worry about speed - I do short runs, so the difference would be negligible, and if it keeps me from chipping a tool down the road, it would time ( and $$) saved.

Alex

8
Thanks for the reply Graham - took 'till now for me to get the time to experiment. This is what I've observed: If I set the retract height to be high above the workpiece, then it seems I can escape the problem somewhat. The problem seems to be if the distance between the retract height and the last depth drilled is too short. If I leave roughly .8" between the work surface and the retract height, it works with essentially no 'bounce'. My theory is that it's still ramping up to rapid when it tries to ramp back down to feed if the retract / plunge height is too small (I was retracting to .1" originally). The result of increasing the R settings so far is that it pecks air for a few cycles while bouncing, then works properly when it gets to the top of the part: As the distance of the rapid increases, the 'bounce' at the end decreases until there is none.  I've thought about playing with the motor tuning ( would faster acceleration help, so it gets to its rapid speed sooner, although it seems counterintuitive to go faster?), but since it's a little out of my comfort zone, I thought I'd consult first. If I were making a godzillion widgets, it would really matter, but for now I guess I can live with it as is, or long code around it ( small job shop - short runs  usually). The spindle doesn't seem to lose position ( haven't yet tested it with an indicator, but it will drill multiple holes without a visible change - if I have time today I'll check it with an indicator at the start and finish of multiple cycles). I'm new to using Mach 3, and not the one who did the motor tuning - the people who did that are far more knowledgeable than me, so I'm reluctant to tinker with what they've done (it's a bridgeport upgrade, and I believe most of the values used are ones from bridgeport, but I could be wrong). So far this is the only cycle that's shown any issues - all parts have been within tolerance, although I've avoided G83 because of this issue.

Thanks again for the help, Alex

9
My machine is a Bridgeport cnc, upgraded in '08. It does take some time to decelerate from rapid - usually not an issue when I program with Mastercam, because by default it sets the feed plane to start .050 above the surface ( doesn't for G83, because it's a canned cycle control ed by Mach 3). The mill doesn't lose position on any axis, and the rapid takes more than .010" to decelerate in any plane. The quill will 'bounce' on a stop, and be at the correct height to start feeding at the end of the 'bounce', but unfortunately that 'bounce' brings the bit into contact with the work on a G83 ( yes I'm sure - chipped 2 bits on some 304 SS, the second because I thought it was an incorrectly set tool offset that chipped the first. Watched closely the second go round, and the bit bottomed on ever peck). I could slow down the rapid to below it's max, but that seems a waste for every other cycle. I know that many other machines, if not all, need some room for deceleration (not sure how you could go from rapid to zero without some 'bounce' - isn't that the reason for a slow zone with the soft limits, and not setting the feed plane to the exact height of the work surface?). I haven't checked carefully for backlash on the Z - my parts have been dimensionally correct, but since the Z really only cuts on one side of the work, this could still be accomplished with some backlash ( unlike X and Y, which cut with the ball screws loaded both ways). The frame is a dedicated cnc frame ( dovetailed  J head, not fixed ) so it should be stiff enough.

 It sounds like I'll have to learn to use a subprogram - if anyone can point me in the direction of good info on subprograms, I'd appreciate it ( new to me - until recently I had done all my programming line by line.... My first machine was originally run off punch tape).    Thanks for all the input, Alex.

10
Thanks Russ - I tried that too, with some trepidation ( I know almost nothing about programming ), and I also saw no change. I wondered if there was another macro I'm not looking at, or ? I spent some time on it, and decided to try and find someone smarter than me to figure it out ( that shouldn't be hard...). Alex

Pages: 1 2 »