hexagon logo

Quirky Issues

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.
  • Are you using the same version of PC-DMIS for your offline programming that you run on your CMM's?


    I see this issue within the same versions.
  • I don't use clear planes, but I've had move points change from an offline program when executing on the CMM. I just assumed it was because I was updating the alignments when adding read points into programs that previously had manual alignments. I haven't noticed if it's happened in any new programs I've written in 2019 R1 but I'm going to make a note to check next time.Slight smile
  • "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."

    Answering yes or no would do that, yes. This is occurring before I execute anything at all. No alignment updates, which would also do it. I'm literally opening the program, and the movepoints/clearplanes are changed. There's nothing going on in between there. In the other instances you've mentioned, I've seen that occur, and the reasons are obvious, as you've mentioned. That's why I'm here. There is no obvious explanation for what's occurring and I wanted to see if others have seen it. Apparently there are similar occurrences. We're having Hexagon app support come to our shop for two days to witness some of the strange issues we deal with.

    Twice within the last three weeks the cmm lost the ability to load and remove probes from the probe rack, while switching probes during calibration! I've reloaded the master probe, reset the tips, re-found the sphere and recalibrated the rack without any issue whatsoever, but it will not load the master probe back into the rack. We just have issue after issue like this. Another common one is skipping a clearplane that causes a crash. The clearplane is clearly there, but it's as if pcdmis never read it. These issues occur on programs that have run 100's of times and on new programs alike. We had a probe run into the granite at 0/0 during calibration! The tech said it took 8 or 10 hits, moved away from the sphere and drove right into the table! How does that happen? This is not a homegrown calibration program either. It's the standard pcdmis calibration.

    I'm not knew to this. I've been programming for about 18 years now. I'm certain I'm not making absent minded errors that are causing these issue. I have a template that I begin all my programs with and it's in a very specific order, so nothing is being missed, and all the parameters are preset in that template. I'm confident everything is correct. Monday I'll see if I can pull some of it from the program to post here.
  • Currently, no. We're actually running 4 different versions, but this was occurring when they were all the same versions, too. We will be getting them all updated to match, but we're having some issue getting our SMA's updated on all the cmm's.
  • Yeah, my clearplane is always set below my MODE/DCC, which is directly under my readpoint alignment.
  • I trust ya. I was just mentioning what I've seen personally.
    You may have answered this, but is this happening to one machine, or all machines? Are you running programs locally, or on the network? Do you have intrusive security software installed? Are you running PC DMIS as admin? Are you running online, operator, or protected mode?
  • I have seen this happen when creating/ deleting alignments to shift features when making programs from similar parts. I perform the shifts correctly because the features move as expected, but the move points do their own thing. I have also noticed that if I run the program offline to reset everything to nominal BEFORE I create/ delete these alignments, that the features AND the move points move correctly.

    I use 2020 R2
  • I have seen this happen when creating/ deleting alignments to shift features when making programs from similar parts. I perform the shifts correctly because the features move as expected, but the move points do their own thing. I have also noticed that if I run the program offline to reset everything to nominal BEFORE I create/ delete these alignments, that the features AND the move points move correctly.

    I use 2020 R2




    I have seen this issue as well. I never associated it with opening a program offline but rather after an alignment change
    I have never seen a move point change by inches but I have had move points change on me and all the other points were translated correctly
  • I can confirm this issue. It happens when you interrupt a measurement routine when online. Move points are stored in a different manner than features. When PC-DMIS comes out of executing, say after your manual alignment is complete, but your DCC alignment hasn't finished been executing, PC-DMIS still stores them based on where your CAD model was supposed to be, typically machine origin coordinates (0, 0, 0), the top, front left of your machine. It is something that has burned me a couple of times. So, when you interrupt your program, your manual alignment for instance might be reflective of where your part is actually on the machine, but your DCC alignment hasn't been executed so the Demon still thinks it is supposed to be at your machine origin.
  • Just submitted this bug to the developers. It's about time we squash this bug. It's been around for as long as I have been using PC-DMIS (about 2010).