Identify the parts in the assemblied

[HP_8721360]

I am using Creo Parametric Release 6.0 and Datecode6.0.6.0

How to identify any part used in what are the assemblies?
Basically, need to know, in how many assemblies, the specific part been used.

[kdirth]

At the top of the model tree, enter text (part number) in the filter and the tree will be reduced to anything the matches with the assembly structure.

[KenFarley]

Presumably you are not using Windchill. From what I understand this might be something that Windchill handles for you.

If you're trying to find all the assemblies in a Windows directory (and its subdirectories) that use a particular part or assembly, you can take advantage of the fact that a part name is stored in the assembly file. I wrote a batch program to find these kinds of things a while ago. It's run in a command window. It's not very fast, but has helped me a lot.

::
:: Builds a list in a file with the complete filenames of any assembly that
:: contains the expression specified.
::
:: Usage: whereused target [filename]
::                  target   = the target string to search for
::                  filename = optional output file name. If no name is
::                             provided, the default "results.txt" will
::                             be used.
::
:: Note: If the output file already exists, any new results are appended to
::       the end of the file. In this way, a batch file could be used to find
::       a number of parts and save all the results in a conglomerated report.
::
:: Author: Kenneth J. Farley
:: Date:   02 July 2015
::

@ECHO OFF

::
:: Check that at least one argument has been provided. If not, issue a
:: "Usage" message and exit.
::

if NOT "%~1"=="" (goto :doSearch)
echo Usage: whereused target [filename]
echo target   = the target string to search for
echo filename = optional output file name
exit /b

::
:: Do the initial setup stuff for the run.
:: * Save the input string to a variable.
:: * Write the search string and some delimiter characters to the results file.
:: * Trigger a search of all subdirectories.
::

:doSearch
set strSrch=%1
set "fileRes=%CD%\results.txt"
if NOT "%~2"=="" (set "fileRes=%CD%\%2")
echo Saving to "%fileRes%"
if NOT exist %fileRes%  echo. > "%fileRes%"
echo ------ %strSrch% ---------------- >> "%fileRes%"
echo. >> "%fileRes%"
for /r /d %%d in ("*") do call :doDir "%%d"
echo. >> "%fileRes%"
exit /b

::
:: Using the directory stack, changes to the target directory. Checks to see
:: if there are any assembly files and if so, processes them. Once done,
:: "pops" back to the original directory.
::

:doDir
pushd %1
set dirName=%1
if exist *.asm.* (call :doCheck)
popd
exit /b

::
:: Performs the searching operation and outputs any positive results to the
:: output file.
::

:doCheck
echo Checking %dirName%
for /f %%a in ('findstr /I /M %strSrch% *.asm.*') do echo %dirName% : %%a >> "%fileRes%"
exit /b

Hopefully it'll be useful.

[mamobono]

good morning KenFarley,

Let me understand, is your batch file able to identify the assemblies in which a certain prt file is present?

if I have a windows folder where there are all my assemblies, (while the parts are in another folder and with the search path "creo" it connects them) and inside this folder I launch your batch file indicating a certain prt file, will a txt file be returned where the asm files that contain it are written?

is that so, can you confirm it for me?

If so, it's brilliant.

bye

[KenFarley]

How it works is I copy the batch file to the top directory of where I want to search. I run it with the necessary arguments: a "target" or string that will be searched for in the assemblies, and optionally a filename to store the results.

As it executes, it will look in the directory you started in, then all the subdirectories of that directory. The results file will list the full path to any assemblies it finds the "target" in. This can take a long time if you have a lot of directories. Also, I usually try to do a "purge" on all the directories so there's only one version of each assembly.

[StephenW]

Creo part files do not contain any information about what assemblies they are used in. I suppose the exception to this is if a part has some sort of reference to the assembly (parent-child type reference).

Windchill keeps full track of where parts are used, if you are using it. 

[Dale_Rosema]

This is how I find them, but I get some false positives:

I click on the cmd window and then type:

whereused partnamehere (where partnamehere is the file name that you are checking - i.e. 1201_1003 for 1201_1003.prt or .asm

At the end it opens up a .txt file and I check each file to verify where the part is used in the file. This bring in all upper level assemblies all the way to the top level.

Tedious, but has helped me a lot. Especially when obsoleting a part.

No windchill.

[mamobono]

Thanks for the replies.

KenFarley
Dale_Rosema

So it works within "creo" and you have to launch the .bach file in the cmd window, which is placed in the folder containing the asm files.
From your example,
whereused is the name of the batch file, and after the > sign is the name of the prt file to search for.

The batch uses the CAD program to read the existing components within the asm files. Now I understand why you say it could be a long process.

Final question: does it work on all versions of "creo" or "wildfire"?
Hi

[KenFarley]

It's a batch file. It has nothing to do with any versions of Creo or Pro/Engineer or anything. It just searches files to find if they contain a string, which in the case of this particular situation, happens to be the name of a part or assembly.

False positives happen if in some instance in the past the target part/assembly was used in the assembly being looked at. The Creo file maintains a history of what was used in the past and so the file, though it is no longer using that particular component, still has text within it referring to the no longer used part/assembly.

[mamobono]

Thanks KenFarley
So it's even better than I thought.
I thought it wasn't possible to read inside the files, but you did it.

I'll try it as soon as I can.

You're great.

False positives are also a problem when using intralinks. In CAD, you need to clean the file of any links to deleted or replaced files with INFO/view references/dependencies and delete them from there.

[mamobono]

Hi,
I tried using the batch file in this ppp folder that I placed in c:\ and which I'm attaching.

The files are composed as follows:
asm01.asm = aa.prt + bb.prt
asm02.asm = aa.prt + cc.prt

I run the batch file from cmd
c:\ppp\whereused aa.prt

and I only get

results.txt

------ aa.prt ----------------

Where am I going wrong?

I want to clarify that this is just out of curiosity. At work, I've been using WF4 with intralink since 2009.

Thanks

[KenFarley]

Don't put the ".prt" on the search string. The text strings stored in the .asm file do not include an extension.

[mamobono]

Hi,
I also tried without prt, but to no avail.
whereused aa
results
------ aa ----------------

I also did another example with different names, but that also didn't work.

My files are generated by wf4 and then extracted by the intra3.4 management software, which, as you know, generates files with an additional .1 extension. Removing or leaving it makes no difference.
Have you tried the files I attached? Does it work for you?

I repeat, it's just out of curiosity; I don't need it.

Thanks

[MartinHanak]

---

@mamobono wrote:

Hi,
I also tried without prt, but to no avail.
whereused aa
results
------ aa ----------------

I also did another example with different names, but that also didn't work.

My files are generated by wf4 and then extracted by the intra3.4 management software, which, as you know, generates files with an additional .1 extension. Removing or leaving it makes no difference.
Have you tried the files I attached? Does it work for you?

I repeat, it's just out of curiosity; I don't need it.

Thanks

---

Hi,

whereused.bat batch file ignores current directory, therefore you have to place it 1 level up. See following picture.

Note 1: You have to enter upper case model names.

Note 2: I added .1 extension to names of assemblies. I thin numerical extension is mandatory.

Note 3: You test part names produce false positives because they are too short. See following picture.

[KenFarley]

Oh yeah, I guess I did skip the current directory. I'm always looking for things in a decades old directory structure so usually start at the top, where there are no files. Oh well.

[mamobono]

Thanks, MartinHanak
With your instructions, it works now.
As you said, there are problems with false positives.
I did a test, and for some reason, parts that have been replaced remain recorded in the files.
In any case, thanks to
MartinHanak
KenFarley
Dale_Rosema
Now my curiosity has been satisfied.

Thanks

[mamobono]

Hi,
I had an idea that should eliminate false positives due to replaced parts in the assembly, but I'm not a programmer.
It would be possible to set these conditions in the bat file:
Find part xxx
- If it's found, write the name of the asm file in results.txt and close the loop (like now)
- If it's not found when you find "#END_OF_P_OBJECT," close the loop.
I noticed that up to the line containing #END_OF_P_OBJECT, the old parts aren't there and appear afterward.
It would speed up the search by eliminating many lines to check and, perhaps, but we'll have to try, the false positives due to replaced parts in the asm.
Have a nice weekend!

[MartinHanak]

---

@mamobono wrote:

Hi,
I had an idea that should eliminate false positives due to replaced parts in the assembly, but I'm not a programmer.
It would be possible to set these conditions in the bat file:
Find part xxx
- If it's found, write the name of the asm file in results.txt and close the loop (like now)
- If it's not found when you find "#END_OF_P_OBJECT," close the loop.
I noticed that up to the line containing #END_OF_P_OBJECT, the old parts aren't there and appear afterward.
It would speed up the search by eliminating many lines to check and, perhaps, but we'll have to try, the false positives due to replaced parts in the asm.
Have a nice weekend!

---

Hi,

I created VBS script. You can test it.

• download zip file and unpack it into top directory
• open Command prompt window
  • change current directory ... example follows
    • cd /D E:\tmp\ppp\ppp
  • run script to display results in Command prompt window ... example follows
    • cscript//nologo whereused_MH.vbs PARTNAME
  • run script to write results into file ... example follows
    • cscript//nologo whereused_MH.vbs PARTNAME > PARTNAME.txt

See following picture.

Note: The script produces false positives, too. You can check them in Notepad.

[mamobono]

Thanks, Martin Hanák
I tried it. In the ppp example, it works, but when I transferred it to a more real-world example (hhh folder), unfortunately, it doesn't give me any results.
Maybe I'm doing something wrong.

The goal is to search for ac0891 or ac0151nf.
The correct search would be this:
ac0891 is contained in 251320 and 251320ws
ac0513nf is contained in 251320wsf12

But in 251320wsf12, traces of ac0891 remain (the part replaced with ac0513nf), and that's what we're trying to avoid by limiting the file scan to #END_OF_P_OBJECT.

I'm attaching the same example I used with bat (ff), which works but gives a false positive because it still finds the name of the replaced file in the asm file.

It's a game, so don't waste too much time.

Thanks, KenFarley. You're a programmer and know the dynamics of software.

Sorry for my English, but I use Google Translate.

[MartinHanak]

---

@mamobono wrote:

Thanks, Martin Hanák
I tried it. In the ppp example, it works, but when I transferred it to a more real-world example (hhh folder), unfortunately, it doesn't give me any results.
Maybe I'm doing something wrong.

The goal is to search for ac0891 or ac0151nf.
The correct search would be this:
ac0891 is contained in 251320 and 251320ws
ac0513nf is contained in 251320wsf12

But in 251320wsf12, traces of ac0891 remain (the part replaced with ac0513nf), and that's what we're trying to avoid by limiting the file scan to #END_OF_P_OBJECT.

I'm attaching the same example I used with bat (ff), which works but gives a false positive because it still finds the name of the replaced file in the asm file.

It's a game, so don't waste too much time.

Thanks, KenFarley. You're a programmer and know the dynamics of software.

Sorry for my English, but I use Google Translate.

---

Hi,

the explanation is very easy ... cscript//nologo whereused_MH.vbs PARTNAME notation means that the name of the part must be entered using uppercase letters ... see following picture.

I uploaded modified script whereused_MH2.vbs packed in whereused_MH2.zip.

whereused_MH2.vbs converts the name of the part to uppercase letters and you don't have to think about it anymore.

[mamobono]

Thanks Martin
Great, it works now.
The only difference with the BAT version is that the txt file is overwritten and the previous search is lost.
I think it's an excellent solution that could be useful for those who don't have a drawing management software.
We'll have to evaluate how long the search through many files will take.

Thanks Martin Hanák and also to Ken Farley, who started the process with his suggestion.

One last thing: I don't know how to rate "solution accepted."

[MartinHanak · Accepted solution]

---

@mamobono wrote:

Thanks Martin
Great, it works now.
The only difference with the BAT version is that the txt file is overwritten and the previous search is lost.
I think it's an excellent solution that could be useful for those who don't have a drawing management software.
We'll have to evaluate how long the search through many files will take.

Thanks Martin Hanák and also to Ken Farley, who started the process with his suggestion.

One last thing: I don't know how to rate "solution accepted."

---

Hi,

to prevent result file overriding you have two choices.

1.) using different result file names, eg.

cscript//nologo whereused_MH3.vbs PARTNAME_01 > PARTNAME_01.txt

cscript//nologo whereused_MH3.vbs PARTNAME_02 > PARTNAME_02.txt

2.] using >>

cscript//nologo whereused_MH3.vbs PARTNAME_01 >> result.txt

cscript//nologo whereused_MH3.vbs PARTNAME_02 >> result.txt

Note: I modified vbs file to insert the name of the searched part before the results. See attached whereused_MH3.vbs

[mamobono]

What can I say... now it's perfect.
Thanks, Martin

[mamobono]

Hi

Given this, and I think you (Martin) agree,
I assume no responsibility; anyone using these search files uses them at their own risk.
It is recommended that you perform searches on copies of the original ASM files.

This is always just an exercise/game and without any other purpose.
My curiosity pushes me further.
Theoretically, would it be possible to do a cross-reference search?
I mean, search only for assemblies that contain two defined parts or three defined parts? Or is that too complicated?

mamobono

[MartinHanak]

Hi,

searching for assemblies that contain two defined parts or three defined parts is not complicated. I will send you the script tomorrow.

[MartinHanak]

---

@mamobono wrote:

Hi

Given this, and I think you (Martin) agree,
I assume no responsibility; anyone using these search files uses them at their own risk.
It is recommended that you perform searches on copies of the original ASM files.

This is always just an exercise/game and without any other purpose.
My curiosity pushes me further.
Theoretically, would it be possible to do a cross-reference search?
I mean, search only for assemblies that contain two defined parts or three defined parts? Or is that too complicated?

mamobono

---

Hi,

yes ... anyone using my scripts uses them at their own risk.

New version of script attached.

Note: The number of arguments is not limited.

[mamobono]

What can I say, perfect,
thanks

[KenFarley]

The DOS batch commands being used are not parsing through the file line by line in any fashion that is controlled and can be stopped when some sort of condition is met. There is no looping structure in the file analysis - it provides a simple true/false result as to whether the target has been found within the file.

One can expect many many false positives if their file naming technique is using very short names or re-using the same names in different projects.