I program offline. I have an issue that when I open my programs on the cmm's, my clearplanes and movepoints change, sometimes by many inches! I've actually had it occur on existing programs we've run a hundred times. Has anyone else experienced this? It's a pretty regular occurrence for us.
No. Not that I am aware of and I program offline all the time and send those programs to the online seats.
Are you programming with the correct probe builds? Can you share a simple program code you use to create a program? Maybe there are admin right issues?
Are you making changes then hitting "YES" instead of "NO" or vice versa when it asks you about alignment changes?
This is the first shop of four that I've had it occur in, and I've been doing this for 20 years. There's no changes made. I just open the program, and now, because it's happened so often, verify all the movepoints and clearplanes before executing it.
I had one last Friday. I ran the part without issue. I ran a second part without even closing the program. 80% into the program it slammed into the part and broke the probe. Sure enough, one movepoint and one clearplane changed. I'm not sure if admin rights are causing a problem. We don't have full admin rights, we have QAadmin rights. I've seen so many odd things, and have advocated for full rights, but it falls on deaf ears. IT says it's PCDMIS, Hexagon says it's the computers. Meanwhile, we're stuck in the middle, having to explain why things keep breaking. Being that I've never seen these issues in other shops, I tend to side with Hexagon. I have to repeat program updates 4 or 5 times before they actually save. I've had people stand behind me and watch as I make an update. save it, close the program, and reopen it to find the update reverted. It's some of the most oddball stuff I've ever seen. I've had one feature disappear from an alignment on multiple occasions. Things that I'm 100% positive were there when I wrote the program, without question.
Answering Yes/No incorrectly after changing an alignment would change everything, not just move and clearance points, so we can rule that out.
I have noticed that this is more likely to occur if a program is stopped for any reason during prove-out.
I have a gut feeling that, behind the scenes, PC-DMIS is translating these points/clearance distances back and forth to machine home, and it simply gets mixed up, depending on where it was in those calculations, when the program is stopped.
Workaround is to lock all move points and clearance plane definitions in with formulas, as I described above. Typing a few extra numbers is a much better situation than a rapid move a foot inside the granite.
Answering Yes/No incorrectly after changing an alignment would change everything, not just move and clearance points, so we can rule that out.
I have noticed that this is more likely to occur if a program is stopped for any reason during prove-out.
I have a gut feeling that, behind the scenes, PC-DMIS is translating these points/clearance distances back and forth to machine home, and it simply gets mixed up, depending on where it was in those calculations, when the program is stopped.
Workaround is to lock all move points and clearance plane definitions in with formulas, as I described above. Typing a few extra numbers is a much better situation than a rapid move a foot inside the granite.
