Jump to content
Private Messaging is activated - check "How to" on how to disable it ×

Two machines, One program?


---
 Share

Recommended Posts

Hi everyone,

Is there a way to set up a program that currently runs using a VAST XXT head and make a separate configuration within the same file to allow it to run on a fixed head Vast XT?

Management would like to better utilize the machines we have and have asked that programs be made available to run on both machine types. While making a separate copy would be the easiest way to achieve that, they would prefer to maintain just one program (for future revision changes and updates). Setting aside the differences in probing systems and pathing, is this even feasible within Calypso? Would I need something like PCM to achieve this?

Any ideas are greatly appreciated.

Link to comment
Share on other sites

If you need to adjust speeds and probes, then defining new strategy is only option ( instead of duplicating program )

image.png.f0bc6523d0d674c0db7bdcbfba0a1965.png

Link to comment
Share on other sites

Please sign in to view this quote.

Please sign in to view this username.

Not feasible, and if it were feasible, would be a nightmare to accomplish. I would push back on management and ask how often are they expecting revisions?

Link to comment
Share on other sites

Please sign in to view this quote.

Martin, what prompts Calypso to use one strategy over another? I'm curious if there is a parameter that would allow you to select different machine numbers and utilize the given strategy based on that. 

Link to comment
Share on other sites

Please sign in to view this quote.

It should be selectable in start parameters ( same like characteristic selection or maximum speed ).

With PCM it should be doable while you get version of head ( if it can be obtained ), otherwise i am not sure if it can be driven with protocol header or formula inside.

Link to comment
Share on other sites

Please sign in to view this quote.

This is exactly what I was looking to achieve. Thanks for the responses, guys!

Link to comment
Share on other sites

I worked briefly at an aerospace shop that had 3 IDENTICAL B&S Global machines, and 1 that was ALMOST identical. They TRIED to run "common" programs, but spent more time working out the bugs than just putting each program on each machine and editing for that specific unit.

Corporate THOUGHT that having 'similar' machines would save a LOT of money, yet unforeseen issues kept ruining that dream. For instance, did you know that every calibration ball is unique? Somebody didn't, calibration balls got moved around, then one day we realized none of the machine calibrations for at least a month were valid, and we had to re-inspect EVERYTHING from the previous month...

Link to comment
Share on other sites

One thing to remember, as well, if this is a program that will live on the network, it is important to set the saving location of the actual data to your local C drive in extras>settings>environment under the paths tab. If you don't do that, we sometimes see freezing and additional odd things, especially if two machines are running the program at the same time.

https://portal.zeiss.com/knowledge-base?id=552028

Link to comment
Share on other sites

😇 Moin,

The only possibility, in my opinion, would be if the stylus systems and stylus on both CMMs had the same name.

Link to comment
Share on other sites

Hello Donald,

with PCM this can be done easily, you can define variables for stylus-systems, probe-number/name, speed. Without PCM, Christian is right, I guess.

Link to comment
Share on other sites

This can be done without anything fancy... No PCM no multiple strategies required. Yes... there are times where all that helps, and I do recommend learning them  but not required to get started.

I do this every single day of my programming.

33 CMMs

2 Contura's with XT

4 GageMax with XT

2 Eclipse with XXT

2 Eclipse with RDS and Renishaw Touch trigger probing

20 DuraMax with XXT

I have the EXACT same programs on all of those machines WITHOUT PCM or Multiple Strategies EXCEPT the RDS machines, for those I use PCM to make it work.

Standardize all your program system names and loading methods across all of your machines, I have a naming system based on the size of the ruby ignoring the length ( Star Port 5 is a 5mm rubies), it's a lot of work but you'll look like a hero after. I did this to thousands of programs.

Write the programs for your LEAST capable machine. In this case, an XXT machine. Do all your settings, speeds, etc for the XXT limitations. That means loop the base alignments, follow the cookbook, leave scanning optimization activated.

Copy that program directly to the XT machine with no changes and run it.  The XT machine would have the same Star Port 5 except most likely much physically longer in all directions, longer is probably okay.

Yes this means you will be scanning slower than the XT is capable of because you wrote the program for XXT, this is a cost of doing this and is basically required to keep good correlation between the machines. When you get advanced and want to delve into PCM and multiple strategies I advise a lot of caution. If you increase the speed or change the point density because XT can scan faster you will create hard to find correlation problems due to the strategy being different on top of the Sensor technology being different. It is sometimes surprising how a slight change to a strategy or filter/outlier can affect your results.

If you do this well, you will be impressed at just how well a DuraMax in another building will correlate to a Contura in the lab.

 

Editing: Yes, you can do this using PCM to handle different Stylus System names and skip my Step #1, but going that route will be a headache forever. Standardize everything you can first.

Edited
Link to comment
Share on other sites

Please sign in to view this quote.

Some customers require a type-2 Gauge R&R be done if a program is run on a different CMM.

Link to comment
Share on other sites

Please sign in to view this quote.

A Programmer should be going through an exercise like that regardless of the customer requirement if you're going to attempt this. There's a lot to get wrong on there. Even the exact same program can give surprisingly different results just due to how the CMM will filter data differently due to the sensor types.

That's why I caution so heavily against using the Multiple strategies until you understand how the different CMMs will affect results with the exact same strategies AND ruby sizes. Mechanical filtering due to different ruby sizes is not something to ignore.

Edited
Link to comment
Share on other sites

I transferred a program from a Contura G2 to an O-inspect 543 and it would not pass a type-2 on the O-inspect. Same XXT/styli size/configuration as the Contura.

Link to comment
Share on other sites

Please sign in to view this username.

 if you meant strategies, then i was posting about it and

Please sign in to view this username.

posted KB link 😉

Link to comment
Share on other sites

The XXT was the same on both. The styli configurations and size were the same on both.

The only difference is Contura vs O-inspect. I would think that those differences should be negligible.

I failed to add that it did pass a type-1 GRR <10%

Edited
Link to comment
Share on other sites

Contura is a bridge type machine the O-Inspect is a class all itself essentially. I'm not entirely surprised that they would struggle to correlate well enough to pass a proper GR&R, but that doesn't mean they can't. It sounds like an interesting challenge. 

But, If I can make a 18 year old shop floor DuraMax that we dropped a stack of bins on correlate beautify with our best Contura with XT, I'm sure those two machines could as well. It's just going to take a lot of legwork to first find out why they aren't, possibly even service calls. There's a million reasons why two machines might give different answers that have nothing to do with the program.

 

Link to comment
Share on other sites

The fact that it passed type-1, and not a type-2 makes me think that it might be more operator error than anything else. Right now, it's on the back burner.

Link to comment
Share on other sites

 Share

×
×
  • Create New...