It is possible to populate 'multiple values' drop down from design tables?

[solid7]

3DX 2017x

I want to create a User Feature that has a drop down box, with pre-populated values. Great for start parts. I was thinking that it would be super simple to use a series of design tables for this. However, I've not come up with a good way to do this. The design table is immediately in conflict with the 'multiple values' aspect of the parameter that it's supposed to populate.

So can anyone tell me if you have a way to do this? Summary:

1) create a design table with all possible values
2) link the values in the design table, to the multi-valued parameter
3) expose the multi-valued parameter to the User Feature. (no custom variables - only admin defined)

Of course, I'm open to other suggestions. This was just my vision.

 

[LucasC]

Try creating a drop down list in a linked Excel sheet. Maybe you can update the table in V5 through that. It's been quite some time since Ive created one of these and I have to convert my Excel sheet to a notepad document to satisfy our PLM system. Otherwise Id give it a try myself. If it works you can just restrict who's allowed to do what to the excel sheet. It would be a lot easier to edit the Excel sheet also.


Also,

Usually on my design tables, I have several predefined configurations you can choose from and update the V5 assembly without changing any data in the table. maybe this works for you?

Example:

Config 1: A=3 b=2 c=1
Config 2: A=2 b=1 c=3
config 3: A=1 b=3 c=2

Edited to add a different idea:

I thought about it and maybe you can skip the design table completely and just make several parameters in the tree to control your values. You defiantly can make drop downs there and also have the power to create values based on formulas as you see fit.

When you create a new parameter, just select multiple values

You can also edit by right click or change a different existing parameter to multi-value also.

 

[solid7]

Getting the multiple values is the easy part. What I want, is to have the option to select from a list of multiple values upon instantiation. Since User Features are black boxed, this would prevent switching the configuration post-instantiation. Which makes perfect sense when you create parts from cut stock, and have no use case for re-using a part number.

 

[Little Cthulhu]

Hi.

I'm afraid what has been suggested in original post is not how design tables work. They allow to select a single set of values (a configuration row), not to associate these values with multi-string parameter nor retrieve all values of a single column of design table.

I would not aim for "configuration switching preventing" as in CATPart user can literally do whatever he wants (and should be able to). He can just instantiate another UDF with "wrong" configuration and replace old one in just a few clicks.
Due to this fact I would simply expose parameter that sets configuration row number to a user. If you still want pretty configuration names, a VB script can be called in instantiation reaction that would read design table and populate multi-string parameter with row "names". Another reaction bound to this parameter would actually change design table configuration.

However, I'd take a look at parametric part catalogs that provide a way to resolve all possible part configurations (based on design table) into a separate CATParts. That's an assembly-level approach, but it makes part configurations manageable and even brings some access rights management as you can easily mark all generated CATPart files as "read-only".
Again, it all makes sense when you do assembly design, not just design parts.

 

[solid7]

I have already published the configuration of the design table into my User Feature. No problem.

However, I disagree with you about just letting end users do whatever they want. When you add configuration control, from an engineering design perspective, it's perfectly valid to restrict what one can or cannot do, post release. And with the maturation of the Catia PLM product, some of this is already being done through business logic.

This is deeper than just "make some parts do some things". I have some smart parts that are generated to specific material specifications, driven by design table. The post-release restriction is one issue; I merely wanted a way to allow more flexible choosing of the black boxed instance, pre-instantiation. It doesn't appear as though I'm going to get that. But the restriction of the part update, post-release, is easy, and very do-able. I can, and will, restrict a part from that type of edition, post release. We have rules regarding part number changes for a reason, and there is no reason not to enforce them. Users who are free to do whatever they want, do whatever they want. Even when there are rules to follow.