Operations Reverting?

[Altek]

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

[Guest]

Jason,

 

Have you sent this "suspect" file off to QC?

 

That is probably your best path.

 

I have seen some strange things but I can not honestly say I've seen what your describing.

 

Good Luck

[gcode]

You might try turing off Windows System Restore.

I've seen that fix weird problems like this.

I've also seen pleny of other sytems run fine with it turned on.

The only failsafe remedy it to run all posted code thru gcode verification such as Vericut or

Predator. That has saved me more times than I can count.

 

Are you programmer's MCX files on a network or on their local harddrive??

[Hardmill]

Gremlins maybe ???

 

 

PEACE

[Altek]

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?

[gcode]

I don't work off a network cause I don't like the performance hit you get when working with large files.

I've sseen people have serious trouble working off a network, but never could find a common thread.

I did have a thought while watering the bushes

this evening.

An open MCX file that has surfacing toolpaths

creates regen files typically pathed to the Regen folder on the hard drive. If you've got solids in the file there are bunches of X_T files pathed to a TEMP folder.

Now suppose the clock on your network is 5 or 10 minutes ahead or behind your computer's clock.

Could a big difference in timestamps between the hard drive files and the network files cause a problem?? Does X even look at timestamps when pulling up a regen file to post an operation???

I don't know.

At my last job, I always kept my computer's clock set right. The network was always 5 minutes slow.

Every time I opened files off the network I had trouble so I just quit doing it.

Coincidence??? probably, but it would make an interesting experiment.

Maybe someone from MC could chip in with some info on how X flags regen files.

If you look in the Regen folder when doing a big surfacing file there are dozens of regen files there. Could a difference in timestamps between the MCX file and the regen files cause problems?????

 

If X pulled up an obsolete regen file when posting

that could ceratinly cause the

"Roll tool automatically based on geometry"

issue that bit Collin today.

[Altek]

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

[Rick Henrickson 65]

Altek, I have not met you but I did know many people there. Is Jim still working there on the Mazak Cell and is it true you guys are moving to Everett?

[Thad]

quote:

---

* 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)

---

I haven't read the entire thread, but yes, I've experienced this and sent it in to QC. Rob P says it's fixed in the daily version of X2.

 

Search for my member number and "rigid tap" and you'll find my recent thread on this.

 

Thad

[VBJB]

quote:

---

*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.

---

I had this problem, but it was my fault. If you use a lot of hotkeys you have to be careful where your cursor is when you do your hotkeys. If your cursor is over the operation manager and you are hitting hotkeys for your graphics window you may be manipulating your operations. For instance, you might be deleting them. This was true in my case. I have ALT> mapped to create arc. However, if I do this same key press while my cursor is over the operation manager, it deletes any operation that was selected. Ever since I figured this out none of my operations have "disappeared."

[Thad]

quote:

---

I haven't read the entire thread, but yes, I've experienced this and sent it in to QC. Rob P says it's fixed in the daily version of X2.

---

Slight correction. The problem that I experienced with changing drilling ops was when I imported them from my library. They are saved as G83, but when imported, they somehow switch to G81. Also, my rigid tapping cycles get jazzed up also when importing them.

 

Thad

[SBerg]

I also have not read the hole thread, but YES those things are happening Altek, to me as well.

So, I just quite copying programs from other programs. I know that is not a fix and MC needs to address this issue.

[Guest]

We are also experiencing this phenomina, thought it was me hurting head at first.

copied ops are reverting back to defaults.

ie profile op was copied and ended up with the default cut depths.

 

Doug

[edmBosto]

Doug,

 

______________________________________________

ie profile op was copied and ended up with the default cut depths.

______________________________________________

 

When I was using Mill 3 in V9 I always had to change the Z depths. I always picked new geometry and had to click on the surface or an entity to reset it.I don't believe having the same Z in the stored operation is an issue.

 

Shouldn't you just need to change your library Z depths to a safe number so when you import them

and forget to change it you won't get bitten?

 

That's if I'm understanding you correctly.

[Guest]

multi passes and depth cuts reverted back to a

default.

when i copy an step i expect it to be an exact copy regarding all parameters within that step. now as soon as new geometry or some other parameters are changed in the copied step then its a hole new ball game.

never seen this behavior in version 9

 

doug

[edmBosto]

I think we were talking about 2 different things.

I was just mentioning the actual Z height of the geometry needed to be requalified by hitting the depth button and clicking on the geometry to reset the Z.

All the other parameters were always the same when I imported an operation. Even the Z cut depths.

That's all.