Take the value of the part number and put into an organized sequence

[armando_amarisNN969]

I just found out about this thing called ILogic and I'm impressed how useful it is!!

Can someone help me with this code

In our company we assign the numation of each sub assembly and part manually according to a system numeration already implemented, until this point is Ok because it works well.  The problem is when we make the drawings of each component because again we manually complete the code for each part taking as reference first the project number (Iproperty, Project) , then the subassemblies (Iproperty, part number) and finally the part (Iproperty, part number)

As you can see this takes us a lot of time and in some cases we make tipe mistakes which sometimes are not easy to detect. What we are trying to do is use an ILogic rule to make this job for us.

An ILogic Rule that can take the value of each component into an assembly (it doesn't matter if is 1 or 100 components inside the assembly) and then put them those values in this order

1. Iproperty Project (A number which is typing manually in a form which we already use) (Example: 005563)
2. Iproperty Part Number (A number which is manually gave it to any component (Assembly or part) when is saved (Example: A001)

The code should take this information, separate each code with an " - " and then put it into the Iproperty Status of each component (Why? because we never use that Iproperty so I think it is easier).

I know I'm asking for a big favor but I've been trying for so long and I feel that I haven't made any progress.

Thank you so much in advance for your help

[WCrihfield]

Hi @armando_amarisNN969.  What about if you use the same part or sub assembly in multiple different assemblies?  That would mean that there are at least 2 different possible part number sequences for that one part?  You can't have two different values for the same part, because there is only one official Part Number iProperty.  And if you set this value for a specific part in this assembly, then use that part in a different assembly tomorrow (or next week), that will change its Part Number value again, because it will be a different sequence of part numbers, and that will overwrite its value from being used in the previous assembly.  It is usually a bad idea to write assembly level data back down to sub components because of this type of situation, and several other reasons.

[J-Camper]

While parts and sub assemblies can be used in multiple places, you might be able to use instance properties for this.  Your drawing would need to be able to access the main assembly BOM because the instance properties are stored at the assembly level. 

I've not had a need to work with instance properties yet, but in theory it should work to traverse the main assembly building up the instance part number as it digs through subassemblies to the parts.  In the drawing, you could pull the instance property from the BOM based on the part file of a drawing view, which exists as a component in the BOM.

[armando_amarisNN969]

Hi @WCrihfield 

Certainly that was a good answer, you are right!! but now I have even more problems than before. As you said if I use a part inside of multiple subassemblies when I run the rule the value will be overwritten several times, the thing is in our company we can not still do it in this way (manually). It takes too long and we are not competitive.  It looks like you already had this problem and got over it, can you advise me or show me where I can start for getting a consistent system.

By the way, for the rule I asked at first if I use a conditional that recognizes an already existing value on the box iproperty status and does not overwrite anything, do you think that could work? In your last message you said there are several problems when you write assembly level data back down to sub components. Can you explain to me a little more thoroughly?

Thank you for your time and effort.

[armando_amarisNN969]

Hi @J-Camper 

I will check about the instance properties. It's the first time I heard about it, maybe this way to get the solution to our sequence automatic code.

Thank you for your suppot.

[WCrihfield]

Hi @armando_amarisNN969.  Attached is a text file containing an iLogic rule example that you can review for a process like what you described in your first post here, but it uses the 'instance' property route, instead of overwriting the regular Part Number iProperty value.  This assumes that each component in the assembly is referencing a model file that already has a normal (not structured) value in its Part Number iProperty.

This process would not work good for overwriting the real Part Number, because that would require getting the current value of it, then overwriting that value with a new value, but then later when working with a lower level component, it would be pulling a structured Part Number value from each of the parent level components, thinking they were not structured Part Number values, then assembling that data into a new value.  It would be chaotic if done from the top down that way.

You asked about the 'system' I was using...

At my company, each user has one Project file, and all those project files are pretty much identical.  All our working files are stored on a server, and all CAD files are stored under a single, structured directory (with sub directories) on that server, below where the project files are.  We do not use 'copy design' process, so some common parts may be used in hundreds of different assemblies.  Each part document that is used in production has its own drawing.  Each assembly has its own drawing that is primarily just for documenting how it is assembled, and what parts are involved, but does not fully detail each of its components or sub assemblies, because each component or sub assembly has their own separate drawing.  Each part or assembly has a part number starting with a short letter or number sequence which indicates its category/main type, then numbers indicating year designed, then the remaining number are basically like serial number, incremented as each part or assembly in that category/type is created.  The drawing for the part or assembly has the same part number as the model, and is stored in the same location as the model file, with the same file name.  Part files are not stored in sub directories of the assemblies, because some of those parts are shared by many assemblies.  Instead they are stored in a parallel branch of the file system, just for parts (parts in one main branch, assemblies in another main branch), that way all other assemblies have access to them.  If there was some sort of data stored within each part that specified every assembly that it is being used in, that would cause the part's file size to continue to increase and be updated every time it was put into another assembly, even though the part itself has never changed.  That would not be a good idea if the part was being used in hundreds of assemblies.  This system requires much less file storage area due to so many parts being shared, instead of just copying entire assemblies with all their parts to other parallel directories and only changing a few things, as some folks seem to do.  But just because this system has worked good for us does not mean that it is ideal for everyone else.  There are many things I would have done differently if I could just move everything around and rename stuff.  But without Vault, moving a bunch of stuff around, or renaming a lot of stuff would cause massive amounts chaos within our existing assemblies, because they would loose their references and would need to be fixed afterwards, which can be a very time consuming and frustrating process.