Z height issue

[jacyEd]

Ever since I started using PCdmis on our Sheffield RS-670 I have been having problems with concentricity and parallelism. Typically I get numbers anywhere from .008-.150 off from a realistic measurement. I have been able to double check on our smaller CMM and confirm there is clearly a problem. I discovered that when creating a plane it will record inaccurate measurements for the Z axis. We have gone through versions 3.6 pre MR1 to 3.7 MR3 and the problem has existed in every one of them. Any suggestions on what the issue may be would be appreciated.

[bw_bob]

Does it only happen for those 2 dims. A little more info

[dfiola66]

Ever since I started using PCdmis on our Sheffield RS-670 I have been having problems with concentricity and parallelism. Typically I get numbers anywhere from .008-.150 off from a realistic measurement. I have been able to double check on our smaller CMM and confirm there is clearly a problem. I discovered that when creating a plane it will record inaccurate measurements for the Z axis. We have gone through versions 3.6 pre MR1 to 3.7 MR3 and the problem has existed in every one of them. Any suggestions on what the issue may be would be appreciated.

If you are measuring a part manually using the jog box(as opposed to in dcc mode), pcdmis does not compensate for your probe diameter. (found out the hard way myself).

[bw_bob]

If you are measuring a part manually using the jog box(as opposed to in dcc mode), pcdmis does not compensate for your probe diameter. (found out the hard way myself).

If your probe comp box is checked it should compensate period...I would think ???

[Wes Cisco]

Two big ideas, first when is the last time your machine was calibrated? It could be that there was a crash and now the machine is out of square. The second idea is that your error map may not be turned on! What follows are some posts I copied from an old thread. The first post is Matt Hodeman and the second is Hilton Roberts. (I hope they will not mind my reposting this.)You should look at these settings. HTH


Here are the settings:
In the settings editor, go to the SHARPE32 section and expand it. There will be an option called CompensFileName and one called VolCompMethod.

If I remember right, the CompensFileName does not have to say COMP.DAT, it can be left alone (then why is it in there?) and the VolCompMethod needs a value of 1. Now, I have noticed that the value of 1 will change BY ITSELF to 14 after you cave the settings and re-open it. It does it every time. Why, I have no idea, but set it to 1.

I think these are all the settings you need. Another thought I had about your problem is that maybe, just maybe, your machine is actually RIGHT in the axis you were checking. It can happen that the machine is actually square in that direction and needed no 'tweak' to make it square. But, make sure these 2 settings are on and then try it again.


Matt,
I read your post about VolComp and it made me very curious. I checked my settings editor and sure enough it was set to 0. I got in touch with Doug Sjogren at Brown and Sharpe and he told me there are a couple of things that will cause a problem. If Volcomp=0, it means no Volcomp is being used. If Volcomp=1, the machine is looking for a Leitz controller. If you are running a Brown and Sharpe controller, Volcomp should be set to 14. If you look in Custprog.exe and skip past the passwords and look at the modules installed, you will see what controller is installed. To see if the comp map is being loaded, rename your comp.dat file to comp.old or something similar and then fire up PCDMIS. It should bring up a message that it cannot find the comp map and that Volcomp is NOT BEING USED.

Go back and rename comp.old to comp.dat and reopen PCDMIS and you should not see a message at all.

What really irritates me is that there was no warning that this value was being reset. B and S told me a mass mailing was supposed to have gone out telling users of the problem. This is just another case of too many programmers working on a section or module and the modules are not all playing nicely. Because I get my software updates from Seattle, the releases are supposed to be throughly vetted there BEFORE I get them. That obviously did not happen. To say I am throughly pissed is an understatement. This is the kind of crap that is leaving the door wide open for a software developer to come in with something new and different that works as advertised. The very least the software could have done is test for a controller and put a message on the startup window that there might be a conflict with compensation depending on the controller being loaded. This is just plain inexcusable

Hilton

[craiger_ny]

If you are measuring a part manually using the jog box(as opposed to in dcc mode), pcdmis does not compensate for your probe diameter. (found out the hard way myself).

Whoh there, I have great luck measuring in manual mode. Do you mean instead that vectoring can be tricky in manual (thereby throwing the compensation in the wrong direction)? I have never had PCDMIS ignore the probe diameter. I think I am reading your post wrong.

[Matthew D. Hoedeman]

OK, the thing is, when you are in manual mode, Pcdmis only comps in 1 direction and that direction will match a machine axis. In DCC mode, it will comp along the vector. If your manual points for the plane are NOT perpendicual to a machine axis, I would suggest that you do a DCC alignment after the manual one. In fact, I would suggest that you get in the habit of ALWAYS doing a DCC alignment after your manual one. There are way too many examples to give here that will point out the reasons for this.

One of the biggest, GREAT reasons for doing a DCC alignment after the manual is that it will let you be a little lazy. Say you set something up, align it, and start programming. Let's say you crash (it happens to all of us) and have to re-calibrate your probes. I would INSTANTLY re-do the alignment to ensure that your pick-up is still good. Now, do you want to go back around and manually measure all the alignment features again or would you rather let the machine do it for you?

[cmmguy]

First, the RS670 would not use the PCDMIS error mapping or at least it shouldn't. It would use the error map built in to the 670 controller.

Second, How long ago was the 670 upgraded? -was it before or after Hexagon bought sheffield (big difference on how the upgrade was done)

Third, probe comp should have nothing to do with concentricity or parallelism meausrements, these are not measurements of size.

However, machine calibration could have something to do with it and so could a uncorrected crash.

Probe cals could have a something to do with it.

Since you say the problem goes back over all of the different versions means that this has been going on for a while. I would suggest that measurement technique may have more to do with it than anything.

Can you hook back up the old Measuremax or DI system and check it with that - that would rule out the machine.

[craiger_ny]

OK, the thing is, when you are in manual mode, Pcdmis only comps in 1 direction and that direction will match a machine axis. In DCC mode, it will comp along the vector.

I beg to differ. In manual mode the point is projected in the direction of the vector you are manually traveling in at the time you take the hit. Try it. If you take the hit on a surface traveling in only one axis then it will comp in the vector that matches the axis you traveled in. Then take a hit traveling in all three axi on the same surface. It will project the point in the direction of machine travel. The comping in manual mode is only as good as you are able to vector manually. However, it will comp accordingly.

Craig

[Matthew D. Hoedeman]

I have tried it, on as close to a 45 angle as I could and I only got comp in 1 direction, 1 machine axis, not 2. I don't remember which version I was using at the time, but that IS what happened. Now, this is for single points, not a line or a plane, but a single point feature. It comped in 1 axis only.

[cmmguy]

Different machines with different controllers may behave differently with respect to comping points?

Is there a setting that can change that.

It seems crazy that a software would even TRY to comp a manual point in any vector other than normal to an axis. (craig, I am not saying that it doesn't)

[craiger_ny]

Different machines with different controllers may behave differently with respect to comping points?

Is there a setting that can change that.

It seems crazy that a software would even TRY to comp a manual point in any vector other than normal to an axis. (craig, I am not saying that it doesn't)

I know, Matt has me thinking right now so I dropped him a line. Shoot me a PM if you'd like to run an experiment because I may not be perceiving this correctly.

What I am saying in a nut shell is if you measure the granite. Then level and translate Z to it. Take a hit manually in the Z only (0,0,1). See what the point data is (X,Y,Z,I,J,K). Then manually travel in all three axis and hit the granite and compare it's X,Y,Z,I,J,K to the hit you took vectoring in Z only. I understand that once you level to Z that Z rail movement will not be perfect 0,0,1 because of machine comp but should be good enough for this experiment. I even did it without leveling and got similar results. I may be off base and thinking something totally different than what is going on here. Let me know because I'd hate to be giving out bad info here.

Craig

[jacyEd]

Wow you guys are fast. I go have a bite to eat and I come back to a ton of replies. Thank you very much for your responses. The problem I have seems to be extremely inconsistent. Sometimes I can simply realign the part and get a correct reading while other times it will just give random Z height readings all day long. We calibrate daily and shutdown every night as well. While we were still under our maintenance contract we had several people come and look at it but they would blame a bad tp200 or dirty read strip on the z axis. Cleaning and replacing has not fixed it unfortunately.
I can try and describe the scenario the best I can. the problem seems to stem from the manual alignment of the part before the program is run in DCC mode. With a few parts a face to face dimension is required along with concentricity's and parallelism and the original manual plane is used as the datum. I have yet to discover how to take manual points on the table and have them repeated in DCC mode without some sort of part alignment to keep the probe from crashing into the part or taking a point within a groove on the table the next time the same part is run. We seldom have the time to write a new program and when we do it can easily take an entire day just for 1.

[JamesMannes]

Can you explain your methodology for manual and DCC alignment? It may be something within your alignments that is causing you this grief.

[Matthew D. Hoedeman]

HEY CRAIG! (aka booger-boy!)

I just started a new program, no alignment. I move the machine at about a 30 degree angle to XY (no movement in the Z axis) and measured a point. No alignment, mind you! I hit done and the results were a point with a vector of 0,-1,0 that should have been a 30 degree angle. This is why I say ALWAYS do a DCC alignment, without an alignment, the machine will ONLY comp in 1 axis for any single point measured. The comp will not be right.