CAD/CAM discussion forum > 3D CAD/CAM > long vxpaths file

long vxpaths file

    
  Subscribe Topic

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 1 of 5

 long vxpaths file
12-06-2008 08:42 . am   |   View his/her posts only
Dear Chris,

My vxpaths file is growing and growing. The reason lies in our filestructure.
We are a mould maker and have sorted the mould parts in subdirectories named after the mouldnumbers.
Now we need to be albe to use parts and assemblies from one mould into the other.
As long as we do not touch the vxpaths file, which is growing with every mould we sell by at least two lines, everything is OK.
I have discussed the growth with my reseller (4C)and he said that if we want to use a part that is used in an other mould this part should be copied into the assembly instead of just imported.
This would stop the vxpathsfile from growing.
I am testing this way at this moment and am not entirely happy with the result.

In my opinion there is another way to see the vxpaths file doesn't grow, namely to save the entire path to a file when it is imported.
4c told me that if VX would adopt this in its programm there will be other problems.
I don't quite understand this answer.

Now to the questions
1] Are there more users wo have problems with a too big vxpaths file?
2] Can you excplain the real reason of VX that the do not save the entire path to a file that is imported.

John

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 2 of 5

12-06-2008 09:45 . am   |   View his/her posts only
Hello John

The 4C suggestion is a work-around that avoids the problem you experienced, but it is not recommended as a long-term measure because you will eventually have a number of Assemblies that call-up essentially the same Part but without having any proper link back to the original design. Therefore, should the Part design be improved during work on the current project, the improved Part might get over-looked a year later when a new project requires it.

Before we look at strategy, let's answer your questions:

1) There are no other customers (worldwide) that have reported to me a vxpaths problem like yours.

2) The reasons that VX does not save (store is a better word) the entire, full path of a Part Object:

(a) The VX architecture: Every VX User benefits from the fact that a single VX file can contain a virtually
unlimited number of Objects (up to maximum file size, which in v13 is now 4GB read and write!),
Part Objects in particular. In order to deliver this, the VX files are special, VX sees them not as an
ordinary file but as a container (like a Windows folder). The fast access of Objects depends on VX's
ability to see the sea - all of the Objects pointed to in vxPaths. So, the motto of the architecture is
"The Object is King".

(b) It avoids a perennial problem that many competitor products suffer, which even their largest, richest
customers using expensive PDM systems have fallen foul of - moving files around that contain specific
file path records, and the moving of those referenced files themselves. For projects like yours, it
would be a disaster. I am not exaggerating the case here, I have been a first-hand witness of the problem.
One of the companies hit lost so much data (and therefore time and money), they blindly invested in
an add-on file management system that their Vendor assured them would be the remedy. Well, it wasn't,
it actually made matters worst.


File Management Strategy

I'm sure you will have different categories of "standard" Parts, ranging from literally standard norm items that are purchased, in-house standard items that are manufactured to Ramix specifications and in-house "seed" designs where the basic shape is modified to produce a bespoke item for a specific engineering case. In essence, all of these Part Object Models are Library items that could be used cross-project. It is how you manage these that determines how big the vxpaths file will grow.

If you can send me your chart defining your file management strategy, I can assess it for you. The little snippet of information you have mentioned here may well point to the source of the vxpaths problem, but I cannot comment without being able to examine the bigger picture.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 3 of 5

18-06-2008 09:33 . am   |   View his/her posts only
dear Chris,
I appologise for my slow responce, but I had to think everyting through.
Here is our filestructure.
I talked to Edwin(4C) this afternoon. He urged me to change my way of working with a growing vxpathsfile....
You might want to talk to him also, because he knows excactly how our comany works.

Enough said.

Filestructure.

Every mould ha sits own subdirectory.
Every daughter mould (interchangeable parts within a mother mould in order to make a different product in the same mould) should have its own subdirectory under the main mould.
Every part has a unique part number thus a unique filename.
Within a file well find several parts:
* 01 Part it selves
" 02 Pocket (solid part to use in an other part to fit this part into)
" 03 Subassy (Part 01 + bolts and nuts + sometimes other parts)
Part 03 helps me to buildup a large mouldassy very quickly
" 04 Sheet

We must be able to use every part/ pocket/ subassy in a completely different mould, thus in a completely different subdirectory.

Standard parts are stored in a separate place. The paths to these standard parts we always need.

Example.
I am working on 2 moulds (nr. 100 and 101) which are quite similar. Some parts and subassys of the two moulds are 100% the same.
As we are used to do in the work within 2D we use the parts which are constructed in mould 100 also in mould 101.
When we are working on mould 101 we need to have a path to mould 100.
Even to a part or parts that are constructed in a mould that was constructed a view years ago (eg. mould 50)

In order to read every file well within engineering (and not only on my machine) we run a small batch program that generates a vxpathsfile to every vxfile we have.
We copy this file around so everyone has the same vxpaths file.
You can imagine this file is beginning to get very big.

In a discussion we had with 4c we decided for the future not to go any deeper than the main mouldnrs subdirectory. (Although for overview reasons this would be better)
When VX would save the path to the file that a particular part is in, we dont need to have such a long vxpath file.
I tried to copy and rename files to use in the newer moulds, but this gives me a lot of work and can give mistakes during work. Lets not make working with VX too hard.

Greetings,

John

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 4 of 5

18-06-2008 09:58 . am   |   View his/her posts only

Hello John

I would appreciate a chart that defines your File Management Structure, File naming and Object naming - a picture paints a thousand words and you will probably be able to detect an inefficiency yourself.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 5 of 5

01-09-2008 02:55 . pm   |   View his/her posts only
Dear Chris,
It seemes very hard to make a scetsch of the structure, because there can be so many links across files.
This gave me thought enough about risks of losing data.
I discussed it with my reseller.
In my opinion the structure of VX looking for parts in files floating around a vxpathsfile still is not the right way to work.
It is beginning to be an issue of great concern to me.
It might be wise to discuss this issue personnally.
Somehow I will have to find a way and some time to set this up together with 4C.

Thanks sofar,

John
See also
X