Posts Tagged ‘batch’

Model Check batch file

Tuesday, October 27th, 2009

Saving this for my reference - A batch file that I used to run ModelCheck outside of Pro/E.

It creates a list of the files (parts.lst) in a directory. The list is progressive, starting with .prt, then .asm, and finally .drw.

It deletes the original (*.1) files (from the backup) so I know there’s no reason to check them in or add them back to my workspace.

The %1 is for a shortcut startup directory.

Some optional ideas are commented out, like the purge at the end.

cd /d %1
echo modelcheck_enabled yes > config.pro
if exist parts.lst del parts.lst
dir *.prt.* *.asm.* *.drw.* /b > parts.lst
set path=d:\ptc\wf2\bin;d:\batch
pause
call modelcheck.bat pro25.bat -f parts.lst
pause
rem c:\windows\system32\notepad.exe std.out
rem cleanup.bat %1
rem del *.prt.1 *.asm.1 *.drw.1 *.frm.* trail.txt.* config.pro mc_run*
rem purge

Things you might do differently:

  • Copy a different config.pro into this directory. I never really bothered checking out the no_graphics option.
  • Open the error log (mc_err.log), but the std.out echoes all the changes made during the run.
  • Open the .html results?
  • Purge and copy all *.prt.*, *.asm.*, and *.drw.* files to a clean directory.

Once again, I’m reminded how nice it is to have a decent text editor like TextPad available on my context menu ready and willing to open any file type.

Pro/E Admin: updated startup script

Saturday, June 6th, 2009

Since I’ve started working on my own again, I’ve had a chance to update my startup script from long ago. Here’s what I’m trying to do:

  • Make a script that works for multiple versions and multiple clients
  • Create a simple directory structure for project management
  • Maximize script flexibility with system variables

Here’s how “prostart.bat” works:

  • Pro/E is installed in directories by version, e.g. D:\PTC\WF2, D:\PTC\WF3, D:\PTC\WF4
  • Pro/E startup commands correspond to version, e.g. WF2.bat, WF3.bat, WF4.bat
  • The Windows shortcut supplies values to three variables: $VERSION, $CONFIG, $PROJECT
  • Startup directories vary by project and provide last level of config control
  • A startup trail file directs user to personal working directory
  • The config.pro uses  $CONFIG variable to provide flexibility for multiple projects and configs

Shortcut command line:
path_to_startup_batch_dir\prostart.bat version path_to_config_dir path_to_project_dir
Shortcut startup directory: blank because script changes directory to $PROJECT

Simple startup batch file:

@echo off

rem version will come from startup parameter, useful for multiple versions
set VERSION=%1

rem $CONFIG points to config files
set CONFIG=%2

rem $PROJECT is team working directory
set PROJECT=%3

rem Change startup directory according to shortcut, could add configs here
cd /d %PROJECT%

rem Create user work directory below project main directory
set WORKDIR=%PROJECT%\%USERNAME%

rem startup.txt is trail file to change working directory to $WORKDIR and instigate the open file dialogue box

call "D:\PTC\%1\bin\%1.bat" %CONFIG%\startup.txt

Simple startup trail file that still works in WF4:

!trail file version No. 1029
!Pro/ENGINEER TM Release 20.0 (c) 1988-98 by Parametric Technology Corporation All Rights Reserved.
~ Activate `main_dlg_cur` `main_dlg_cur`
~ Select `main_dlg_cur` `MenuBar1` \
1 `File`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `File.wd`
~ Select `main_dlg_cur` `MenuBar1` \
1 `File`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `File.psh_working_dir`
~ Update `file_open` `Inputname` \
`$WORKDIR`
~ Activate `file_open` `Open`
~ Activate `main_dlg_cur` `ProCmdModelOpen.file`

Also.

There’s a default config.pro setting: “search_path_file $PROJECT”. Each project can create a subdirectory of reference parts, multiple user subdirectories, and a vault.

And..

I still prefer to install Pro/E outside the Windows “Program Files” hierarchy. PTC may feel the need to comply with M$oft programming guidelines, but I remember PTC’s early problems with spaces in directory names. A side benefit of a separate install location (like D:\PTC) is that I don’t compete with permission enforcement for program directories, and I can do remote installs with simple scripts.

And…

You don’t need Pro/E on your Windows path. If you’re running multiple versions, it’s better that you don’t. If your life depends on “ptcstatus”, create a Windows shortcut.