I can't speak to the Property Tab Builder perhaps others can. I have been encouraged by everyone to use the data card and avoid file properties.
From my experience it boils down to providing your users with a single data entry point (the data card) to ensure data integrity/stability and avoid confusion and failures.
I would have to agree with Jon Brunke yet I have found due to the fact that SolidWorks and EPDM do not always mesh perfectly which often times is due to add-ins that we have. We are forced to use both the Card and the File Properties. I would say though if you are at all able to avoid using the File Properties that would be the best option. As for the Properties Tab Builder I know nothing sorry.
EPDM is a piece of crap (and I deeply think it is) for managing data card/file properties from SW correctly:
I helped to implement it in my company and that is the one of the worse add-in DS ever coded (if they were the coders). The interaction between the file properties in a solidworks file and the datacard is really badly implemented.
One of the strongest feature of the solidworks properties is the ability to have properties identical for all configuration and some properties specific for a configuration, it works well, but I think they can still improve it with the ability to configure properties accross configuration like you can do with feature in the feature tree.. But still, it gives a good and easy way to handle properties, creating file properties tab with the builder was a great idea and works really well at least for the use we have of it.
When we implemented EPDM, we get crushed against a major bug (let me call it a bug), EPDM cannot seamlessly implement the file properties correctly. What are in Custom property tab (the property that we consider for ALL configurations) are put in a datacard configuration called "@", the datacard displays a tab for all other configurations, but their property are configuration specific. So, for example, I have a part with three possible configuration, material is a common property, description is configuration specific, in the EPDM, the material will only appear in the @, and descriptions in the other tabs.
To solve it, you can enable the "for all configurations" in the datacard, this will copy the property which it is enabled for in all the configurations, so to take back the previous example, material field will appear in all the configuration specific tabs when checking file properties under SW.
Then, I could just switch to using the data card only, which in this way works great, but it cannot replace the property tab completely. One of its biggest flaw is the non ability to set a same property for multiple parts at once, you need to run some workflows (I heard that 2010 will have the possibility to have it in the admin tools). With the property tab, when you work in an assembly, you can select a bunch of parts, open the property tab and set properties that will be alike across the selection of parts which greatly improves productivity, this does not work with datacard and makes us loose our time.
In summary, the concept of having a custom property sheet where common property are kept is lost, each configuration need to have their own sets of property. Datacard and property tab builder's all configuration settings has not the same definition and I would like SW to respect a bit some of their standards.
Final sum up:
For the tab builders, for all configurations means that the property is only filled in custom property tab in the file properties
For the datacard, for all configurations means that the property exist in all the configuration specific tab in the file properties.
Also, another problem that we have is the use of list, SW can support text, excel, access, EPDM can support MS SQL... That's the beauty of software integration made by the solidworks team. What I would like is to have both ways to access and edit the same set of data using the same rules. It's stupid to have a same set of properties handled differently by SW and the EPDM.
It's like having a feature call cut a round hole with diameter D in SW and that transferred to the EPMD it will extrude a cylinder with diameter D.
That's was my angry post about the EPDM
To start out, don't listen to these other guys, EPDM is Awesome!!
We set up our SolidWorks templates with configuration specific custom properties, we do not use the 'generic' custom properties which corresponds to the @ configuration tab in the EPDM data cards. The users actually turn off the @ configuration tab so they do not even see it.
The users, SolidWorks and AutoCAD, fill in the properties in the files themselves and the metadata is pushed to the data cards when the files are added to the vault. We never update the data cards themselves, all data is pushed from files going into the vault. This process works out very well for us. The users only have to deal with one place to go to add the custom properties and they do not have to depend on a file getting into the vault prior to adding the properties. We do this for all files going into the vault, not just CAD files.
There are definitely numerous ways of populating the data cards, we decided to use the source file; SolidWorks, Acad, Word, Excel, etc. as the goto source for all properties (metadata). The only time we actuall update the cards is when we want to add data to 'folder' datacards. Like I said, we have been using EPDM for three years now, and this process works great!
Hope that helps,
To me, your process seems a bit dangerous. Users can make a mistake and accidentally overwrite a property name with a property value, or overwrite a calculated property with simple text. I have users who do this now for things such as material information. The extra control of the data card seems to eliminate these problems. Users are less likely to screw up the custom properties if they aren't using them. Out of sight, out of mind.
Another reason I'm leaning toward 'Thou Shalt Enter All Data in the Data Card' is that we plan on connecting EPDM together with Oracle Applications to ensure that item descriptions and such are consistent and that data only has to be entered once. I can talk to Oracle much easier through the EPDM API than the SW API.
I'm curious about your decision to use config specific Properties. Do you use configurations more often than not? Probably 95% of our parts do not have configurations. Those that do often have them simply to show alternate positions and such. A part with multiple configurations during the design phase will typically be split into multiple distinct parts/part numbers when the time come to create drawings.
We too propagate the data, once in EPDM, to other systems. The data starts with the SW files and moves through the system(s) from EPDM. I am not sure how the risk is greater if the users input the data from the file properties than from the data cards? Like I said we have 140 users and have not had one issue with the properties and data card information. The philosophy is the metadata is about the files themselves so that is where the data should be entered. We do all of our preliminary designs outside the vault, so not having to wait to enter the properties until the files enter the vault is a plus.
Anyway, we chose to go with configuration specific custom properties because the number on our files is actually the drawing number, the part number is the drawing number with a -001. So, each model file as at least one configuration called "<drawing number>-001" and that is what goes in the BOM for our MRP system. And yes, the engineers go crazy with configurations here.
I am not sure how the risk is greater if the users input the data from the file properties than from the data cards?
When they enter data from 'File...Properties' they can inadvertently change the name or type of a property. SW doesn't allow these to be made locked or read-only. I have users who do this now. Sometimes intentionally . They do it the quick way instead of the right way.
The data card hides the underlying property name and type and only exposes the value.
Anyway, we chose to go with configuration specific custom properties because the number on our files is actually the drawing number, the part number is the drawing number with a -001.
OK. We pretty much have a 1 to 1 relationship between parts and drawings, so they get the same name and differ only in the extension. All our custom properties live on the non-config specific tab. In the event we have a config, we manually add the config-specific properties and they override the other properties on the drawing.
About the custom properties in the SolidWorks parts and assemblies. I assume you drive your titleblock information from the custom properties of the part and assembly files. How do the drawing titleblocks get populated before they go into the vault if all properties are entered via the data cards in EPDM? I am confused on that one.
"OK. We pretty much have a 1 to 1 relationship between parts and drawings, so they get the same name and differ only in the extension. All our custom properties live on the non-config specific tab."
Yes, exactly. It is the same here, all related files; slddrw, sldprt, sldasm, dwg, get the same file name and differ only by the file extension. My point is, the base number is the drawing number and the -001 is the actual part that is ordered. That way you can have different instances of the same base number; a left and right hand part, for example, would be set up this way: LH = <basenumber>-001, RH = <basenumber>-002. We have drawings that have hundreds of dash numbers on them that represent different instances of the same part.
When we first set up our SW templates we disregarded the config specific properties as well. After a few years, we realized the properties were actually for the part number and not the base number and switched all files over to config specific properties. Different configurations, or instances, of a part may have properties specific to each configuration.
I assume you drive your titleblock information from the custom properties of the part and assembly files.
Yes and no. In our current (non EPDM) setup all title block information comes from the part or assembly model. My plan for our EPDM implementation changes some of that:
- The title and material information will come from the model.
- The drawing number will be the file name of the drawing itself (without the extension of course).
- The signature information (Drawn By, Checked By, Approved By, etc) will come from custom properties of the drawing itself, but they will actually be populated by the workflow.
How do the drawing titleblocks get populated before they go into the vault if all properties are entered via the data cards in EPDM?
Good question. Since we don't have EPDM yet (accountants are dragging their feet on the expenditure request), I can only say how I hope it will work. Unfortunately, SW doesn't allow your to have a copy of the User Guide prior to purchase.
Our current process works like this:
A. We have project directories where design work is done. Parts and assembly files have simple descriptive names like BRACKET.SLDPRT or CASTER.SLDASM. Drawings are rarely present in project directories.
B. When a part/assy design is complete, we create a new number in our Oracle system and then do a 'Save As' on the part/assy model using the newly created part number as the file name (to a different directory).
C. Custom properties are entered through 'File...Properties', using the Task Pane or on the drawing title block (see below)
D. The drawing is created and if not handled in step C, the title block data is entered using the buggy title block functionality in SW.
E. The drawing is saved, again using the newly created part number as the file name.
F. Lather, rinse, repeat for the other parts and assemblies in the project.
When all is said and done, the project directory is full of abandoned parts and the numbered parts are all in a well organized directory structure where anyone can find them.
For EPDM, I hope to duplicate the process but eliminate waste and automate it more:
A. Project directories in the vault, like we have now. Parts and assemblies with descriptive names, like we have now. Check ins and check outs should be uneventful.
B. When a part/assy design is complete, we create a part number in our Oracle system.
This is where things get fuzzy since I'm speculating on how EPDM works and what it can do
C. Initiate a workflow transition ('Complete' or 'Ready for Mfg' or something) on the part/assy file. This would rename the file to the desired part number and move the file to the appropriate location in the vault.
D. Create drawing (with file name matching part number) in the local workspace (or perhaps step C creates it automatically in the vault and checks it out)
E. Check drawing in to proper location (workflow populates signatures in title block via digital signature and custom properties)
Future plans include tighter integration with Oracle so that EPDM can request the next available part number and then push the part description from EPDM into Oracle (eliminating the need to enter data twice).
So, to answer your question more succintly, portions of the the drawing title block would be populated from the model properties (since they already exist) and other portions would be populated by the workflow (hopefully) on check-in.
We have drawings that have hundreds of dash numbers on them that represent different instances of the same part.
When we first started using SW (1999) we set things up to handle dash numbers and such. After serveral years of fixing drawing problems caused by models that had configurations (but weren't true dash number parts), we determined that dash numbers really weren't helping us. We simply don't have enough configurations to see the benefits that you see.
If you only use configuration specific, do you spend a lot of time filling all properties for each configs? How do you handle that?
Your way is the right way, it's as stiff as modifying the datacard, because you end up with a 1 to 1 relationship. But it is not practical in all different company practices. Though, I would like all people in my company to work like that and don't spit on the hard extra worload I have been putting to have the EPDM set up...
Anyway my problem is if you have one file with 10 configurations (we are working in plastic industry and one way I find out to have our ERP system correctly order material and colorant is to create one unique material for each color we have, then, create one config per material), if you have one common property like: base resin (in my case), I would need to change this property for each configuration going through all the configurations tab, for an assembly of 5 parts with 10 SKU, I will have to go through 50 fields to change, whereas using all configs, I would only use 5 fields. Using task pane, it will requires me to open the assembly, click on the 5 parts, change the resin for all the parts at the same time, done, last, using the EPDM, I would have to click on each parts and change the field in every configuration, nearly the same amount of click that editing the file properties of each file under Solidworks plus the latency induce by the database/archive server.
That's when we like to have something used for all configs.
The other way to say what you said is that if things are set properly in Solidworks, EPDM shows them the right way, as far as you don't use common properties, it works, which I totally agree, but I would like to have solidworks and the EPDM handles this custom property the same way.