Part Versioning and Load Latest

[looslib]

This was also posted to the internal Siemens BBS.

I have my part versioning rules set for NX4 (4.0.3.3) as follows:
Part name format: ((([0-9]+-)([0-9]+))|([0-9]+))(-[A-Z])
Part name match: \1(-[A-Z])
Part name substitution: \1
Part name version substitution: \2
Version type: ALPHABETIC

When I do a Verify Dirs from the load options menu, I get conflicting reports on my file names:
Parts that comply to version format:
Versions of 806000.prt
806000-D.prt
806000-B.prt
Parts that do not comply to version format:
806000.prt

This leads to problems when I load an assembly that uses one of these versioned parts. NX does not load the latest version, even though that is checked in the load options. When I close the old part and do a Open Assembly As, I get a message stating that the file is already loaded.

The new part name is already in use.
"806000-D.prt" is a part family template of member "806094-B_dwg.prt"
"806000-D.prt" is a component of assembly "806094-B_dwg.prt"

This means that I have to close all files, load the latest rev part of the component, then reopen the upper assembly to get the updated component into the assembly.

Now for the kick!
If I have an assembly that already uses 806000-B, the load latest will load 806000-D as the component.

Where is the problem coming from, my versioning rules or the NX versioning code?
This has a major impact on maintaining the latest files on a project that we are having issues with. If we can get to work with loading the 806000-D file in place of the 806000, we will be very happy. When we first discussed this, we thought we may have to rename hundreds of the no-rev file names manually to be rev A (806000-A) files so load latest would work. Are we back to that option?
If we do the manual rename, we will also have to run ug_edit_part_names.exe on all of the no-rev drawing (806000-A_dwg) files to look for the renamed component file(s). We would let the uses manually update the assemblies, as where used is too slow and produces errors when I run it now.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[uwam2ie]

... this must not be a problem of your version rules.
I have something found...in NX5 that smells like your problem (managed mode TCeng2007)...
the data has been created in Nx2 - refiled reused cloned with replace - our normal workflow ... the replaced part is unreleased... but is still loaded into the memory. The reason is that still the mating conditions pointing to that unreleased part. We haven't noticed it since I've done an export out of the database - an opened it native - native this assembly member is missing but NX still want it a file not found message after load on the unrelased part. The strange thing is - that the mating columun still tell me that every thing is fully constrained. After editing ( native) the mating condition column in the ant is showing an question mark - cancel editing - fully constrain again??? Going into the proprties of the component on the information button - the question mark stays. - Doing the same in managed mode nothing is to find... I did a call at GTAC ... but no sucess / help .

 

[looslib]

Since when does rev C become a newer file than rev D?

When you use load latest with NX4.0.3.3.

This is from the syslog file: Mapped requested file 741000-D.prt to version 741000-C.prt

In the same directory I have:
741000-B
741000-C
741000-D
741000-E

I will open a GTAc call later!
This puts a serious wrinkle in our plans to use load latest to keep assemblies up to date with revised components.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[hudson888]

Are they all in the same directory on the system?

If not then your search options for recursive sub directories in NX don't work the way that you probably think. You have to structure your storage, your search options or both to ensure that the directory containing the latest files is searched first.

Using versioning rules the search will only distinguish between two versions of a file in the first directory where it encounters a file matching the core file name. Once it finds one it does not continue to interrogate directories underneath for the same core file name.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum

 

[looslib]

Yes, all files are in the same folder.

I have had this happen again with a different assembly. One file opened with rev B, rev C was the saved version and rev D and E were all in the same folder. Another file in this same folder opened the Rev B when it had been saved with the no rev file.

This is really confusing to me! I have been using UG/NX since v3.2 in 1987 and did the upgrade to V10 and all of its chnanges at the company I worked for at the time. I also did beta testing of V14-NX1 and learned a lot from that experience as you have closer support from the development side.



"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[hudson888]

You may need to try File>Options>Assembly Load Options and under the Part Versions section look for verify directories. This will generate a report that allows you to check whether the affected files are at least recognised by the versioning rules. Somebody may care to comment whether to confirm or deny if case matters in these things or indeed whether it is occasionally possible that networking between various unix and windows server workstation combinations may upset things.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum

 

[looslib]

I have run the Verify Directories rport against our Search Paths. All of the files I am seeing are showing up as valid part versions. Sample from the report:
Versions of 728523.prt
728523-B.prt
728523-C.prt
728523.prt
Versions of 728522.prt
728522-B.prt
728522-C.prt
728522-D.prt
728522.prt
Versions of 728521.prt
728521-B.prt
728521-C.prt
728521.prt
Versions of 728520.prt
728520-B.prt
728520-C.prt
728520-D.prt
728520.prt

Unigraphics Load Options Are :-
Load Options : Load from search directories:-
J:\Engcad\Sdata\UG PARTS... ntfs
J:\Engcad\Sdata\WIP... ntfs
J:\Engcad\Sdata\IN CHECK\... ntfs
J:\Engcad\Sdata\DA APPROVED\... ntfs
J:\Engcad\Sdata\UG RELEASED\... ntfs
Load Latest : Find the latest version of the partname
Load Components : Load all the component parts
Failure Option : Do not abort load on failure
Load Fully : Fully load all the component parts
Load Substitution : Allow Substitution
Reference Sets : Apply to all levels
Load Wave Data : Default load behaviour
Part family members : Regenerate missing members automatically

Loading "J:\Engcad\Sdata\UG RELEASED\728520-B.prt" which was saved in NX V2.0
Mapped requested file 729137.prt to version 729137-B.prt
Mapped requested file 729138.prt to version 729138.prt
Mapped requested file 728521-B.prt to version 728521-B.prt
Mapped requested file 728522-B.prt to version 728522-B.prt
Mapped requested file 702099.prt to version 702099.prt
Mapped requested file 728260.prt to version 728260-B.prt
Mapped requested file 90048.prt to version 90048.prt
Mapped requested file 495648.prt to version 495648-B.prt
Mapped requested file 90059.prt to version 90059.prt

Loading "J:\Engcad\Sdata\UG RELEASED\728520-D.prt" which was saved in NX V2.0
Mapped requested file 729137.prt to version 729137-B.prt
Mapped requested file 729138.prt to version 729138.prt
Mapped requested file 729174.prt to version 729174.prt
Mapped requested file 729165.prt to version 729165.prt
Mapped requested file 728521-C.prt to version 728521-B.prt
Mapped requested file 728522-D.prt to version 728522-B.prt
Mapped requested file 702099.prt to version 702099.prt
Mapped requested file 90059.prt to version 90059.prt
Mapped requested file 495648.prt to version 495648-B.prt
Mapped requested file 728260-B.prt to version 728260-B.prt
Mapped requested file 90048.prt to version 90048.prt

Both the rev B and rev D file were loaded with the same load option settings, closing all files between loads. I even tried to load them in new sessions of NX.

"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[hudson888]

It looks like it is getting the wrong version of 728522 where it defers to the lowest version rather then the highest. Is that the problem?

Should "Part name version substitution" be /1 rather than /2 at a guess I'm not sure.

Best Regards

Hudson

www.jamb.com.au

Nil Desperandum illegitimi non carborundum

 

[looslib]

Yes, it does defer to the oldest, not latest, but not on all files. That is the confusing part.
I will try it with /1 for the substitution, but I think that gave me errors before, which may have been corrected by a chnage to the rules. That is the only tyhing I have not changed yet in my testing.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[vrishraj]

Hi Ben
Is Load Latest problem solved, I also face the same problem after changing all these options still it loads wrongly(some older version and some newer version using NX5). Please share the result



Raj
NX 5.0.6

 

[looslib]

Yes we got it solved but I am away for the day and don't have the settings with me. I will post them tomorrow. It involved using different Part Name Version Substitution positions.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[looslib]

These are the rules that worked:
part_name_format :- (([0-9]+-)|([0-9]+))(-([A-HJ-NPRT-Y]{0,2})|)
part_name_match :- \1(-([A-HJ-NPRT-Y]{0,2})|)
part_name_substitution :- \1
version_substitution :- \2\3
version_type :- alphanumeric



"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli

 

[vrishraj]

Hi Ben,

Thanks for sharing, those settings works great for me.

Raj
NX 5.0.6