Programmatically add tips to the probes list...

When you added the probe, did you calibrate it?

I can only think of one use case to actually want to do such a thing, and unless your probe qualification procedures are PERFECT, it would cause more problems than it would solve.
Namely, if you (or anyone else) restarts the controller and does NOT locate the qual sphere with a probe that previously was qualified on that sphere while saying that the sphere moved, the added tips, even qualified, will not relate to previously qualified tips.
This is where a "Master" tip comes in handy.
But it has to locate the sphere (qual and say yes it moved) EVERY SINGLE TIME the controller is restarted or someone actually moves the sphere.
The moment you don't do that, your tips stop relating to each other.

If the program is adding angles because you don't want to restrict how someone loads the part on the CMM (only reason I can think of to bother with doing this), how does it "know" if the sphere is located?

Are you only going to locate the sphere out of a program that ONLY quals the "Master" tip and then writes to an external file a 1 (standard boolean for yes), and have a script that sets the value of that file to 0 because it is watching the controller to determine if it has restarted (send query to it at some interval to watch the return)?

It seems like too much to me.

However, you have the code, it adds the tips, perhaps they are dumped if not qualified when added programmatically.

Or perhaps it writes to a different probe file that is a clone. I think this a lot less likely.

The probe dialogue is interacting with a probe file, and when you click "OK" it writes the changes to that file.

I'm not sure qualifying would do it, but I'm guessing your code is creating the change but never writing the probe file with the changes. You need to find a way to write changes to the probe file after adding the tip, would be my guess.
I think calibrating the tip would be more likely to do that than just adding a head rotation.

Not sure what you are trying to do, but I was able to successfully remove all the tip angles from the probe utilities for a specific build and add in only the ones I wanted. That part seemed to work pretty good, but I was getting sporadic behavior due to something else going on. Haven’t gotten a chance to come back to it yet. My intentions were to create an auto-calibration routine for my UI. Anyways, here’s how I did it.

CurrPrb = part.CurrentProbeName
MsgBox(CurrPrb)
MsgBox("Got the Probe file name")
probes = part.Probes
probes.Visible = True
probe = probes.Item(CurrPrb)
If probe.Dialog = True Then
MsgBox("probe dialog weeeeeeeeee")

probe.SelectAllTips()
Tips = probe.Tips
Tips.Remove(1)


Dim Replaced1 As String
Dim Replaced2 As String

textline = ""
If System.IO.File.Exists(file_name) = True Then
Dim objreader As New System.IO.StreamReader(file_name)

Do While objreader.Peek() <> -1
Replaced1 = "T1A"
Replaced2 = "B"

textline = textline & objreader.ReadLine() & vbNewLine
textline = Replace(textline, (Replaced1), "")
textline = Replace(textline, (Replaced2), ",")
'MsgBox(textline)
Dim Angle_A As String
Dim Angle_B As String
Angle_A = Split(textline, ",")(0)
Angle_B = Split(textline, ",")(1)
Tips.Add(Angle_A, Angle_B)

textline = ""


Loop
objreader.Close()
End If


probes.SaveChanges()
probes.Visible = False
part.EXECUTE()
part.Close()
End If
​

Hi,

Thanks for the reply. On a dual arm machine when you mirror a program the mirroring mangles all the tips in the mirrored program. The tips are easy to extract from the as shown part and mirror correctly in VB. We then want to 'inject' those extracted and mirrored tips back into the mirrored program, to correct the mangling, BUT it appears they have to exist in the tips list first. Thus we are looking for a way to added them into the tips list programmatically. Probe qualification for us is pretty robust because our 'master' sphere moves per design. Long story.

Thank you! I'll give this a whirl and report back.

That all makes a fair bit of sense.

Gagedude's line near the bottom, probes.savechanges(), would be my first guess on why you are losing info... if you don't already have it.

Have to remember the probe file is its own thing, it isn't part of the part program at all. I don't understand why he's getting "sporadic" behavior, but we are working on Windows with PcDmis, so I suppose that is something I should just expect lol.

Yes, I'm working on getting that implemented right now. Unfortunately, there is always some other emergent issue I have to attend to here. All I know is I want this application completed and out of my hair.

I appreciate everyone's input and ideas on this event. I was at my at the end of my rope. Thank you!

Works great so far in testing. I think the problem may now be solved. Thank you!!!

No problem! Happy to help!

Caemgen I am doing a lot more than what I posted . I am opening pcdmis and searching through a program for the probe build and all tip angles, deleting any duplicates , then writing those to a text file. Closing, then reopening pcdmis and reading in both the probe build and tip angles, then calibrating said tips. But the problem is the guy before me who set up everything when we converted from measure-max to pcdmis, made all probe builds machine unique. So for example on our Sheffield Endeavor CMM’s he called a probe, “1mm_with_extension”, but for our globals he called it “1mm_with_extension_adapter”. Then on our D8’s it’s called “1mm_with_extension_tip1”, because that head does not index. And now we have thousands and thousands of programs saved with these unique probe files So the challenge for making a one shoe fits all auto-calibration routine has become quite cumbersome. I have a text file on each CMM that I read in, then based on what machine the probe is being calibrated on , I need to input the correct probe builds or else my script will error out . So I think the sporadic behavior might be due to doing so much, opening/closing/re-opening the app, some kind of timing issue, or something else. I haven’t gotten a chance to test more. At first, I noticed multiple instances of pcdmis being opened, and I thought I fixed that because my application seems to work great when I run it on my offline seat. But, when I run it on the cmm it’s telling me an object is not declared for my “Currprb” string. So the string is empty which results in it bombing out because it has no probe file to add the tips into. And also I’m not the only one who has experienced weird behavior when dealing with the probe objects . I’ll keep tinkering whenever I get some free time. If I get it working properly I will share it with y’all!

Couldn't the Global Used within the Probe Utilities help with this? For example, the CMM's that use a Probe Changer I copy and paste all of the measurement routines that will be used on that particular CMM to a folder I created within the Hexagon folder. Then I will change the Set Search Path to that folder location for the Probe Directory. Then use the Global Used within the Probe Utilities to add the probe angles for each probe build in the probe rack. Once all of the probe angles are created, I have a script that is called from each measurement routine to save as the routine locally to a folder created by the script. Now I will use that folder to create all of the probe angles for the current measurement routines. The current measurement routines are the latest routines with the current template builds. When completed I will change the Set Search Path back to the required directories. For the Auto calibration routine, I use a routine template using trace fields to allow a user to add the probe builds names and number of probe racks. This allows one routine template to be used to create individual Auto Calibration routines for each CMM.