I saw this problem not long ago and didn't think much of it.

[huskermcdoogle]

I noticed a while back that one of my files wasn't taking my ref points on the beginning of an op. I use these to get a tool over in XY before diving in Z. Strictly a safety thing for z clearance on approach, then the retract in the op keeps the tool inside the cavity. This said the file was coming from X4 to X5, and this ceased to work on the ops that came with the X4 file. At the time I ended up re doing the operation to get it to work right, posted and went on my merry way.

 

Well lets just say this reared its head again, and I had no reason to look into this area of my program because it was all proven from before, just re post and go. But the act of updating the file from X5 to X6 has caused this to stop functioning again... Now I think I will need a new spindle. My longer than necessarily practical 1" insert mill just made a dive at 25% through a wall in the casting at an angle (in z-). Had I been in 100% I would probably been fine as it would have over torqued out... But being in 25%, I broke the TRK, and the holder spun in the spindle for a few more revs than needed.

 

Now I can't get the ref points to work at all on the ops, new or old. I am out for blood now. I just blew up the only machine in my shop because of a stupid bug. A Bug that has now cost the company I work for 30 grand.

 

Thanks CNC for screwing up a perfectly good functioning operation. I love your software, but the deeper and deeper I get into it, and the more you try to help us by adding functionality, the more and more I need really good third party verification. This should not be the case. BTW, I contacted my re-seller about joining the beta so I could help find these things, but they have not contacted me back since the initial response. I truly do understand what you are up against. I want to help, I really do. But if you or your partners turn it down, I can't.

 

If anyone can help me on this issue with a solution, I would appreciate it, but currently I am going to go back to a full retract over each boss in the cavity, not a huge thing, just lots of wasted motion. I don't think I can get my machine running again though short of getting a regrind in...

 

My pucker factor is currently through the roof. I don't know how to approach the boss man now. We really needed these parts, now I won't have them for weeks.

 

Looks like I need to put on the maintenance hat.

 

 

Husker

[gcode]

Sorry about your machine.. that really hurts, especially since it's the only one you've got.

 

I've run into this problem before and have never found a solution to it other than being careful.

We have a seat of Vericut here, but I rarely have time to use it.

I have never seen this issue backplot correctly and post a crash.

It will stick out like a sore thumb in backplot if you turn trace mode and rapids on.

I also have a full seat of Cimco Edit ( with backplot ) and review the posted code with that.

 

Are you running MU1?? I haven't seen this in X6MU1. I'm not saying it's fixed.. just saying I haven't

got bit by it lately

 

 

[huskermcdoogle]

Well this puts me in a pickle... I tried and tried to get the thing to output right, so for chucks, just like any other time mastercrash gives me trouble, I close the window, reopen, and voila! It works properly. Now I am really really really really mad.

 

I am going to attach some code. Posted without any changes in the operation manager or hand edits.

 

You tell me what you think...

 

I $h!t you not I did not play with this at all other than, open the file, regen (tried that before to no avail), and post.

 

It's not just the first oops...

Good Code...

Blows Up Spindle

 

Husker

[huskermcdoogle]

 

It will stick out like a sore thumb in backplot if you turn trace mode and rapids on.

I also have a full seat of Cimco Edit ( with backplot ) and review the posted code with that.

 

Are you running MU1?? I haven't seen this in X6MU1. I'm not saying it's fixed.. just saying I haven't

got bit by it lately

 

Yeah I had verified my backplot a few days ago, was good then. But didn't post it then, I just posted it today. And oh yes it stuck out like a sore thumb upon reviewing the backplot to see the problem area.

 

I am running MU1

 

Thanks for the sympathy. I called the bossman and he is in the I don't care what you have to do to that spindle to get the parts out the door mode. "I don't care if you have to die grind out the bad spots to be below the contact, we need to ship 25pcs. on monday"

 

SPindle

[gcode]

GOOD

 

G03 X-.8579 Y3.4719 Z-.7637 I.1439 J-.173

G01 X-.9201 Y3.3556 Z-.7577

G00 Z.5

(MILL SMALL BOSS TOPS)

X-10.5322 Y-2.6975

Z-1.7972

Z-1.9472

 

 

NOT GOOD

 

G01 X-.9201 Y3.3556 Z-.7577

G00 Z.5

(MILL SMALL BOSS TOPS)

X-10.5322 Y-2.6975 Z-1.7972 <------- blam!!!

Z-1.9472

G01 Z-2.1159

[huskermcdoogle]

You found the first of three or so major issues so far... But that was the demise of our spindle. The others would have just been broken tools. I can handle that.

 

 

Husker

[huskermcdoogle]

Gonna go home and not sleep so much tonight. So much for fishing tomorrow morning...

[Newbeeee™]

Husker,

Do you look on Practical Machinist?

http://www.practicalmachinist.com/vb/cnc-machining/spindle-taper-repair-122416/

If you do, Walt@SGS would sort it for you (asuming the bearings are ok).

HTH

[Jayson Kramer]

What path was it?

[huskermcdoogle]

What path was it?

 

Contour 2d

 

Technically it was going from a 2D High Speed Dynamic Core to Contour 2d

[huskermcdoogle]

Husker,

Do you look on Practical Machinist?

http://www.practicalmachinist.com/vb/cnc-machining/spindle-taper-repair-122416/

If you do, Walt@SGS would sort it for you (asuming the bearings are ok).

HTH

 

 

Walt wouldn't be able to get it fixed for us fast enough. (Need to deliver parts Monday!) Not to mention it has a small crack in it next to a drive key. We sanded out most of the crap, and brought it down the the plating (spindle has been out to rebuild before). Then lapped it for a few seconds with a new holder to get out the final high spots. The machine came with bad bearings and the spindle taper was pretty rough when we aquired this machine, so after only two years it is a pity this will need a new spindle again. Final result on the taper is that it runs slightly less than a thou at twelve inches g/l. Bearings don't sound terrible, but you can feel a little grumble when spinning it by hand, but it comes and goes randomly. I can accept that for 25 open tolerance parts. No boring involved, and no super tight Z blends or anything. So I don't think I will have a problem getting some parts out the door, just hope the spindle doesn't lock up in the process. Drawbar fingers will all need to be replaced as well. They are pretty chewed up, though I can imagine I have pulled worse ones out of running machines before... I am about to go out and cut a part with it and see what I get...

 

Wish me luck

 

Husker

[#Rekd™]

Wow,this really sucks.

 

I would be so angry.

[Jaz]

I have been seeing this ref. pt. issue since X4. It doesn't always do it. If you open a fresh session and regenerate the toolpaths, they will be good. If you have been working a file for a while the toolpaths can backplot good with ref. pts. but not post them. I have come to depend on Vericut.

[Altek]

First: Sorry to hear about your machine...

 

Second: In some weird-twisted way, I'm happy to see someone posting about this.

 

This is a LONG STANDING bug with Mastercam. I personally have history with it that goes back to at least V9 & CNC/Mastercam is well aware of this issue. I find it completely inexcusable that they've let this problem persist so long.

 

Like you've now experienced its pretty dangerous. I've had plenty of crashes over the years from this bug (crossed fingers, no ruined spindles yet: but fixtures/parts/cutters/holders) - and its not for lack of being careful. The thing gcode says about running backplot with rapids on is a must, the approach/retract error will always show on screen - but the problem is hugely compounded by the other flaky issues in Mastercam where ops can go dirty for many random reasons when they shouldn't. Things that you verified & still contain correct values can become dangerous with a simple regen... Add the pressure in your shop on any given "hot" project & that simple edit you just made, like a feedrate change (which I'm told dosent cause a regen, yet sometimes it really does), that you were rushing back out the to the floor just became a machine crash.

 

I'm currently in progress of fighting with Mastercam over this very issue - my reseller is involved, we've cancelled our maintenence over this - its a mess. This should be a very serious issue to them & while it may be putting words in their mouth, I assume this has no priority because its not "reported much" (which has been what they've told me about other bugs). In case you receive a similar response, you should know there's at least one other user besides you who has reported this bug, many times, over the course of 8+ years (thats being conservative), sent files, discussed it with members of CNC Software.... and to date has gotten nowhere.

 

I use reference approach/retract points extensively, there's 3 of us here programming - we all do & all 3 of us have this bug pop up constantly. Usually we catch it before we go to the machine - but it happens all the time. Unfortunately the only way to avoid the bug is to not use the approach/retract points (a poor answer if you ask me).

 

Things I know about the bug that are usefull to know:

 

* its random, you cant reproduce it at will - it happens all the time, but I've yet to find a way to explicitly "create" it.

 

* the bug can affect any toolpath type - coutour/pocket/etc.

 

* it happens in new files, not just files brought in from previous versions (I've had it in every version from V9 to X5 MU1)

 

* when the bug happens & you cant "correct" it with a regen, you must save your file, completely exit Mastercam, re-open your file & then regen (then like magic it will be normal again).

**** this causes a huge problem when sending CNC/Mastercam sample files

the first thing that happens when look at the file is they regenerate it

at that point the issue disapears & they say - "see, no problem"

 

* Run backplot with rapids on (like gcode said), run a complete backplot & look at it directly from the front & again from the side before posting code, look for diagonal rapid motion - do it allways (if you make any edit & regen - do it again).

 

* Through the years I've had a suspition that "regen all" (all or all-dirty) triggers this bug. It may just be superstition at this point, but regen-single seems to "reduce" the amount it pops up. (I have a hard time staying strictly regen-single)

 

* Also through the years a number of "fixes" have been offered. They include things like: dont copy operations, use edit comon pramaters to make changes whenever possible - none of these have ever helped - only complicating life & serving to take away features in the software you should be able to use.

 

For what its worth, I feel your pain

-Jason

[Newbeeee™]

Not to go off topic...I *think* that the big problem with bugs, is people experience them and then look/see them here and asume CNC sees them and are then dealing with them. I'm certainly guilty of this.

I would say if you see a bug, send it in every time. The more CNC get on the same subject, the higher up the list it goes (from my understanding).

 

Lastly, I think a post mod to ensure Z moves on a separate line to XY is the way to sort this. If the code can only output this way, this will never be an issue.

I'm talking with my dealer to implement this when I'm back to work.

[Altek]

I appreciate what you're saying about modding your post to stay safe (I just saw the other thread after posting) but - the fact still stands this is a Mastercam BUG. This isn't a post issue, the post is doing its job. You can verify this by outputting & digging into the NCI file... when this Bug shows the move is omitted from the NCI - and consequently the posted code as well.

 

I don't want to ruffle any feathers & argue the post method - but to me its more the point of: if the Software's bad, why should I have to create a work-arround? why cant they fix it - why can't that be the answer? Seems like an important thing that is basic functionallity, they should want that to work. Without fixing the software, the on-screen would have me believe the machine is going to crash - I'm supposed to ignore that, post code & assume the post will "fix it" - to me thats backwards.

 

As for reporting bugs, I'm on the opposite end & its really the whole reason I wanted to chime in here. I always report my bug findings directly to CNC (after testing them, creating examples, etc). But my experience on this one has been ridiculous & long. For that reason, I just wanted others to be aware it has a (long) reported history (currently still being reported as we speak). Like you I'd encourage people to send it in - I just wanted help add to the awareness.

 

-Jason

[Newbeeee™]

Jason - I fully agree with you 100%.

I don't knock out anywhere near the programs you boys do, and I have never seen an XYZ rapid move before. And I really don't want to ever see one so I'm going to go the post mod route in case I miss it in backplot. Safety (machine) is my no 1 concern as I write the cheques .

[Mick]

That sucks to hear about your crash. I would be annoyed, and angry too.

 

I modified my posts to force "dog leg" moves, ie, XY on one line, and then Z on the next.

 

I did this, because I prefer not to rely on reference points, because it is all too easy to forget to set the reference points. Also, it is easy to open the file months later, and accidentally uncheck the reference points.

 

I've read about this bug elsewhere, and I believe, back in the V9 days, I experienced it once or twice. It was around then that I forced the post to output the moves, because I didn't want to experience it again. I've never purposely programmed an XYZ rapid move, as I prefer to err on the side of caution/safety.

[GoetzInd]

Just curious. What kind of machine/control. How'd you spin the holder if it has drive keys?

 

Mike

[Jim Evans from CNC Software]

For those that have seen this or have a part with this issue, please, please send QC the files - zip2go everything. Yes many times if we regen the file the issue goes away, but we do pass those files on to development to see if they can find something in there to help decipher what is causing the issue. I have to ask, do you run with multiple instances of mastercam open at the same time? What other programs do you have open? What 3rd party programs do you have installed and run? The more information the better as it will help us try and chase down potential causes when trying to reproduce the issue.

[gcode]

I've been seeing this since V9 but have never suceeded in building a file that could replicate it.

I usualy just delete the offending operation and rebuild it.

When I'm using reference points, I always backplot each tool with trace and rapids on before posting.

Unless it's a super busy file it's pretty easy to spot.

[Altek]

Hi Jim,

 

If you'd like to see a file you should talk to my re-seller (we're NetHASP #749). I just sent him a fresh example last month from one of our other programmers (in addition to other files that have been sent in over many years that should exist somewhere). There should be a conversation about this very issue in progress (I'm currently waiting again for a reply) & without trying to be evasive or muddy the water - I'd like to just leave it at that. Theres already too many people in the conversation as it is, from CNC & my resellers office. Details aernt being kept straight & people keep getting added - I have to keep explaining it over & over... If you'd like to contact me directly afterwards, please feel free (I have more files that I've saved up where this problem is captured).

 

To address your questions (programs, 3rd party, etc.): Its not an exaggeration when I say 8+ years history with this bug. So that means every version of Mastercam form at least v9 (V9, X, X2, X2 MR1, X2 MR2, X3, X3 MU1, X4, X4 MU1, X4 MU2, X4 MU3, X5 & X5 MU1 - NOT USING X6 YET) probably 3 diferent operating systems on 9+ computers (3 workstations upgraded every 3 years), 8 years or driver updates, versions of other software we run (Inventor, our ERP system, etc) & our company's network & policy changes/upgrades. Over those years, hundreds of combinations of hardware/software/etc. - yet the bug has still always been there.

 

I understand what you asked for was just good troubleshooting (and wasn't really trying to be sarcastic above, as much as just give you an idea of the scope of the problem) but for me, at this point, its so far beyond that & seems to be something that's obviously broken at the core of the software.

 

-Jason

[huskermcdoogle]

I would send in the file, but I don't know if I have a version of it saved that has the missing NCI moves. Anyway the file is 100+ MB, so how would I send that in? I cannot post it on the FTP.

 

Husker

[3rdstring]

I would send in the file, but I don't know if I have a version of it saved that has the missing NCI moves. Anyway the file is 100+ MB, so how would I send that in? I cannot post it on the FTP.

 

Husker

 

I use Drop Box to send a file like that. Just upload the file to your public folder and send a link for them to download it.

[huskermcdoogle]

I use Drop Box to send a file like that. Just upload the file to your public folder and send a link for them to download it.

 

Yeah I suppose I could do that.

 

Husker