Losing probe calibration during the day???

[dwade]

We have had problems where one CMM has a tendency to lose what I want to think is probe calibration during the day. Me personally, I don't think it can happen without a software or hardware crash but I'm beginning to have my doubts.

I thought that I had brought this up another time but couldn't find anything in my searches this morning. We can be running multiple parts of one size (this has happened with more than just one program) and parts will start showing out of tolerance. We will rerun the parts that were good only to find them out of tolerance and when verified with another CMM (either another Hex or Renishaw CMM) all of the bad parts will check good. We can re-calibrate the probes on the CMM that was showing bad and then they are good.

We do weekly shutdown and restart on the PC and the controller and this is beginning to create a lot of issues with one CMM in particular. This has happened before and after we had the CMMs calibrated this year. Probe builds have been deleted and re-recreated at least twice this year and has not fixed this issue.

[neil.challinor]

A few things to rule out...

1) If your CMM PC is connected to a network, make sure you are not storing your probe files (.prb extension) in a shared netwrok location that is being accessed by multiple CMMs. Probe files are unique to each CMM and must be stored locally.

2) Make sure you only have one copy of each probe file (.prb extension) on the CMM PC - especially if you have multiple versions of PC-Dmis installed. It is better to have one "PROBES" folder and to save your probe files in a format that allows all of your versions to use it than to have a 2016_probes, 2017_probes, 2018_probes for example.

3) Check the permissions for your "PROBES" folder - especially if you have multiple users all logging on to use the CMM under there own individual user account logins. ALL users must have full read write access to whatever location you store your probe files (as well as multiple other files, folders and registry locations).

4) If you perform manual probe changes (i.e. not via an automated probe changing rack), make sure that the modules are kept in a safe location where they can not get knocked and that the connection surfaces are clean & free from debris (and obviously attached correctly) whenever a probe change is performed. A lot of probe modules use magnets and can easily attract swarf / metallic dust.

5) Make sure none of the stylus components are loosened, tightened or replaced during the day without performing a probe calibration afterwards and ensure the probe tip & the part being inspected are both cleaned prior to each program execution.

6) Consider naming your probe files purely alpha-numerically in line with the recommended naming conventions defined in the help file. i.e. avoid names that start with or only contain numbers, do not use special characters, quotation marks, mathematical symbols or brackets and use an underscore rather than a space.

[dwade]

my responses in red

A few things to rule out...

1) If your CMM PC is connected to a network, make sure you are not storing your probe files (.prb extension) in a shared netwrok location that is being accessed by multiple CMMs. Probe files are unique to each CMM and must be stored locally. All probes are on the hard drives and have been for the 12 years or so....

2) Make sure you only have one copy of each probe file (.prb extension) on the CMM PC - especially if you have multiple versions of PC-Dmis installed. It is better to have one "PROBES" folder and to save your probe files in a format that allows all of your versions to use it than to have a 2016_probes, 2017_probes, 2018_probes for example. There is only 1 version of the DEMON loaded and that is V4.3MR1

3) Check the permissions for your "PROBES" folder - especially if you have multiple users all logging on to use the CMM under there own individual user account logins. ALL users must have full read write access to whatever location you store your probe files (as well as multiple other files, folders and registry locations). The users only have one login username and no one has changed any of login permissions since I had Win7 boxes put on the CMMs 2 years ago.

4) If you perform manual probe changes (i.e. not via an automated probe changing rack), make sure that the modules are kept in a safe location where they can not get knocked and that the connection surfaces are clean & free from debris (and obviously attached correctly) whenever a probe change is performed. A lot of probe modules use magnets and can easily attract swarf / metallic dust. No manual probe changes. Everything is done with a probe changer. Probes and module bases are cleaned several times a day.

5) Make sure none of the stylus components are loosened, tightened or replaced during the day without performing a probe calibration afterwards and ensure the probe tip & the part being inspected are both cleaned prior to each program execution. This is checked at probe calibration and when we see the readings take a dump one of the first things to do are to check the probes to make sure the ruby is still there and that the styli is not loose.

6) Consider naming your probe files purely alpha-numerically in line with the recommended naming conventions defined in the help file. i.e. avoid names that start with or only contain numbers, do not use special characters, quotation marks, mathematical symbols or brackets and use an underscore rather than a space. The probe files are named after part families (the practice started long before I hired in and I have continued the practice) and DEMON file naming conventions are used with only alphanumeric names with only underscores and dashes in the filename.

When the parts start reading bad (again, verified good on another CMM or hard check) it normally happens when the ops are running multiple parts of the same size so the program is not closed at all, the program is simply executed again. Nothing changes other than the operator loading another part and program execution.

[Matthew D. Hoedeman]

my responses in red



When the parts start reading bad (again, verified good on another CMM or hard check) it normally happens when the ops are running multiple parts of the same size so the program is not closed at all, the program is simply executed again. Nothing changes other than the operator loading another part and program execution.

that is starting to sound more like an alignment 'drift' issue. Have you done a QUALIFICATION CHECK (not a calibration) of the probe when it does this? Open probe utils, measure, but select qual-check instead of calibrate tips. MUST BE "NO" for tool has moved, and of course, tool must still be where it was when the last calibration was done.

[neil.challinor]

With regards to your comments

There is only 1 version of the DEMON loaded and that is V4.3MR1

and

The users only have one login username and no one has changed any of login permissions since I had Win7 boxes put on the CMMs 2 years ago.

4.3MR1 is not supported for windows 7 as per the read me

PC-DMIS® 4.3 operates under 32-bit and 64-bit (x64) WindowsXP® |
| systems and 32-bit Vista Business®. No other operating systems are |
| supported.

Since Microsoft are now also dropping support for Windows 7, I assume whomever manages your IT will soon insist that you move to windows 10 and so I would strongly advise you upgrade to a more recent version of PC-Dmis. I'm not saying that this is the sole cause of the problems you describe but since the version that your are using was never designed to run on and never tested on the operating system you are using then there could be all kinds of unforeseen consequences and strange, inexplicable behaviour.

[dwade]

With regards to your comments



and



4.3MR1 is not supported for windows 7 as per the read me

Since Microsoft are now also dropping support for Windows 7, I assume whomever manages your IT will soon insist that you move to windows 10 and so I would strongly advise you upgrade to a more recent version of PC-Dmis. I'm not saying that this is the sole cause of the problems you describe but since the version that your are using was never designed to run on and never tested on the operating system you are using then there could be all kinds of unforeseen consequences and strange, inexplicable behaviour.

We've been running Win7 and V4.3mr1 on 3 CMMs and my offline seat for 2 years without any problems. The controllers on this CMM and one of the other CMMs are both B3C-LC, the other Hex CMM runs an FBII controller and no issues with either of those CMMs at all. All 3 of those Win7 boxes were built at the same time and are identical to each other. And I'm not trying to be a smart a$$ but Hexagon will not provide support if you load a version of the DEMON onto an operating system that is not recommended for that version (I've been through that at a previous employer) and they also say that you can't run V2013 on an XP box but I did it for over a year and had no issues running a CMM with it either. Those are guidelines and there are some versions that will not run with certain releases of Windows but there are usually work-arounds because I've run V2011 on a Win10 box and Hexagon says that you can't.

As far as network operating systems, we still have XP boxes talking to Win10 network protocol so upgrading according to Windows is $$ driven. Our company has not kept the SMA up to date (long before my time) so that probably isn't an option until they absolutely have to and then again my not as the CMMs can be ran off the grid.

[NinjaBadger]

My gut tells me something else is going on here but there is a quick way to check your hypothesis.

Next time it happens do this:

From probe utilities window click on a suspect tip angle and click 'edit' - make a note of the X, Y, Z offsets and Diameter & StdDev for that tip.
Then check the results file for the previous calibration of that tip. These numbers should be identical. If they are then the calibration hasn't been lost.
When you then re-calibrate that tip make a note of the new calibration values (xyz offsets and diameter & std dev) whilst these won't be identical there should only be a few micron differences. IF these values are considerably different then there is some other issue going on here.


Further questions which might shed some light...


1) Are these standard programs - i.e. Manual alignment, DCC alignment, measure features etc, OR do they involve looping, flow control, external alignments etc?

2) Have these programs been assessed for repeatability? As this appears to be machine specific it's probably not this but worth asking.

3) You say part which failed are rechecked and show good; but what actual size variation are you getting in results? Can you be more specific in terms of the errors (is it just sizes, positions, are we talking micron differences or something more substantial)

4) What's the environment like? Are the parts cleaned properly, is the temperature stable (both room and parts)? Are there non LED lights just above the machine? What material are the parts?

[dwade]

my responses in red

My gut tells me something else is going on here but there is a quick way to check your hypothesis.

Next time it happens do this:

From probe utilities window click on a suspect tip angle and click 'edit' - make a note of the X, Y, Z offsets and Diameter & StdDev for that tip.
Then check the results file for the previous calibration of that tip. These numbers should be identical. If they are then the calibration hasn't been lost.
When you then re-calibrate that tip make a note of the new calibration values (xyz offsets and diameter & std dev) whilst these won't be identical there should only be a few micron differences. IF these values are considerably different then there is some other issue going on here. I will check this out next time it happens

Further questions which might shed some light...

1) Are these standard programs - i.e. Manual alignment, DCC alignment, measure features etc, OR do they involve looping, flow control, external alignments etc? pretty much standard programming with nothing fancy being done and the programs start with a readpoint then run through the DCC (3-2-1) alignment.

2) Have these programs been assessed for repeatability? As this appears to be machine specific it's probably not this but worth asking. A GR&R was done on the original programs when we started the project 2 years ago and other than the really tight tolerances (0.013mm straightness and 0.012mm circularity) everything was acceptable

3) You say part which failed are rechecked and show good; but what actual size variation are you getting in results? Can you be more specific in terms of the errors (is it just sizes, positions, are we talking micron differences or something more substantial) Most of what we are seeing is surface profile failing as most of the other dimensions are taken with one probe angle doing all of the measuring and the profiles are done with another probe and multiple probe angles

4) What's the environment like? Are the parts cleaned properly, is the temperature stable (both room and parts)? Are there non LED lights just above the machine? What material are the parts? The lab is a controlled environment with temp and humidity being controlled and while I would like to say the parts are always clean I would be lying. We strive to have clean and burr free parts brought to the lab but this does not always happen. We machine (lathe, mill, wire EDM) implants and surgical instruments mainly using SS, titanium and some plastics

[BKulpa]

Are you by chance using any MOVE/ALL commands? I've seen strange results with these sometimes.

[dwade]

No MOVEALL commands

[jtrofatter]

When calibrating probes, do you guys have a master probe that all the other probes used for inspection are tied to?

If you look through the calibration results, do you happen to see any instances where one of the probes used in the program was calibrated by itself?

[dwade]

Probe calibration results look near perfect for everything and typically in all of our programs (going way back before my time) calibrate the probes with YES the qual sphere has moved and everything after that is NO, qual sphere has not without the use of the master probe. We've been running without any issues since I've been here (3 years in October) and now within the last couple of months this happens once or twice a week.

[LostL]

I've seen a similar issue on one machine reacently. It behaved wierdly after the last update of PC-DMIS, upon examination it turned out that one probe angle had nonsense cablibration values. It was calibrated at the same time as other angles that was ok, and the timestamp was as it should. It kept happening despite reverting the probes, reinstalling PC-DMIS, etc. In the end we backed down to the previous version of PC-DMIS and it hasn´t happened since.