Manufacturing UDFs: Reference group

[d-]

I have created a few UDFs to assist in programming hole drilling. They combine drilling, chamfering (actually just another drilling sequence with a spot drill), and tapping sequences. Depth is set using two planes (drilling depth and tap offset from bottom) controlled by variant dimensions. This also lets the depth for both the drilling and tapping be controlled in one place.

Usually they work great, reducing the whole process to a few clicks. Unfortunately, they are not all equal. Some of them occasionally refuse to go onto a model; the only indication I even tried something is a message in the log stating:

" Reference group is not present; group creation aborted."

This does not happen with all models, nor with all the UDFs, and doesn't seem to happen at all with some of the UDFs. The UDFs were created piecemeal over several different models (as needed). Both the models used to create the UDFs and the ones I'm trying to place them on do vary. We've gone through several versions of Pro/E, Wildfire, and Creo, and I doubt the base models have been rebuilt from scratch in the last ten years. We also get models that have been "updated" since the original was built, leading to lots of fun regarding holes that should be the same having dimensions differ by anything from 0.00005" to 0.005."

Is this error a problem in the UDF? If so, would it have been something wrong with the model used to create the UDF in the first place? Or just a mistake during creation? Is the problem caused by something in the model I'm trying to apply the UDF to?

On a side note, I'm currently in Creo 3.0 M010. Most of the UDFs were created with Creo 2.0 M070, and the models would have been made/updated with either a later version of Creo 2.0 or Creo 3.0 M010.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[gkoch]

David,

I checked our database and found only one reference to the error message in a Pro/TOOLKIT / J-Link related case a couple of years ago.

When you say "assist in programming hole drilling" you mean NC programming, not using one of our program APIs, right?

In the reported case it was that they had to explicitly get the model with the GetCurrentModel() function to make sure the program mode was correct (MFG and not assembly) for the UDF.

For your case this could mean that the UDF and the active model are not properly fitting together. I don't assume you have still some old "part MFG" models in use (they must have become legacy 15 years ago), but maybe it makes a difference, whether being in MFG mode or having the MFG assembly opened in a window?

Gunter

[d-]

Gunter,

I did mean NC programming. I have looked at the APIs, having a little computer programming background, but it seemed the only way to create NC steps with the APIs was placing UDFs, so I have not done much with the APIs yet. Now, if we could change the tool, parameters, etc, an industrious user could automate quite a bit.

All of the MFGs in question are made by copying one of a set of MFGs with most of the NC programming that is common for the part already done into the job folder. The major parts of each job have standard file names, so just copying in the MFG makes it use the PRT from that folder, no updating or part replacing needed. As far as I can tell, they are all MFG assemblies created (or at least most recently updated) with Creo 2.0 M020.

I had not considered that the differences between the MFGs could be the issue. I will have to do some testing and see if all the UDFs fail on some of the MFGs... though I suppose if some of the UDFs were created with different MFGs that could affect it as well.

Was the UDF system built in PRO/TOOLKIT?

[gkoch]

The case contained not much details on what they tried to achieve with the program. It had been opened because they did implement UDFs programmatically (by J-Link) and then got this error.

As I understood, they were trying with J-Link, but would have been ready to switch to Pro/TOOLKIT, if there had been a solution J-Link did not offer.

There was not even a feedback in the case, whether they have been successful after they got the suggestion to be careful whether they choose assembly or manufacturing.