hexagon logo
Register Sign in
  • Replies 6 replies
  • Subscribers 221 subscribers
  • Views 169 views
  • Users 0 members are here
Options
Related

Best fit error on one CMM and not others

dwade
What I'm struggling with is a best fit error on one cylinder (DAT_N) on one CMM only and only when running through Inspect. I've ran the program on 4 CMMs all through Inspect (5.1) and on 3 I have no problems but on 1 CMM this error comes up. I can exit Inspect and run the program in Online mode and have no problems with this cylinder (DAT_N). I've deleted and rebuilt the probe, I've deleted the cylinder and recreated it and changed algorithms and stop / start angles and nothing I've done will let me run it through Inspect without the best fit error popping up. We are currently walking half way across the shop to run the part on 1 of the CMMs that we don't get the error. 

DAT_M =FEAT/CONTACT/CYLINDER/DEFAULT,CARTESIAN,IN,LEAST_SQR
THEO/<-37.9,-17.89,2.314>,<-1,0,0>,3.65,21.49
ACTL/<-37.9,-17.89,2.314>,<-1,0,0>,3.65,21.49
TARG/<-37.9,-17.89,2.314>,<-1,0,0>
START ANG=10,END ANG=115.5
ANGLE VEC=<0,0,1>
DIRECTION=CCW
SHOW FEATURE PARAMETERS=YES
VOID DETECTION=NO
REMEASURE=NO,USE THEO=YES
SURFACE=THICKNESS_NONE,0
MEASURE MODE=NOMINALS
RMEAS=NONE,NONE,NONE
AUTO WRIST=NO
CIRCULAR MOVES=STRAIGHT
GRAPHICAL ANALYSIS=NO
FEATURE LOCATOR=NO,NO,""
SHOW CONTACT PARAMETERS=YES
NUMHITS=5,NUMLEVELS=3,DEPTH=1,END OFFSET=10,PITCH=0
SAMPLE METHOD=SAMPLE_HITS
SAMPLE HITS=0,SPACER=0
AVOIDANCE MOVE=NO,DISTANCE=0
FIND HOLE=DISABLED,ONERROR=NO,READ POS=NO
SHOW HITS=NO
DATDEF/M,FEATURES=DAT_M,,
$$ NO,
=================================================
MOVE/POINT,NORMAL,<-50,-17.89,2.3>
MOVE/POINT,NORMAL,<-50,2,-15.23>
$$ NO,
=================================================
DAT_N =FEAT/CONTACT/CYLINDER/DEFAULT,CARTESIAN,IN,LEAST_SQR
THEO/<-37.9,2,-15.23>,<-1,0,0>,3.65,21.49
ACTL/<-37.9,2,-15.23>,<-1,0,0>,3.65,21.49
TARG/<-37.9,2,-15.23>,<-1,0,0>
START ANG=30,END ANG=150
ANGLE VEC=<0,0,1>
DIRECTION=CCW
SHOW FEATURE PARAMETERS=YES
VOID DETECTION=NO
REMEASURE=NO,USE THEO=YES
SURFACE=THICKNESS_NONE,0
MEASURE MODE=NOMINALS
RMEAS=NONE,NONE,NONE
AUTO WRIST=NO
CIRCULAR MOVES=STRAIGHT
GRAPHICAL ANALYSIS=NO
FEATURE LOCATOR=NO,NO,""
SHOW CONTACT PARAMETERS=YES
NUMHITS=5,NUMLEVELS=3,DEPTH=1,END OFFSET=10,PITCH=0
SAMPLE METHOD=SAMPLE_HITS
SAMPLE HITS=0,SPACER=0
AVOIDANCE MOVE=NO,DISTANCE=0
FIND HOLE=DISABLED,ONERROR=NO,READ POS=NO
SHOW HITS=NO
DATDEF/N,FEATURES=DAT_N,,


I'm open to any and all suggestions.

TIA,
Duane​​
  • Wild guess: Maybe someone remembers the Pentium Bug from the nineties… Not suggesting you still run a Pentium, but I know for a fact that some weird CPU errors still exist in modern processors. Maybe this is an error that occurs on a hardware level?
  • If you have a problem in one software out of two (Inspect and PCDLearn), and only on one computer out of four, it sounds to me as though this is not a PcDmis thing and is instead a PC/Windows thing.

    I'm with Paganini here.

    Is this the only program this happens on? If you make another program on a 1-2-3 block that otherwise mimics this, does it have the same problem? What if you keep adding data collection (the cmm hitting the part) so that the 1-2-3 block program has the same failing line of code with the same amount of measured data in program as the program that currently fails?

    Did you reboot the PC and the controller?

    If you are running profiles in Windows, can IT make you another profile and can you try it there?
    Can you run a repair in windows?

    Can you check the build versions of Inspect and PCDlearn to be 100% sure they are identical across all four machines? Not positive with Hex, but 5 is major version, .1 is minor, and then there are often (with software) .xxxx after that (whether they show you or not) or service packs, or build xxxx or whatever. Might all four be 5.1 but 3 machines have a different service pack in them? At least that would be easier to fix, match the build on the machine that fails to the three machines that work.
  • Wild guess: Maybe someone remembers the Pentium Bug from the nineties… Not suggesting you still run a Pentium, but I know for a fact that some weird CPU errors still exist in modern processors. Maybe this is an error that occurs on a hardware level?

    If you have a problem in one software out of two (Inspect and PCDLearn), and only on one computer out of four, it sounds to me as though this is not a PcDmis thing and is instead a PC/Windows thing.

    I'm with Paganini here.

    Is this the only program this happens on? If you make another program on a 1-2-3 block that otherwise mimics this, does it have the same problem? What if you keep adding data collection (the cmm hitting the part) so that the 1-2-3 block program has the same failing line of code with the same amount of measured data in program as the program that currently fails?

    Did you reboot the PC and the controller?

    If you are running profiles in Windows, can IT make you another profile and can you try it there?
    Can you run a repair in windows?

    Can you check the build versions of Inspect and PCDlearn to be 100% sure they are identical across all four machines? Not positive with Hex, but 5 is major version, .1 is minor, and then there are often (with software) .xxxx after that (whether they show you or not) or service packs, or build xxxx or whatever. Might all four be 5.1 but 3 machines have a different service pack in them? At least that would be easier to fix, match the build on the machine that fails to the three machines that work.

    Out of the 13 newer (less than 6 years old) CMMs we have on the floor this one CMM that is giving me fits is I believe around 3 years old. All of the PCs are Hexagon supplied Dells, all running the same all running the same release of the DEMON and Inspect, the same Win10Pro, same CPU, same RAM and same controllers. This cylinder is measured the same as 3 others on this part (2 on one side of the part and 2 on the opposite side) using the same number of hits and depths but this one hole is the only that gives me the best fit calculation error. What makes no sense to me is that I can run the program in Online mode and I do not get the error message but when I run it through Inspect I get the error.
  • So, you are saying that the specific CMM can run other parts and not have the problem AND it runs this part with no problems EXCEPT for ONE specific hole?
    If this is what you are saying, it has to be something with one of the involved features, the feature you are measuring (if the math is failing best-fit immediately after measurement) or the feature or one of the datums if it is failing best fit during True Position reporting. Remember that in GeoTol (if you are using it) datums and features are recalculated, at least if you are using ASME. I don't know about ISO and you are in metric, so maybe you are in ISO and that wouldn't apply.
    If this is immediately after the measurement, try dragging the middle level so that it is either near the top or bottom level rather than equally spaced. Five hits, three levels should be fine, but you have less than 180 degrees (unless I'm envisioning direction backwards, from 30 to 150 CCW is 120... I believe, but your axis is -1, so maybe I'm backwards), so stranger things have happened. Maybe with the way THAT machine moves, htis are a little more wonky and the point distribution doesn't resolve into any cylindrical shape. Changing hit pattern can help that.

    If you have this problem on hole 1 on part number A (every piece of part number A, hole 1 fails), and hole 7 on Part number B, etc. etc. I would think (making assumptions about the way Hex programs and operates here) there could be some issue in the way that data is passed between applications through the stack. That could be hardware or software. Most likely soft, as hardware issues on the stack usually give you a blue screen of death or just a hard reboot without asking.
  • So, you are saying that the specific CMM can run other parts and not have the problem AND it runs this part with no problems EXCEPT for ONE specific hole?
    If this is what you are saying, it has to be something with one of the involved features, the feature you are measuring (if the math is failing best-fit immediately after measurement) or the feature or one of the datums if it is failing best fit during True Position reporting. Remember that in GeoTol (if you are using it) datums and features are recalculated, at least if you are using ASME. I don't know about ISO and you are in metric, so maybe you are in ISO and that wouldn't apply.
     It runs just fine on the other CMMs running through Inspect and it runs just fine running in ONLINE mode on the same CMM as the error pops up when ran through Inspect. I'm using Xact for the tolerancing but tolerancing isn't done until near the end of the program.


    If this is immediately after the measurement, try dragging the middle level so that it is either near the top or bottom level rather than equally spaced. Five hits, three levels should be fine, but you have less than 180 degrees (unless I'm envisioning direction backwards, from 30 to 150 CCW is 120... I believe, but your axis is -1, so maybe I'm backwards), so stranger things have happened. Maybe with the way THAT machine moves, htis are a little more wonky and the point distribution doesn't resolve into any cylindrical shape. Changing hit pattern can help that.
    I've played with stop/start angles and moving the points in/out from the middle with no changes. We have another family of parts that we have been running for over 2 years with the same front end and the same hole measurements so this was a save as and the only change is we've not ran that family on this particular CMM as they moved production to another cell (the reason I ran this part/program in the old cell was to see of it happened there). Still gives not rhyme or reason why it runs just fine in ONLINE mode.

    If you have this problem on hole 1 on part number A (every piece of part number A, hole 1 fails), and hole 7 on Part number B, etc. etc. I would think (making assumptions about the way Hex programs and operates here) there could be some issue in the way that data is passed between applications through the stack. That could be hardware or software. Most likely soft, as hardware issues on the stack usually give you a blue screen of death or just a hard reboot without asking.
    Same hole (DAT_N) no matter what I do.
  • Can you make that feature FIXED_RAD for solution method and get it to work?

    If so, can you construct (yellow icon) a cylinder from that cylinder and set it to BF. Probably need to change manually to make it say DAT_N.HITS[1..DAT_N.NUMHITS]. Does the construction of the cylinder work then?
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement