Z height issue

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Z height issue

    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.

  • #2
    Does it only happen for those 2 dims. A little more info
    sigpic.....Its called golf because all the other 4 letter words were taken

    Comment


    • #3
      Originally posted by 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.
      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).
      sigpicDF

      The "NEW AND IMPROVED" Golden Rule!

      Comment


      • #4
        Originally posted by dfiola66
        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 ???
        sigpic.....Its called golf because all the other 4 letter words were taken

        Comment


        • #5
          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

          sigpic"Hated by Many, Loved by Few" _ A.B. - Stone brewery

          Comment


          • #6
            Originally posted by dfiola66
            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.
            <internet bumper sticker goes here>

            Comment


            • #7
              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?
              sigpic
              Originally posted by AndersI
              I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

              Comment


              • #8
                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.
                Links to my utilities for PCDMIS

                Comment


                • #9
                  Originally posted by 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.
                  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
                  <internet bumper sticker goes here>

                  Comment


                  • #10
                    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.
                    sigpic
                    Originally posted by AndersI
                    I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

                    Comment


                    • #11
                      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)
                      Links to my utilities for PCDMIS

                      Comment


                      • #12
                        Originally posted by 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)
                        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
                        <internet bumper sticker goes here>

                        Comment


                        • #13
                          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.

                          Comment


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

                            James Mannes

                            Comment


                            • #15
                              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.
                              sigpic
                              Originally posted by AndersI
                              I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

                              Comment

                              Related Topics

                              Collapse

                              • Clueless
                                Probe Triggering Issue
                                by Clueless
                                Morning kind Sirs

                                Have an issue that I have never come across before. My cmm is a B&S global. It is equipped with a PH10T head and...
                                08-02-2013, 09:46 AM
                              • R2ah1ze1l
                                Auto-circle issue
                                by R2ah1ze1l
                                We use V2013mr1 currently at our shop. Recently there have been accounts of the auto-circles not comping 1 of the hits. This is happening with circles...
                                09-22-2015, 02:25 PM
                              • nooners4
                                3 Intermittent Errors
                                by nooners4
                                Hi All,

                                I am having 3 recurring issues on a CMM.

                                1. Probehead Deflection.
                                2. No Probe Data Available.
                                3. Illegal...
                                10-17-2017, 07:08 AM
                              • jacyEd
                                RS-670 TP200b problems
                                by jacyEd
                                We have been using a TP-200 with out RS-670 running 3.7 MR3. The probe has pretty much reached the end of its lifespan and we attempted to replace it...
                                10-11-2006, 08:18 AM
                              • Amdgk
                                Alignment Issue
                                by Amdgk
                                Hi all

                                I am running version 2010 MR2 and having issues with my level. My manual alignment is fine but after i run my DCC alignment I get...
                                03-21-2011, 10:26 AM
                              Working...
                              X