Just my opinion, I don't think it should be so easy to give Mastercam/CNC Software a pass on this. I haven't been using the software since V5, but I have been a user since V8. Conservatively I've mentioned this bug persisting for 8+ years, but really if I looked up release dates its probably been more like 10. So, for 10 years I'm supposed to just ignore a feature that exists in the software that I actually want to, and should be able to use? Sure I know about the bug, I know what CAN happen, I know how to look for it... but what we users don't know anymore is what gets fixed & when. Without CNC Software publishing a bug/fix list (I'm aware they recently buried one in the latest release if you dig for it, but that's a brand new development) the only options you have are: turn your back on that feature in the software FOREVER, or HOPE that its fixed & use it (again, like you should be able to). I don't disagree with anyone's method of dealing with the problem - to each their own. To me modifying the post is a bad option because I believe outside of the start & end of any tool the motion you see on-screen is exactly what should post in your code. What I disagree with is the principle that a potentially dangerous bug (yes dangerous, it can cause a machine crash - it produces motion different than the values you have set) that has been reported for many, many (many many many) years can so easily be dismissed. For myself, in my experience - I write production programs, aside from making a good part, the other thing I need is efficiency. I can't accept not being able to use reference points. Sometimes what I have running in the machine is scrutinized down to minutes & seconds, as such I cant have a program full of huge, slow (some of our equipment is certainly not the fastest) retract moves. Reference points are a tool I have available in the software that allows me to tailor my programs & minimize wasteful motion. I don't have much choice but to use them to get the motion I want - they're a feature in the software (a basic one at that) to me they should just flat out work. Its hugely disappointing that I have to struggle with this bug constantly, its sad that its experienced by others as well & it has existed this long. -Jason

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

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

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

Hey Beck... Was this what you installed? 1.Microsoft Security Update offered on February 13, 2007: http://www.microsoft.com/athome/security/u...ins/200702.mspx Autodesk is has issued a warning that this is affecting Inventor - some users are reporting problems with other software as well. in addition to un-installing: MS07-013 - addresses a vulnerability in Microsoft Windows, and Office (KB918118) they are suspecting you have to un-install the following as well, to fully reverse the effects: MS07-016 - addresses a vulnerability in Microsoft Internet Explorer (KB928090) MS07-005 - addresses a vulnerability in Microsoft Windows Interactive Training (KB923723) MS07-011 - addresses a vulnerability in Microsoft Windows (KB926436) Hope this is what you were looking for.

TS53, I have seen exactly what you are describing, exactly. Its small consolation - but no you aren't crazy. In fact this is such a regular occurrence (with all three of the programmers in our company) that I'm totally surprised that more people don't experience it or aren't speaking up. I have this behavior happening in X(mr2) currently & also saw it in x2 (actually X2 was so chalked full of bugs I've un-installed it & have gone back to X for the time being - this particular problem seemed worse in X2 but really I only used it for a week or so) All I've nailed down so far it that it happens when you save your file - you can have a file open, save it, post from it (code will be fine) & then exit the software, re-open the file... & thats when everything will be hosed (even posted output). I've sent this one to mastercam with no resolution . All I've recieved back (to date) that seems like it could be related was an answer to another bug that i submitted... "We are currently working on an internal re-write of the Operations Manager to add new functionality and fix several bugs, this one included. We are planning on having this complete within a few maintenance releases. Thank you for your patience." Looks like it could be a while... I feel your pain, Jason

Yea, As you see, I've got mine as a static value in the post. It works for my application because this drive letter is associated with each users space on the network as they log in, so it always pulls from the same location - but yeilds the current user. All I can think of would be if you were able to define the file in the root of the current directory (maybe "file.txt") and then keep your projects in individual directory's. Always calling the same text-file name (at the root of the current directory.) - but that might be a stretch. Good luck.

Don't know about the whole VB thing, but here is an example of how I'm pulling the "programmer name " from a text file that follows the user (as a network resource) It prompts the programmer with a post question & gives them the opportunity to override it - but defaults to the value in the text file. Below are all the strings, the buffer, post questions & logic (plus the text file example at the end) that Ive added in my post to make this happen. Hope it helps - Jason sbufname5$ "g:mcuser.txt" #File Path, Programmer name file, for header sauthname "" # User input Q1-7 # -------------------------------------------------------------------------- # Buffer 5 - Holds Username from File 'sauthname' # -------------------------------------------------------------------------- fbuf 5 0 80 1 1 fq 1 sauthname "Programmer is //sauthname//. [Enter] to Accept or Type New Value." fq 2 sauthname "Enter Programmer Name. [ENTER] = None" pheader$ #Call before start of file if fexist(sbufname5$), [ sauthname = rbuf(5,1) q1 ] else, q2 if sauthname = "", sauthname = "********" if progno$ > 0, "O", *progno$, "(", sprogdesc, ")", e$ "(MACHINE - ", *smachine, " ", *scontrol, ")",e$ "(PROGRAM - ", *sprogname$, *sextnc$, ")", e$ "(DATE - ", month$ , "-", day$ , "-", year$ , ")", e$ #" )" 30 char wide "(TIME - ", ptime, ")", e$ "(---------------)", e$ "(", *smcname$, *smcext$, ")", e$ #smcpath - full file path "(PROGRAMMER - ", *sauthname, ")", e$ "(POST NAME - ", *snamepst$, ")", e$ "(MASTERCAM - ", "V", *vers_no$, *m_vers_no$, ")", e$ pspace,e$ g:mcuser.txt (below is what is in this text file) J Tollefsen (LEAVE THIS LINE AFTER NAME)

Gcode: Excellent thought, I follow what your thinking but I should have told you more details of what I’m actually doing in my file. The Part I was working on didn’t have any surfacing, in fact all the toolpaths are just the run-of-the-mill 2-1/2D stuff. I am working on a 4th axis – but only doing rotary positioning. So, nothing real special going on here. However I do have a whole grip of solids in there. We do our design in another piece of software and then export the assy. to MC. I don’t make 2d paths off of the solids (usually extract edges and modify) – so everything is tied to normal geometry. Would the solids still be cached, and would this make any difference? Also, about the network – agreed, you do take a performance hit. This file is typical of most of our production work, and the performance is really pretty fair. When things get more intense sometimes I do work of my local machine. And as far as the clock goes, I couldn’t change it if I wanted. Its part of our ‘security policy’ passed down off the network – all computers set to a common clock (the server). Thanks for the thoughts – I appreciate it, If I get some time today I’ll try and do a little testing. Right now I just gotta get this part running. Jason

Colin: Thanks for the confirmation, Sorry to hear about your part – We only have 3 seats here and my other two guys are still in the design phases of their projects (not in Mastercam) since I upgraded everyone to MR2. So currently I am the only one experiencing this, but probably not for long… Also thanks for the ‘lock your ops’ tip – I’ll give that a try. Gcode: Had a feeling that a network question might pop up. I almost included that in my original post. Yes our files are stored on a server. And weather or not it’s a good idea we do work on the majority of our files straight off of the network. Too many benefits to having our work stored in a central location that has data integrity – I’m sure you understand. Not that we want to change the way we work – but do you know something? Or do you just have a hunch that that could be adding to our troubles (I’d had that thought too) Hardmill: Gremlins perhaps – Are you suggesting that I throw my PC in a bucket of water? – That’s how you kill ‘em in the movies right? … or was that how they multiply?

Please tell me this is happening to someone else… (Although for your sake I hope not) Some of my operations seem to be 'reverting' back to a previous state after I have saved a file, closed the software and then open it back up. I know it sounds insane - trust me I had real hesitations about posting this. But something is definitely up. Here’s what has happened the two times since I recognized there was a problem & started tracking it. (Who knows how many times I thought it was me)... (Working in V10 MR2) * Drill operations reverting from peck-cycle back to spot/drill (operation was originally copied from a spotting operation and modified to be a peck cycle with a new tool) *Recently created operations totally missing (toolpath group, geometry, & tool strangely still there!) along with deleted operations re-appearing and a copied-then-modified operation reverting back to its previous parameters. The pattern I am picking out is that it seems to be copied operations that are subject to 'change' - but copying ops is my normal workflow. The file I am working on is also fairly lengthy (around 200 operations). CNC, somebody, what the hell is going on? Been using MC since V8, please don’t go through the 'new user' Q&A with me - this definitely seems to be a problem. Any help appreciated. Jason

Doug, I agree with Roger (usually B0) but what I have done in my post is read a misc integer on mt first posted operatio which I set to the rotation I want in my G10. I also have a post question that verrifys the B value it will post (so you have a chance to change it on the fly). It helps me when we are doing de-bugging of our programs, that way it wont make out to the machine at B0 when the parts sitting at a different rotation. Just a couple of ideas Jason

Charlie, Try mcwfo_x, mcwfo_y, mcwfo_z... These should get you what you want, but if you are trying to output a G10 line you will have to do some stuff with buffers as they only apply to the current offset. Hope it helps. Jason Whoops, those were my variables - heres what they really are... mcwfo_x = corgx mcwfo_y = corgy mcwfo_z = corgz

Hey guys, I went through all this too, I recieved the same fix that CNC has addressed in this thread and it didnt work for me either. However I do know what does work... Im not sure what kind of video cards everyone is running, but my three machines are all Nvidia Quadro's (all different models). What ended up working for me was to disable the "unified back/depth buffer" (same option suggested by CNC) at the video card level instead of for just the mastercam ap. Still not real happy about having to do this systemwide but it does make backplot behave. you should be able to find this setting for your card somewhere in the display properties "advanced" tab. Hope this helps, Jason.

Matt, I have a spaceball 4000 FLX - but I'm using the latest software. I have had problems as well with a button I mapped as translucent shading toggle, it keeps reverting back to OP Manager also. I tried all the same tings as you - Ihavent found an answer yet myself. It may be 3Dconexion's software - although I havent had this problem on any other app. myself Jason