Drawing format

Andrea,

you have to create a format with a table. You can assign parameters to those tables. If those parameters are defined in the part (assembly) they will be filled in automatically. If you use templates with pre-defined paramteres that are designated, then you will be prompted for those whenever you start a new part with that tmeplate. This should work for drawings also. Search the help for parameters and templates and something should come up.

Tom

Andrea Willans wrote:

This also works well when you have the same parameter defined within the model or assembly. The format will then NOT prompt you for the info, but take the values from the model referenced.

Secondly, by creating a custom BOM, you can have those parameters (part name, part number, vendor, etc...) populate the BOM automatically.

Dammerl wrote:

also, if you change your format you will be re-prompted for details. it is much better to have the parameters in the part or assembly. if this will require adding paramters to a lot of parts you have previously created, it is wothwhile creating a hotkey that creates paramters, perhaps with default vaues. If you are at the beginner stage of cerating formats, bom's etc, it will be worth learning how to do this, as it is possible that you will realise in a month or two that you need to add new parameters to your parts/ assy's. i don't use wildfire at the moment, so someone else will have to detail that

cheers Craig

There is a config.pro option for 2001 called new_parameter_ui that will list parameters in the part or assembly in the Wildfire type scheme vs the nested menu picks required normally.

On my formats, I created a table. In each cell of the table I entered parameters. If the parameter is in capital letters (&DRAWN_BY), the user is prompted for input. If the parameter is in lower case (&scale), there is no prompt, and the system parameter is used.

Scott

"Scott" wrote in message news: snipped-for-privacy@corp.supernews.com... : On my formats, I created a table. In each cell of the table I entered : parameters. If the parameter is in capital letters (&DRAWN_BY), the user is : prompted for input. If the parameter is in lower case (&scale), there is no : prompt, and the system parameter is used. : Thanks, Scott, for pointing out a couple things, not so far covered:

First, that it doesn't matter how or where you create parameters, and Pro/e has about a half dozen ways, none of them will show the parameter value in a drawing or format table without preceding the parameter name with the ampersand sign. This is just about the whole trick to using parameters in drawings/formats.

Second, that in a case sensitive operating system, like Unix, &scale or &SCALE or &Scale or &sCale, etc. are all different parameters. And, yes, only the lower case one is recognized by the operating system as the system parameter. This applies to the other system parameters, such as &current_sheet, &dwg_name, &todays_date, etc., as well. While it may be preferable to distinguish user parameters from system ones by using upper case letters, there is no inherent significance to parameters with names that are capitalized. They do not automatically request user input, for example. They may do so, in format tables that contain such user parameters, *when no value* has been assigned to the parameter, either in part, assembly or drawing mode. Most Pro/e users who commented already in this thread favored creating parameters in parts and assemblies. It may seem more convenient to use the centralized title block or BOM to enter parameter information, but there are dangers to this method too, the first being that type declaration is by obscure rules and informal methods when filling in title block/bom parameters, even if you are highly aware of what's going on. And most users have no idea of how parameter types are decided when entering tb/bom information. They just know, for example, that they wanted an integer for a department number and now it, mysteriously, has a decimal point and trailing zeros or they try to modify the value and for some reason, they need to enclose the number in quotation marks for the value to be accepted. An MRP system can be horribly screwed up by this. So I'd agree with the others: create the parameters in the parts/assemblies, in fact, load up the start part with them and get people to fill them in when they first create a part from the default start part. These parameters have a type deliberately declared, which can always be checked with 'Tools>Parameters'.

That brings me to the last point, namely, Andrea's original question ~ prompted parameter filling. Dammerl suggested that designating the parameters when they are created will result in being prompted for values when the template/start part is used to create a new part. It is necessary, but not sufficient, to designate parameters. On the page where you fill in the file name, there's a box labelled 'Use default template' which, by default, is checked. You have to uncheck this box, then select a template name from you start part directory. When the template is selected, all the designated parameters will display in the area below with an input line to the right. The input line will be blank, if you set up the parameters with no value assigned, or it will show the place holder values you entered. Since parameters are designated primarily to make them searchable in a PDM system, you may have default, constant parameters that you don't want changed and don't want to give people ready access to. You should set those parameters' Access to locked. The parameters will still appear in the start part's input list, but changing the value will have no effect.

Another way to prompt for parameter values is to use Pro/PROGRAM. When used in conjunction with the start part (which we will assume already has parameters that don't require prompting), the start part can be used with the 'Use default template' box checked, then get parameters for input from Pro/PROGRAM. This is set up with 'Tools>Program'. Between the two lines that say INPUT/END INPUT, you should enter a parameter name followed by a type declaration (string, number, yes/no). On the next line, place inside quotes, some prompt text. Keep going like this, entering all the parameters and prompts you want to have input. When you save the program, it will ask you if you want to incorporate into model. Answer yes and select 'current values'. Save the template file and erase from memory. If you now use this template in conjunction with the 'Use default template' box checked, you will have to first select 'Edit>Regenerate' to activate the program, then select 'Enter' from the menu manager which will start the prompts for values. With this method, and no values assigned to parameters, you can not just hit enter to get rid of the irritating request for input. I registers an error and stubbornly insists on legitimate input.

Some limitations on the method using Pro/PROGRAM: * 'Tools>Parameters' can not directly remove parameters, this must be done with Pro/PROGRAM, deleting the lines in the Input section, then the parameters/values may be deleted from the part with 'Tools>Parameters'. * Pro/PROGRAM does not recognize the parameter type of 'Integer', only 'Number' which is the real number type. I suppose they figure if you are going to use the parameter for calculations, a real number will do and if not, then a string will do. * A general constraint in parameter management is the fact that their type, once set, can not be changed, even if no value is assigned to the parameter. You will get an error if you try to manually change the type in the Input section. * Most parameter types created through an assignment statement, e.g., height=25, will be string, even if quote marks are not used. The only way, in an assignment, to insure that it is assigned a number type, is to use a decimal,

25.0 instead of 25. This is why, when an integer value is needed, the parameter must be created using 'Tools>Parameters'. * Real number parameters pick up the value from num_digits when created. When it is necessary to limit the number of digits to display, the parameter may be followed by a decimal value in brackets indicating the number of decimal places, e.g. [.2], following &total_height, to show the value with two places.

David Janes