Dedicated Probe Files

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

  • Dedicated Probe Files

    Over time I've accumulated a number of probe builds unique to a given part (and only used for that part). Slot definitions for the tool changer take longer and qualification results (appended) get lengthy. I started creating probes for each program and storing them in the program folder ("search current directory first"). Each part inspection gets archived (*.prg, *.cad, *.pdf, *.prb, *.results, etc.) so I can always go back and pick up where I left off. So I'm left with the only probes in my \Probes\ directory being MASTER & UNLOAD. All the probe files used for a given part measurement are tucked away in the folder along with the *.prg that uses them. The small file size isn't an issue for our server. So far I haven't run into any issues. Are there any compelling reasons to have a generic probe file used by numerous inspection programs?
    "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." (Samuel Clemens)

  • #2
    I guess it could depend on the number of similar parts you measure in each batch - if every part is a one-off, with a separate probe file, there will probably be many unnecessary calibrations during a working week, while if you run batches of hundreds of similar parts, you save time by not calibrating tips you will not use this week...

    It's definitely a Good Thing(tm) to archive the probe files together with the program. More than once have we helped a customer rebuild probe files when they suddenly have to re-circulate some very old part program.
    AndersI
    SW support - Hexagon Metrology Nordic AB

    Comment


    • #3
      I only get one of a part at a time and don't have enough stylus holders to go around (only 9). My most common builds are 3x40 & 5x50 and you are right. By the end of the week I do end up repeating some calibrations. I like the idea of an inspection being self-contained and having all the needed resources at hand. On 2 occasions I had a community probe file go bad slowly and it took some work to track down the collateral damage. Just thought I'd try using private probes to see how it works out. Most likely I'll end up with a combination of both.
      "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." (Samuel Clemens)

      Comment


      • #4
        We used to have a separate probe file for every tool program (thousands), from single probe angles to probably a few 100 probe angles per file. We ended up with new hardware/software at some point and 're-thought' a lot of our processes --- probe files included --- and went to generic probe files. Now we have perhaps 15 probe files. As probe angles are needed for new programs, we add them to the particular generic probe file. BTW, as we open old programs to run, we replace the probe file with the generic probe file, so, over time, the individual probe files will go away. We've been doing this for ~4 years now and our most-used probe file is about 2/3 full, whereas some of our least-used probe files have only a few probe angles in them. We did it to save 'clutter' and (I suppose) disc space. I prefer this new way of doing things because it DOES reduce clutter - there are 15 probe files instead of 15,000. Disc space is incidental --- memory is so cheap, who cares? All our probe builds are fairly simple --- 50/100/200mm Extension, TP20, stylus. Our naming convention: A50MM_2X20 where 'A' represents the 50MM extension (PC-DMIS orders numbers differently so that 100 comes before 200, and both come before 50, so A=50mm, B=100mm, C=200mm) just to get the probe file names in order from shortest to longest extensions. We add the (redundant, I suppose) extension length, so you don't need to know the 'code'. And lastly is the stylus. If we were using stars, or even custom (funky) styli, we would have to consider those naming conventions, but it's not been an issue. Also, we qualify the probe ('MARK USED') before each new tool, or re-qualify the probe first thing in the morning if the tool was left on the CMM overnight. Yes, there is duplication in probe angle qualification with this philosophy, but we have simply accepted this as 'the cost of doing business'. Which do I prefer? I prefer less clutter, so the new way is the way to go for me. Your opinion may be very different. That's why they make chocolate and vanilla.

        Comment


        • #5
          Originally posted by fatso666 View Post
          ...went to generic probe files.
          One part I run has 13 dedicated probes (rotated star tips) to avoid a 2-sided inspection. Additional common probes are also used. Flipping the part over means taking the part outside the room so that 2 cranes can be used to invert the thing. Doing so means it has to soak overnight to acclimate on the CMM. For me, I prefer the overhead of these dedicated probes opposed to the effort needed to flip the part (and lost time). It also avoids having to ATTACH programs for certain dimensions (the ATTACH command leaves a lot to be desired). I probably have close to 100 probes dedicated to individual parts.

          One benefit of the private probe is that qualification results are saved in the active measurement folder (self-contained objective evidence). It also makes transporting the inspection (Online\Offline\Home) a bit easier along with probe/tip selection from the toolbar.

          One downside to a private probe is that if assigned to a tool changer slot, then the probe file relocated, I'm asked to manually remove the probe at a LOADPROBE. There's also the qualification redundancy you and AndersI mention.

          In the end it's just a matter of trade-offs. Priorities change. The lesser evil today might be preferred next month. You've tried both ways and know what works best for you. Clutter to me is having to sift through dozens of nonrelevant files to get to the few I'm interested in (really an issue when assigning tool slots). Sometimes annoyance drives a choice over efficiency.
          "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." (Samuel Clemens)

          Comment


          • #6
            Not sure if this helps, I have a Leitz LSPX1H with 9 port probe changer. Each slot I believe can hold up to 5 assignments, for a total of 45 different tips that could used. Of course, you have to manually swap them out, and in each routine, we have two comments for each tip used in a routine.
            First comment ( YES / NO ) informs the operator that a specific tip is required and where it should be in the probe changer and a picture of the probe build and picture of the location of the tip in the probe changer are embedded in the comment so they get the visual and verbal of what is needed and they choose YES or NO based on if the tip named is in the correct slot ( of course, the hope is that if the tip is not there, the operator will place the right tip in the right slot and click yes, ). If the operator selects NO that the tip is not loaded,( thanks to my dummy proof person ) a 2nd comment prompt opens telling the operator to place that specific tip in the specified slot. and then the program loops back to the first comment . This is set up for each tip in a routine.

            Also, we have found that hand loading a tip in the probe changer can lead to a tip not always being seated properly, after all the tips are verified loaded in the probe changer, the routine then picks up and replaces each tip in the probe changer used for the routine to ensure proper seating of the tips.

            Then our routines move to calibration of tips in the routine.

            If the routine is being run for the first time, the operator will go through all these steps, if it is not the first run on routine, then certain information is skipped as needed.

            We have 4 CMM's. ( 7107) We are growing and are finally getting around to protect mode, so we have been struggling with finding the best way to handle allowing operators to access everything in protect mode that they need.

            For all tip builds, all angles possible were created for each tip, this way, at any given time in program creation, a programmer can use any tip angle for any tip and know it will always be accessible to the operators when running a routine for calibration and use.

            We also created the ability to calibrate or not, all the tips in the routine. Using our offline seat, we created a calibration sphere tool for CMM 1 and named it CMM 1 and input the appropriate Calibration sphere tool information for CMM 1 tool. Opened each probe for calibration, selected CMM 1 for the tool, and closed the operation, Reopened the calibration operation and selected " use only tip angles in routine" and created a parameter set name and saved it. We did this for all tips so that all tips had CMM 1 as the tool assigned for calibration. Once all tips had CMM 1 tool saved for use, the probe files were copied and saved to a folder on the network that was named CMM 1. Then we went to CMM 1 and made sure the Cal sphere tool name was CMM 1. This way, once a week, as part of the PM, the operators can delete the current probe files on the hard drive and replace with untouched probe files that are on network and the probe files will recognize the correct tool for calibration and we do not need to get out of protect mode to make a quick change for the tool needed for calibration.
            This was repeated this for all 4 CMMs.
            Calibration results were set up so the results print out on the first part report. That gives the documented proof of what calibration was before starting the lot of parts. No need to keep a private probe file.

            The offline seat version does not have the option for calibration to select lower matrix. Although, it appears on the desktop PC with the CMM that we can create a parameter set name and save it with Lower matrix selected. Our master tip only has A0B0, but a tip angle has to be selected for lower matrix. Not sure if we can find a way to incorporate an option to the operator to perform a lower matrix. We know it should not be needed unless there was impact/crash...but it appears there are operator(s) that don't speak up when something crashes. So as part of the weekly PM, we wanted to incorporate mandatory Lower matrix. In fact, we are considering creating a PM routine that will move the bridge and Z arm to certain location to allow for cleaning of the scales and etc.... and adding operator inputs for performing all the needed PM steps as needed ( weekly, bi weekly, monthly, etc... ) and output an actual report as verification the PM was done, what steps were performed, and by whom.

            The only issue we have yet to find a solution for in protect mode, besides testing what we think will work for lower matrix, is Probe changer calibration.




            Last edited by baseballfan; 02-14-2017, 11:24 AM.

            Comment

            Related Topics

            Collapse

            Working...
            X