3.73 Stability?

[Wingman]

Every time I read about 3.73 people hail it as the most stable PC DMIS around. I mention 3.73 to the Support Techs and they always say 'Good Choice'. In light of that I realize I am a vast minority here but it does not seem stable to me. There are a couple probles that I would really like to know if anyone else has had it and found a way to fix it. Hopefully it is just some switch somehere.
Anyway:
1) CTRL E does not behave as it did in 3.72. In 3.72 I could count on program values updating when I stepped on a feature etc. Now it does not work. I have to execute large sections of code to get 'accurate' results. I actually have to run entire programs to get results I 'think' I can trust. In 3.73 I routinely get features showing someplace out in space for actuals even though the niominals and the targets are correct and the CMM finds the point just fine. It just says the point is somwehre else. What gives here?
2) Same goes with alignment commands. ALl I had to do before was F9 and alignment command as I was stepping through a program. Once I Accepted it the Alignment was created. That doesn't work correctly either. Half the time it doesn't update (probably cecause the features aren't updated but I am not sure why).
Other weird problems that have caused me to question the reliability and accuracy of the measurements in 3.73. I used to think the issues were only present because I was using programs originally written in 3.72; however, this is no longer the case. Programs written from scratch in 3.73 also behave oddly.

Any insight, help, etc will be appreciated and I will drink a beer in toast!!

Bill

[Matthew D. Hoedeman]

Every time I read about 3.73 people hail it as the most stable PC DMIS around. I mention 3.73 to the Support Techs and they always say 'Good Choice'. In light of that I realize I am a vast minority here but it does not seem stable to me. There are a couple probles that I would really like to know if anyone else has had it and found a way to fix it. Hopefully it is just some switch somehere.
Anyway:
1) CTRL E does not behave as it did in 3.72. In 3.72 I could count on program values updating when I stepped on a feature etc. Now it does not work. I have to execute large sections of code to get 'accurate' results. I actually have to run entire programs to get results I 'think' I can trust. In 3.73 I routinely get features showing someplace out in space for actuals even though the niominals and the targets are correct and the CMM finds the point just fine. It just says the point is somwehre else. What gives here?
2) Same goes with alignment commands. ALl I had to do before was F9 and alignment command as I was stepping through a program. Once I Accepted it the Alignment was created. That doesn't work correctly either. Half the time it doesn't update (probably cecause the features aren't updated but I am not sure why).
Other weird problems that have caused me to question the reliability and accuracy of the measurements in 3.73. I used to think the issues were only present because I was using programs originally written in 3.72; however, this is no longer the case. Programs written from scratch in 3.73 also behave oddly.

Any insight, help, etc will be appreciated and I will drink a beer in toast!!

Bill

Well, I went from V3.5-0 to V3.7-3, so I can't help you on transitions from V3.7-2 to 3.7-3. HOWEVER, I can tell you, that in V3.5, you could place your cursor on the DIMENSION for a feature and hit CTRL-E and it would execute the feature and give you the new dimension. Now, in V37-3, you can NOT place the cursor on the dimension and do a CTRL-E, only on the feature. Since you are not executing the dimension, it does not update. Yeah, it sucks. Just re-type in the LAST number/letter in the feature ID for the dimension and it will update the dimension. IE, place the cursor on the last character in the ID, type it in, hit delete to remove the existing character and it will update.

[Wingman]

Hmm

Seems there is another issue. I used to be able to 'add angles' within a program if I need a new tip orientation. Now I cannot do that. I have to stop and get out of the program or go back to reset alignment to add a probe angle. Anybody see this. WTF?

[Cumofo]

Sorry Wingman, but I think you are really out there on some of your stuff. I've never had any of your problems. I fact I can change whole tip profile and still run the program just fine. Where do you save your probe files to? Do you have admin rights on your computer?



g

[Wingman]

Admin rights = yes. Probe files in the PCDMSW Directory.

I could change tip profiles before too and program ran just fine. The thing is, we went to 4.2 and back to 3.73 FROM 3.72. The issues I am having I really don't know are associated with 3.73. They could be associated with new people on off shifts. Frustrating. Just fishing to see if anybody else experiences the same crap. If it is an off shift doing something I want to know what they could be doing.

Just having some really screwed up alignment / Zero shifts and some weird measurements. Example, I just added a new angle and calibrated it. When I looked at the offsets they were WAY out in left field somewhere. Values like 500x, 2213y,-650z (that is a heck of a long tip). So for some reason zero was changed?

I recalibrated tip 1 and said OK to Sphere Move / Zero Change and it came back to norm.

Still, there ARE the issues with 3.73 that are a pain. I just measured a 76mm diameter and the CMM said 69mm (Automeasure). I paged up a few lines in code to the nearest probe change and did a CTRL U and the DIA was fine.

I measure an Auto point at say X 0, Y 34, Z 0 (X Minus Plane). Measures fine but reports the location as X 273.5, Y -27.65, Z 400.2. I do a pattern copy to get a set of points around the ID and the CMM findes them all OK it just says the actuals are somewhere else. Again, I scroll up a few lines and do a CTRL U and everything is fine. Just really weird, dumb crap. It was going fine until I created a temp alignment to a cylinder and all help broke loose.

It is like it measures OK in the alignment that I am in but for some reson the actuals are sent to the former alignment?

[Cumofo]

Sounds like you don't use a fixed cali-sphere, and the night shift guys always use a different location. (has the sphere been moved, or has the cmm zero point been changed?)


G

[Wingman]

Nah, it is fixed. I did catch one thing a while back. The nightshift guy would crash out and when he HOMED the machine he would move it as soon as DCC came back to the stick. Homing was not complete yet and the Zero point got lost somehow. I didn't know this was even possible until he did it and 'showed' me what he did. I didn't even think PC DMIS would LET you move the probe until it was done homing.
Anyway, I am sure it all boils down to something simple. Remember, I have only been running this machine for a year now but it has run without any of these weird issues until the last month when we installed 4.2 and came back at the same time as we gained a third shift operator. I mean, PC DMIS has it quirks for sure, but nothing totally fubar like this.

When you say has the sphere been moved I understand that. When you say has the machine zero point been changed I don't fully understand that. I can move the sphere, but I cannot move the machine zero point, can I. Isn't that pretty much fixed by marks on the scale or limit switches or something?

[Matthew D. Hoedeman]

Nah, it is fixed. I did catch one thing a while back. The nightshift guy would crash out and when he HOMED the machine he would move it as soon as DCC came back to the stick. Homing was not complete yet and the Zero point got lost somehow. I didn't know this was even possible until he did it and 'showed' me what he did. I didn't even think PC DMIS would LET you move the probe until it was done homing.
Anyway, I am sure it all boils down to something simple. Remember, I have only been running this machine for a year now but it has run without any of these weird issues until the last month when we installed 4.2 and came back at the same time as we gained a third shift operator. I mean, PC DMIS has it quirks for sure, but nothing totally fubar like this.

When you say has the sphere been moved I understand that. When you say has the machine zero point been changed I don't fully understand that. I can move the sphere, but I cannot move the machine zero point, can I. Isn't that pretty much fixed by marks on the scale or limit switches or something?

It will never repeat to the exact same location when it homes, mine uses a magnet next to the scales to trip a switch in the reader head, so it will never repeat to the exact micron, or even to the exact 0.001", so when you home, you must re-align anything and you must tell it the cal-sphere is in a new location, even if you didn't move it, and you must do complete calibrations, you can't just calibrate 'some' of the tips.

[Wingman]

We are talking about between 300 to 2,000 milimeters.

[cmmguy]

We are talking about between 300 to 2,000 milimeters.

Is this on the Sheffield?

[Wingman]

Is this on the Sheffield?

yep

[cmmguy]

yep

Make sure that you restart the controller and the machine(PCDMIS) does a complete rehome(it is three iterations). If another software(ie MMax) homes the machine out and then you start PCDMIS, the homing precess never occurs for PCDMIS and all of your numbers will be off that relate to the home position - such as master ball location, machine reference frames, etc...

The homing is pretty accurate(of course not perfect) but close enough to find the master ball each time or to find a fixture in machine coordinates.

The homing process is not so important going from PCDMIS back to MMax.

[Wingman]

Well, this particular issue arose when I was in the middle of a program and needed another angle. Per usual I did the following:

1) Opened the calibration toolbox
2) Defined the new angle
3) Calibrated using the correct sphere and answering NO to the question "has the sphere moved or machine zero changed"

The machine found the sphere just fine and calibrated the new angle and all seemed well.
Wen I called the tip in the program the XYZ location of the sphere immediately changed by 5 or 6 HUNDRED millimeters.
I checked the calibration offset and sure enough that probe was offset 5 or 6 hundred millimeters.

Seems like the machine coordinate system and the part coordinate system are criss crossing and bleeding onto each other some way. This also shows up when I use a temporary alignment some times. The feature actuals sometimes show up where they shouldn't. It appears they are relative to a previous alignment. By this I mean:
Lets say my alignment moved 100,0,0 and was rotated to some angle. Now I measure a feature at 10,10,10 in the new alignment. The feature gets found and measured OK but the actuals say the feature is in the neighborhodd of -90, 10, 10 (the -90 appears to be derived from the real location (10) minus the alignment offset (100) = -90. In reality the alignments are more complex and include variable angles etc but the actuals physically show up in the proximity as described above. Like the alignments are corrupting each other or something. This all goes away if I back up through the program and run several likes of code before the feature (including the feature). 3.72 did not behave this way. Each feature added successively to a program reported correctly, temp alignments were no issue, tip angles could be added on the fly etc.

[craiger_ny]

I too have issues with new probes with 3.7 MR3. I can't say it is with newly defined tips within an existing file though. But I can say when I create a new probe file my coordinate system for that probe (all tips) is way off but not as much as you, mine is usually 0.75 inches (I am guessing). I should try defining a new tip in an existing file to see if I have the same issue. Not that it will help I have never gotten to the bottom of it.

[#2#]

Well, this particular issue arose when I was in the middle of a program and needed another angle. Per usual I did the following:

1) Opened the calibration toolbox
2) Defined the new angle
3) Calibrated using the correct sphere and answering NO to the question "has the sphere moved or machine zero changed"

The machine found the sphere just fine and calibrated the new angle and all seemed well.
Wen I called the tip in the program the XYZ location of the sphere immediately changed by 5 or 6 HUNDRED millimeters.
I checked the calibration offset and sure enough that probe was offset 5 or 6 hundred millimeters.

Odd, had you homed between the last time A0B0 was calibrated and when you calibrated the new angle? If you had, you should have answered 'yes' to the sphere moving. I don't think this is the problem you are experiencing but, this is a problem.

The following is in inches:
Lets say you calibrate A0B0 with the sphere at 1,1,-1 from home and then shut down the machine. Now, you bop in the next morning and start up your machine and home it. The machine will not home in exactly the same place. Lets say this morning it homes -.005,-.005,0 from where it homed yesterday. Now you go in and calibrate a new angle without calibrating A0B0 and answer 'no' to the sphere moving. The machine now thinks the sphere is still at 1,1,-1 from home when in reality it is 1.005,1.005,-1 from home. Now, take a hit with A0B0, rotate your head and take a hit in the same place same vector with your new angle. Dimension the distance between the two points in X and Y and you will get .005 and .005! Any hits you take with your new angle will be off .005 in x and y relative to your other angles.

That BTW is not a problem if the new angle is the ONLY angle you use in the program. If you use the new angle AND A0B0 you may be in trouble.

Also, BTW you could answer 'no' if you calibrate A0B0 and any other angles you use b/c then your hits will all have the same error from home no matter which angle you use. Since you don't dimension anything from the home position, the error is not important.