Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
-
Congratulations waross on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
how to run a .dfa file in NX
- Thread starter Kavith
- Start date
TaylorAnderson
Mechanical
Kavith --
Pardon the length here... This is from a document I wrote about 13 years ago, updated for NX (as opposed to UG.)
It's a little bit KF-centric (which is probably good for your immediate purposes) but extends into deployment of traditional NX Open API applications as well.
Hope this helps:
--------------------
When using a customized application, there are several files that may be necessary to execute the application. These may include:
[pre].DFA Knowledge Fusion rules definition files (Design File ASCII)
.PRT “Compiled” Knowledge Fusion rules definition files
.DLL Pre-compiled NX Open API application (Windows platforms)
.SO Pre-compiled NX Open API application (UNIX platforms)
.DLG UI Styler dialog files
.TBR Toolbar definition files
.MEN Menuscript (pull-down menu customization) files
.BMP Bitmap images used on toolbar icons or in dialogs
.UBM Bitmap palettes used in toolbar icons or in dialogs
.MDB Microsoft Access database files
.TXT, .CSV, .DAT, etc. Other data files that may be used by the custom application[/pre]
The NX session must be told where to look for some combination of these files. There are four basic mechanisms for telling NX where to look for a custom application:
[ol 1]
[li]For Knowledge Fusion applications only, a user can set a search path using the DFA Manager dialog and adding a New Directory to the list of Search Directories:
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-07-21_DFA_Manager.png[/URL])
While this method is undoubtedly the best for a development environment (because it allows rapid reloading of DFA files that may be changing frequently while being developed, without restarting NX) it is not the best deployment method for a production application.
This method requires every user to manually go to the dialog and add the path to the DFA files. In a large deployment, this requirement is particularly undesirable. Additionally, while this method will find and use both ui_comp user interface definitions and older UI Styler dialog files (DLG) correctly, it does not automatically recognize bitmaps that may be needed to render dialogs. In summary, this method is useful when used used in conjunction with either method 2 or method 3 as part of a more dynamic development environment.
NOTE: This method cannot be used to deploy NX Open API applications.
[/li]
[li]Every time a NX session is initiated, NX looks at three particular environment variables as potential locations for customization files. Customizations recognized by this structure might include Knowledge Fusion applications, NX Open API applications, custom toolbars, and pull-down menu customizations. These environment variables are: UGII_USER_DIR, UGII_SITE_DIR, and UGII_VENDOR_DIR. Inside each of these folders, NX is looking for any of the following sub-folders:
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://tbaimages.com/forums/2016-07-21_application_folders.png[/URL])
When DFA and DLG files are placed in the dfa sub-folder, they are recognized automatically as NX is started. Similarly, BMP, UBM, TBR, MEN, and DLL files placed appropriately in the application and startup folders will be automatically recognized and used as needed at NX startup time.
Conventions and correct locations for each file type are described in the NX API documentation here:
This approach provides full access to all needed data types, and provides automatic startup functionality for new toolbars and menu options, but is not scalable beyond a handful of applications. Files for multiple applications can be put in a common set of folders under a UGII_SITE_DIR, for example, but the management of more than a handful of applications in this manner quickly becomes unwieldy.
NOTE: When an application is deployed this way, NX will register any Knowledge Fusion classes as "System" classes, which will block the ability to dynamically reload the DFA files using the DFA manager, as in the first method. Thus, you'll need to choose one or the other. The first method is clearly better for development, and these other three methods are clearly better for deployment, after development has been completed.
[/li]
[li]The third (and recommended) way to have applications automatically recognized and registered is to use the UGII_CUSTOM_DIRECTORY_FILE environment variable to point to a custom_dirs.dat file. This file is a simple text file containing paths to any number of folders, as follows:
Each folder listed in this file is treated as though it were individually referenced by any of the UGII_USER_DIR, UGII_SITE_DIR, or UGII_VENDOR_DIR environment variables. There is no stated limit on the number of applications that can be registered using this method, thus providing the scalability missing in approach 2 above.
You can see more on this approach in the NX API docs here:
The UGII_CUSTOM_DIRECTORY_FILE can be set either in the ugii_env.dat file during NX startup, or by executing a DOS batch file to set the environment variable and then start Unigraphics. In general, the batch file approach has proved to be more deployable because this batch file can be located on a shared network drive (along with custom application code) and used to set environment variables and then start a locally installed NX session. This allows system administrators to edit the custom_dirs.dat file and startup batch files in one place, rather than requiring changes at every installation.
A sample startup batch file is included here:
This file will set up paths to any site-wide applications first, add a path for any user-specific applications next, and then start NX from the local installation, using the UGII_ROOT_DIR environment variable created at installation.
[/li]
[li]The fourth method involves zipping up the application package (the folder structure above) into one archive file, and then using Teamcenter to serve the zipped application package. This one is a little more involved, and I don't have the time to write up the details just now. But it's described in the NX API documentation here:
[/li]
[/ol]
--------------------
But for someone just getting started, I'd recommend #1 and #3 as the two modes you should use the most.
Again, my apologies for the length, but does that help?
Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Product Engineering Software
Siemens Product Lifecycle Management Software Inc.
(Phoenix, Arizona)
Pardon the length here... This is from a document I wrote about 13 years ago, updated for NX (as opposed to UG.)
It's a little bit KF-centric (which is probably good for your immediate purposes) but extends into deployment of traditional NX Open API applications as well.
Hope this helps:
--------------------
When using a customized application, there are several files that may be necessary to execute the application. These may include:
[pre].DFA Knowledge Fusion rules definition files (Design File ASCII)
.PRT “Compiled” Knowledge Fusion rules definition files
.DLL Pre-compiled NX Open API application (Windows platforms)
.SO Pre-compiled NX Open API application (UNIX platforms)
.DLG UI Styler dialog files
.TBR Toolbar definition files
.MEN Menuscript (pull-down menu customization) files
.BMP Bitmap images used on toolbar icons or in dialogs
.UBM Bitmap palettes used in toolbar icons or in dialogs
.MDB Microsoft Access database files
.TXT, .CSV, .DAT, etc. Other data files that may be used by the custom application[/pre]
The NX session must be told where to look for some combination of these files. There are four basic mechanisms for telling NX where to look for a custom application:
[ol 1]
[li]For Knowledge Fusion applications only, a user can set a search path using the DFA Manager dialog and adding a New Directory to the list of Search Directories:
While this method is undoubtedly the best for a development environment (because it allows rapid reloading of DFA files that may be changing frequently while being developed, without restarting NX) it is not the best deployment method for a production application.
This method requires every user to manually go to the dialog and add the path to the DFA files. In a large deployment, this requirement is particularly undesirable. Additionally, while this method will find and use both ui_comp user interface definitions and older UI Styler dialog files (DLG) correctly, it does not automatically recognize bitmaps that may be needed to render dialogs. In summary, this method is useful when used used in conjunction with either method 2 or method 3 as part of a more dynamic development environment.
NOTE: This method cannot be used to deploy NX Open API applications.
[/li]
[li]Every time a NX session is initiated, NX looks at three particular environment variables as potential locations for customization files. Customizations recognized by this structure might include Knowledge Fusion applications, NX Open API applications, custom toolbars, and pull-down menu customizations. These environment variables are: UGII_USER_DIR, UGII_SITE_DIR, and UGII_VENDOR_DIR. Inside each of these folders, NX is looking for any of the following sub-folders:
When DFA and DLG files are placed in the dfa sub-folder, they are recognized automatically as NX is started. Similarly, BMP, UBM, TBR, MEN, and DLL files placed appropriately in the application and startup folders will be automatically recognized and used as needed at NX startup time.
Conventions and correct locations for each file type are described in the NX API documentation here:
This approach provides full access to all needed data types, and provides automatic startup functionality for new toolbars and menu options, but is not scalable beyond a handful of applications. Files for multiple applications can be put in a common set of folders under a UGII_SITE_DIR, for example, but the management of more than a handful of applications in this manner quickly becomes unwieldy.
NOTE: When an application is deployed this way, NX will register any Knowledge Fusion classes as "System" classes, which will block the ability to dynamically reload the DFA files using the DFA manager, as in the first method. Thus, you'll need to choose one or the other. The first method is clearly better for development, and these other three methods are clearly better for deployment, after development has been completed.
[/li]
[li]The third (and recommended) way to have applications automatically recognized and registered is to use the UGII_CUSTOM_DIRECTORY_FILE environment variable to point to a custom_dirs.dat file. This file is a simple text file containing paths to any number of folders, as follows:
Code:
##### ACME Beam generator #####
U:\NX\KF\beam_generator
##### ACME Struts Generator #####
U:\NX\KF\struts_generator
##### ACME Strut Fixture Generator #####
U:\NX\KF\strut_fixture_generator
##### ACME Optical Lens Generator #####
U:\NX\KF\lens_generator
# A "#" symbol at the beginning of a line indicates a comment.
# White space lines are allowed.
# All other lines are treated as a path.
# ...and ACME is used here only to indicate
# a hypothetical company name. :-)Each folder listed in this file is treated as though it were individually referenced by any of the UGII_USER_DIR, UGII_SITE_DIR, or UGII_VENDOR_DIR environment variables. There is no stated limit on the number of applications that can be registered using this method, thus providing the scalability missing in approach 2 above.
You can see more on this approach in the NX API docs here:
The UGII_CUSTOM_DIRECTORY_FILE can be set either in the ugii_env.dat file during NX startup, or by executing a DOS batch file to set the environment variable and then start Unigraphics. In general, the batch file approach has proved to be more deployable because this batch file can be located on a shared network drive (along with custom application code) and used to set environment variables and then start a locally installed NX session. This allows system administrators to edit the custom_dirs.dat file and startup batch files in one place, rather than requiring changes at every installation.
A sample startup batch file is included here:
Code:
rem ## Looks for the list of ACME-specific UG customizations
set UGII_CUSTOM_DIRECTORY_FILE=ACME_custom_dirs.dat
rem ## Looks for the list of user-specific UG customizations
rem set UGII_USER_DIR=%HOME_DRIVE%\%HOME_PATH%
start "NX" "%UGII_ROOT_DIR%\"ugraf.exe %*This file will set up paths to any site-wide applications first, add a path for any user-specific applications next, and then start NX from the local installation, using the UGII_ROOT_DIR environment variable created at installation.
[/li]
[li]The fourth method involves zipping up the application package (the folder structure above) into one archive file, and then using Teamcenter to serve the zipped application package. This one is a little more involved, and I don't have the time to write up the details just now.
But it's described in the NX API documentation here: [/li]
[/ol]
--------------------
But for someone just getting started, I'd recommend #1 and #3 as the two modes you should use the most.
Again, my apologies for the length, but does that help?
Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Product Engineering Software
Siemens Product Lifecycle Management Software Inc.
(Phoenix, Arizona)
- Thread starter
- #3
TaylorAnderson
Mechanical
Sounds good!
Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Product Engineering Software
Siemens Product Lifecycle Management Software Inc.
(Phoenix, Arizona)
Taylor Anderson
NX Product Manager, Knowledge Reuse and NX Design
Product Engineering Software
Siemens Product Lifecycle Management Software Inc.
(Phoenix, Arizona)
- Status
Similar threads
- Locked
- Question
