PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Proto-guy
Regular User
Regular User
Posts: 17
Joined: Thu Jul 24, 2014 11:38 am

PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by Proto-guy » Thu Jul 24, 2014 12:14 pm

Here is the problem.

We have two machines running CMM Manager. While attempting to run a program on machine 1 that was created on machine 2, the "Get probe assembly" command was automatically replaced with another problem assembly from machine 2.

Ok, no problem right. You simply pull the probe.cfg file from machine 1 where the program was written, set-up the probe assembly the same, and run the program. Which is what I did. The program ran and I finished the work.

Now here is where it started getting sticky. After completing the run, and starting a program on machine 2, which it was created on, it recalled the probe.cfg file from machine 1 and automatically replaced the probe assembly with another from machine 1 probe.cfg. In this case, the technician who wrote this program was here and realized the probe recalled was not the correct one and knew what the correct one was. However, he is leaving the company. So, if the program recalls the probe.cfg from the last time the software was used (in this caseMachine 1), and the recalled probe assembly is not the one the program was written with, I have no way of knowing and am likely to crash the machine.

So, you would think you could just create the same probe, with same name, identical to the assembly in machine 1 that would match machine 2 and all would be well, right? Nope! I did that and the software still grabbed the wrong probe assembly automatically even though the correctly named probe assembly was now in the probe.cfg file on the current machine.

So, I called Nikon and they tell me that the program recalls the probes based on an index number and not the probe assembly name????? Why have a name at all if the program is going to recall by the index number instead of probe name?? The program should not change the probe assembly that has been called by the "get probe assy" command... PERIOD. If the probe.cfg in current use does not contain the probe file it needs the software should tell me and I will get the correct one for it. it should not change what it has been programmed to use, at least not without prompting to do so!!

Because the software changes the "Get probe assy." automatically, the potential for a crash because the program now has the wrong probe assembly, is great. It will occur!! Quite nice probe mangling feature for the unsuspecting CMM operator who is trying to run someone else program.

ragin1
Frequent User
Frequent User
Posts: 47
Joined: Fri Mar 15, 2013 8:28 am

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by ragin1 » Thu Jul 24, 2014 2:56 pm

Have you tried inserting, "Probe, Probe, Load Probe Assembly/Tip", into each program? Save the .cfg, and the .tip files on a network that both machines can reach, and ensure the proper .cfg/.tip file is inserted into each program that is shared between machines.

Incidentally, you do not need the exact same config to run a program. You need the same configuration with the called tips for a program to run properly.

Proto-guy
Regular User
Regular User
Posts: 17
Joined: Thu Jul 24, 2014 11:38 am

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by Proto-guy » Thu Jul 24, 2014 3:23 pm

Thanks for your reply.
I am not sure what "Probe, Probe, Load Probe Assembly/Tip" is.
Inserting this command, once I learn what it is, into hundreds of existing programs is not a good fix.

I have my own work-around to get the programs to run, which involves either reconstructing probe assemblies or sharing/copying the cfg. files across the network.

However, one slip on my part and I have the wrong probe file loaded into any given program because the indexes do not match. Going back and re-indexing all the probe.cfg files to match is also not a good fix because there are quite a number of them.

What I would like to see is the Program retain the probe assembly it was programmed with. The software should NOT be automatically changing the Load probe assembly command. It should prompt the programmer/operator with something like "Probe assy XYZ" is not available. Please load probe assy. XYZ". It could possibly suggest, with some type of pull down menu, the probe assy to be used. In this way the name which is what the programmer recognizes could be selected regardless of what index it is.

User avatar
mhochkins1
Nikon
Nikon
Posts: 253
Joined: Tue Mar 22, 2011 12:10 pm
Location: Linden, MI

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by mhochkins1 » Fri Jul 25, 2014 9:35 am

Usually, if a probe assembly on the machine is different than the probe assembly which created the project, you will receive a warning message at runtime.

The "index" is the number at which the probe is listed in the probe "builder" list. Probe Assembly 0 is actually number one and Probe Assembly 1 is actually number 2 etc..You will notice that by looking at the status bar at the bottom of the interface on the right side with the probe icon. Whichever probe is active will show the index number. Remember this when you are building and renaming your assemblies. Make sure they are listed in the same order as the other probe configurations that you are matching with.
Best Regards,
Mark Hochkins

Ralliartevo
Regular User
Regular User
Posts: 25
Joined: Tue Oct 22, 2013 12:32 pm

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by Ralliartevo » Fri Jul 25, 2014 10:02 am

I don't understand this. We cant do that. We have hundreds of programs. if the program is looking for a certain index and we rebuild it to another index then its still going to grab the wrong one in all the subsequent programs. It does not give us a warning that the wrong probe is there. The program was written on ANOTHER MACHINE that has different probe builds. ( we just started using the machines together) So when we bring it to a new machine it grabs whatever probe build is in the index that it was created in . For example, if probe build AJ1 is in my machines index 1 and he has an AJ1 in his machines index 3 and he writes a program using his index 3, when we bring the program to my machine it grabs whats in my index 3 automatically, without warning (instead of reading the name) which is a probe assembly that is 200 mm longer than the AJ1 assembly. Now what do you think is going to happen when we run this program. Im leaving this company soon and he will have no idea what probe build i used to write some of these programs. This is a huge potential for a very serious and expensive crash.

On another note why would probe assembly 0 be index 1 and so on . Its just like the points in a program. Why would you start with zero? point 1 should be point 1 just as probe assembly 1 should be index 1

User avatar
US_Helpdesk
Moderator
Moderator
Posts: 1087
Joined: Wed Feb 23, 2011 7:26 pm

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by US_Helpdesk » Fri Jul 25, 2014 10:08 am

ragin1 wrote:Have you tried inserting, "Probe, Probe, Load Probe Assembly/Tip", into each program?
This will resolve your issue if done right... You may have to "unify" the probe configurations between the two machines - i.e. 2mm x 2omm is probe 1, 3mm x 40mm is probe 2, etc.

The probe configuration between the two machines does have to be the same or at least very similar.
I've migrated to a new user account, see my other posts here

User avatar
mhochkins1
Nikon
Nikon
Posts: 253
Joined: Tue Mar 22, 2011 12:10 pm
Location: Linden, MI

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by mhochkins1 » Fri Jul 25, 2014 10:14 am

Starting with "0" as number 1 is a computer programming convention which CMM Manager uses. It really is not strange or uncommon in coding languages.
Best Regards,
Mark Hochkins

Ralliartevo
Regular User
Regular User
Posts: 25
Joined: Tue Oct 22, 2013 12:32 pm

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by Ralliartevo » Fri Jul 25, 2014 10:20 am

nfrost wrote:
ragin1 wrote:Have you tried inserting, "Probe, Probe, Load Probe Assembly/Tip", into each program?

Could someone give me an example or screen shot of this please.


But if we do this then what will happen to all the programs we already have written when they go to look for index1 and we change index1? is it going to still grab the wrong assembly
Last edited by Ralliartevo on Fri Jul 25, 2014 10:24 am, edited 2 times in total.

Ralliartevo
Regular User
Regular User
Posts: 25
Joined: Tue Oct 22, 2013 12:32 pm

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by Ralliartevo » Fri Jul 25, 2014 10:21 am

mhochkins1 wrote:Starting with "0" as number 1 is a computer programming convention which CMM Manager uses. It really is not strange or uncommon in coding languages.

Fair enough (but i still hate it :D )

User avatar
mhochkins1
Nikon
Nikon
Posts: 253
Joined: Tue Mar 22, 2011 12:10 pm
Location: Linden, MI

Re: PROBE CONFIGURATION PROBLEM BETWEEN TWO MACHINES

Post by mhochkins1 » Fri Jul 25, 2014 10:26 am

After you get the two machines set the same, Save the probes and tip files and use the "Load Probe Assembly/Tip" options as indicated below:
Load_Probe.JPG
You do not have the required permissions to view the files attached to this post.
Best Regards,
Mark Hochkins

Post Reply