Total Wipe Out

[HackMax]

Has anyone had any issues with Mach 3 Mill going haywire if you increase the feed speed while in a program? I've done it before and not had issues but twice recently Mach went crazy and sent the head crashing into the stock. This last time though I'm so pissed because this part was almost complete (15 hours plus) and I was running a final cut to clean up the bottom of the part since I didnt go deep enough to release the part from the stock. I just re-ran the program that cuts the part from the stock but changed the final z depth .010 deeper so it would release it from the stock. I figured I would just speed up the feed while it wasn't cutting anything and then reset the feed speed when it got near the bottom. I had the original speed at 4 ipm and increased it to 10 using the bar graph tool in Mach. I didn't pay much attention to it because I done it before with no problem but this time all the axes went crazy. The z even tried to plow into the table before I could hit the emergency stop. I'm so F@#$%*g pissed. I hate to go EMC2 but i'm surely going to see what it can do for me now.

Rick

[keithorr]

been there done that. I never use the feed rate change. I edit the g code instead, which can be a hassle if there are many feed rate changes. Might have to go back to the cam software and re-do your toolpath from scratch. This is one of many problems when you make one offs. In production, the first piece is sacrificial while you optimize the code.

Now you know the software has a quirk, you can work around it. Use nc verification software or backplot your toolpaths as a matter of procedure.

You know that problem you have where the thing goes wrong and everything gets screwed up? Stop doing that.

[vlmarshall]

Wow, sorry to hear that one. Still, thanks for the warning about the feetrate bug. What version of Mach were you using?

[HackMax]

been there done that. I never use the feed rate change. I edit the g code instead, which can be a hassle if there are many feed rate changes. Might have to go back to the cam software and re-do your toolpath from scratch. This is one of many problems when you make one offs. In production, the first piece is sacrificial while you optimize the code.

Now you know the software has a quirk, you can work around it. Use nc verification software or backplot your toolpaths as a matter of procedure.

You know that problem you have where the thing goes wrong and everything gets screwed up? Stop doing that.

I had the piece 99% complete so I'm sure the code is fine except for that minor depth problem. As a matter of fact if I had the stock mounted to a solid plate my depth probably would have been right but that last .010 to .020 was probably pushed down while being cut. I've sped up the feed rate plenty of times without a problem but from now on I guess I'll have to rewrite the code specifically to do what I need so I don't have to change things on the fly. I was sooooo close to a perfect part though. I had already boogered up a previous one optimizing and verifying the code and this one was going to be the final coding trial.

[HackMax]

Wow, sorry to hear that one. Still, thanks for the warning about the feetrate bug. What version of Mach were you using?

This was 2.63. I know there is a newer one out but I haven't had a chance to install it yet. Whether the new one will make it more reliable I have no idea. I depend on that feed rate option to test the maximum speed I can cut the part for certain operations. Now that I can't trust it I need to find an alternative way to test.

Rick

[Khalid]

basically this is not a bug... In Mach3 you have Look ahead features...If your Look ahead is 20Lines, then actually your machine is running 20 lines in past but the processor has calculated 20 lines ahead and cammanded in Buffer to run ur machine...

Another thought is you are loosing steps this may be:
1- Your rails and leadscrew is not clean enough as before..
2-Tool teeths are not sharp..
and many many more...

[jalessi]

In the general config portion of Mach3 there is a option called:

No FRO on Queue

If checked, it will delay the application of feed rate override until the queue of commands waiting to be implemented is empty. This is sometimes necessary to avoid exceeding permitted
speeds or accelerations when increasing the FRO above 100%.

This may help.

Jeff...

[HackMax]

basically this is not a bug... In Mach3 you have Look ahead features...If your Look ahead is 20Lines, then actually your machine is running 20 lines in past but the processor has calculated 20 lines ahead and cammanded in Buffer to run ur machine...

Another thought is you are loosing steps this may be:
1- Your rails and leadscrew is not clean enough as before..
2-Tool teeths are not sharp..
and many many more...

The machine rapids 60ipm and is quite clean so 10ipm shouldn't be an issue. I sped it up because it wasn't cutting anything, just going over what it had already done. I just needed to clean up the end portion a bit and it was no where near that point. I thought the same thing so I made sure all was clean. I saw the z dro trying to bore the head into the table before I stopped it. I was wondering looking at the screen why I could hear the thing icreasing in speed but the display didn't show it increasing. This is why i wasn't looking at the table and didn't catch it sooner. This is the second time its happened. The first time I didn't think much of it because I caught it in time and no damage was done.

Today I'm going to do some testing cutting air to see if I can recreate the event. Computers aren't failsafe and I'm thinking it may have just been a rogue hickup in a memory location somewhere. I need to make sure I reboot the PC when I come in to work too. Windows XP isn't the best thing to leave running for weeks without a reboot.

Rick

[HackMax]

In the general config portion of Mach3 there is a option called:

No FRO on Queue

If checked, it will delay the application of feed rate override until the queue of commands waiting to be implemented is empty. This is sometimes necessary to avoid exceeding permitted
speeds or accelerations when increasing the FRO above 100%.

This may help.

Jeff...

Thanks Jeff, I will change that.

Rick

[ger21]

The FRO has been changed since 2.63. There is now a separate FRO for rapids, and the standard FRO does not affect rapids anymore, although the two can be linked.

You might want to try the latest lockdown. But you also should back up your current version, so you can go back to it if you find other isues with the newer vesion.

[mecheng10]

Along the lines of this post, I had a similar event occur yesterday where my machine flipped out in the middle of a rectangular pocket while I was using the feed rate override to speed things up. I increased the feed rate using the override while in a part of the pocket that was cutting air, and the y-axis took off in a portion of the toolpath that only called for x-axis movement. Luckily I was using a 1/8" end mill at the time, so I only snapped that off leaving a small nick in my part rather than completely trashing the part or my machine.

-Brian

[HackMax]

Along the lines of this post, I had a similar event occur yesterday where my machine flipped out in the middle of a rectangular pocket while I was using the feed rate override to speed things up. I increased the feed rate using the override while in a part of the pocket that was cutting air, and the y-axis took off in a portion of the toolpath that only called for x-axis movement. Luckily I was using a 1/8" end mill at the time, so I only snapped that off leaving a small nick in my part rather than completely trashing the part or my machine.

-Brian

Well at least some good has come out your experience anyway. There may be a problem since I'm not the only one. Mine went off in the y direction snapped off the bit then stopped and went in the z direction. Of course it was down instead of up.

I think I've figured out a way to salvage the part anyway. Since it is going to be chrome plated I can drill out the part where the z attempted to plow through the table and press a plug into it. Chrome plating should cover up any flaws there (hopefully.) Where the y went askew and left a divot isn't really that noticeable where the part is intended to be used.

Rick