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.

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.

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.

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!