16 Replies Latest reply on Jun 14, 2017 5:43 PM by Joe Miller

    Part Numbers & Descriptions

    Joe Miller

      Hopefully someone can straighten me out here, but it will probably be "Oh well, that's SW for you". Why are there 4 different ways(by my count) to enter part numbers and descriptions into configured parts and the way you do it determines the behavior? It seems pretty simple to me. Every part has a part number(or at least should or could by every measure I've ever seen). Every part has a description. Every part in SW has at least one configuration. Provide one blank for the part number, one blank for the description and allow the user to display either or both in any and all tables/selection boxes.

       

      Feature tree displays file name, component instance number, configuration name and description.

      Configuration selection box inside an assembly shows configuration name and description, but only if the description is in the configuration properties shown on the left side of the screen in the part file.

      eDrawings reverses the feature tree display and shows the component file name and instance number.

      Bills of material are a whole other challenge.

       

      I didn't mark this as a question because it's more of a vent than anything. I know a lot of folks like having multiple ways of doing the same thing, but with part numbers and descriptions just one way that works across the board would be really nice!

        • Re: Part Numbers & Descriptions
          Bernie Daraz

          At a former contracting position we had files saved into a directory for each build. The top level assembly part number was the name of the directory. Within the directory we had multiple parts to build that assembly and sometimes multiple parts within those assemblies. Each and every one of them was a configuration. While the top level assembly number might start with 350- to indicate a product family, internal parts would be 450-, a silk screen would be a 250- and a PCB was a 650- if I remember correctly.

           

          Each one of those XXX- were followed by the individual part numbers for sheet metal chassis or other parts, at this point the XXX- were followed by XXXX- to indicate those parts. Then followed by another XXX to indicate the configuration. Only the configured part had a full part number. It was common to see 350-12345-001 as much as it was to see almost any other part number. Only the directory name had a revision level noted. While the internal parts may have been revised they were not saved as a part number with revision level.

           

          Descriptions were secondary as the full assembly naming and part numbers were assigned before we 'engineers' modeled or made drawing of anything. We were supplied with a One Note flow chart if you will, it described the names and part numbers. I think it worked great.

           

          Hopefully your assemblies are less complex or don't require such a nested layout.

          • Re: Part Numbers & Descriptions
            John Stoltzfus

            I've used SW for years and have never noticed, maybe it's because I always did it the same way, I don't know.. I did find though that to use SW it pays to do it the same way every time. 

             

            What is your issue with BOM's

             

            You get out what you put in.

              • Re: Part Numbers & Descriptions
                Bjorn Hulman

                John, is this not where you mention the Custom Property Tab and it's associated builder?

                  • Re: Part Numbers & Descriptions
                    John Stoltzfus

                    Bjorn Hulman  you know - maybe I should, you mean I should mention that the CPTB is the most underrated SW addin...  Joe Miller (not sure if it's the right one) Joe didn't say he was looking for a solution, just an excuse to rant...

                      • Re: Part Numbers & Descriptions
                        Bernie Daraz

                        Good morning John! Perhaps I could have mentioned that too! In my response I spoke of the way we kept track of things but I had a custom property builder tool in these files. I could identify a part as a 'chassis' or 'cover' and the text in the notes would update properly depending on which part I was working on. It reduced the workload for me and my coworkers. It might be a small amount of work to create these files but the payback is in reduced efforts and automatic updating of things that really should be an important concern. One of the side benefits is once you create these files and the spelling is right you need not be concerned will spelling errors. Are spelling errors that important? Yes, when a part number or finish number is misspelled you don't get what you expect at delivery.

                  • Re: Part Numbers & Descriptions
                    Andy Sanders

                    I was always good with assigning "Description" as a custom property (either for a single part, or for multiple configs with config specific descriptions).

                    Then, somewhere along the line SW added "Description" to the config properties box.  That's when things got muddled.  In the end, I just ignore that completely and go about it the way I always have with custom properties.  Works great.

                     

                    As far as part number, I always use the "Bill of Materials Options" under the config properties.  If there's just one, then it's the Document Name option.  If there's more then one config, then I pick User Specified for it.

                     

                    This way has worked for us in many assemblies for many years.

                     

                    I think you just need to establish a standard and have everyone stick with it.  Easier said than done sometimes!

                      • Re: Part Numbers & Descriptions
                        Bjorn Hulman

                        A great way to get everyone to stick with a standard company method, is to make it easy. Custom Properties Tab.

                          • Re: Part Numbers & Descriptions
                            Andy Sanders

                            Bjorn,

                            Can you tell me how to incorporate this field into the property builder?  All the tags I've tried that are available in the drop down list don't work.

                            This is the property we use for all of our BOMs so to use the tab builder this is what I need.

                             

                            part number for property builder.jpg

                              • Re: Part Numbers & Descriptions
                                Bjorn Hulman

                                Hi Andy,

                                You'd add the part number as a configuration specific property. With files with a number of configs, you can add a configuration table to help maintain the properties.

                                  • Re: Part Numbers & Descriptions
                                    Andy Sanders

                                    Thanks, but what I need is to use that specific field as shown in my pic on the configuration properties tab.

                                     

                                    I could create a part number custom property, as you suggest, but we have a huge library of history that uses this particular field for the BOM part number.  We rely on the configuration list to show the part number associated with the config in the [brackets] next to the config name.

                                     

                                    There must be a tag inside of SW that pulls this number.  Much like you have access the SW-Material, etc tag.  They have SW-Filename but that only works if there aren't any configs.

                                     

                                    I guess, in the end, I'll keep doing what I'm doing for the part number field and keep the property tab strictly for custom properties.

                                     

                                    I guess this just underscores the original post as to there being more than one way to enter this info in SW.

                            • Re: Part Numbers & Descriptions
                              Scott Stuart

                              Solidworks can be used many different ways. Some companies use one configuration per model. Some use multiple configs per model, but treat all configs as the same part number. Some use multiple configurations and treat them as separate part numbers. These different use cases mean there are different ways to input part number and description.

                               

                              At my company we use multiple configs per model and treat the different configs as different part numbers. We might have a file called 123-456.sldprt which is the base part number for, say, a family of sensor brackets. We might have configs 01, 02, 03, which are short, medium and long brackets. The part numbers would be 123-456-01, 123-456-02, and 123-456-03, entered as user specified in the config properties. The config descriptions might reflect the general "short", "medium", and "long" descriptors, or maybe would reflect the machines or assemblies where they are used. But in the custom properties, which is where we input the actual part number description for our ERP system, we would give proper descriptions like "BRACKET,SENSOR,SHORT", "BRACKET,SENSOR,MEDIUM", and "BRACKET,SENSOR,LONG".

                              • Re: Part Numbers & Descriptions
                                Tom Gagnon

                                I can add a related side-gripe to the Description discussion. Installation reference 2016 SP3, Win 7. For all I know, this has been addressed in newer licenses, but broader stability issues have kept me from upgrading. I agree in spirit with the OP's comment that, while diversity of input methods is sort of distracting, the real problem is that Solidworks handles this exact custom property in various ways per context.

                                 

                                Create Part. Save Part. Completely fill out custom properties, particularly including Description. Save. Then Add to Library...

                                In the Add to Library FM dialog, you can add a description. I already did that! Doesn't it recognize or even look for one? Forget this extra step. Leave it blank, accept and continue. Item is now Added to Library. (Close original Part)

                                Mouseover on the Part in the Library: It shows no description.

                                Open Library Part. Open Custom Properties. Evaluated Value of Description property is empty, but content is present in its Value / Text Expression. Click Description's Text Expression. Hit Enter. Description re-evaluates to fill out its Evaluated Value from its Text Expression. Save Part. Close Part.

                                Now, mouseover of Part in Library displays its description.

                                 

                                This is an easy but tedious extra step to make Library Parts more useful to select from. I can avoid it by having the description copied onto clipboard before Adding to Library, but an extra step is an extra step, whether implemented before or after.

                                 

                                What irks me is the removal of Evaluated Value in the process of adding Part to Library when THAT description field is left blank. Can't it fetch the property in the first place? If I actually fill this in, inaccurately or more generalized and less specific, does it retain this value, or revert to original description, or somehow both? I've also seen redundant Description Custom Properties added to the list, particularly on items where I've removed that from the base custom properties so that it will be ruled by the configuration specific custom properties.

                                 

                                It'd be even worse if you named your Custom Property, "PartDescription" or "BOMDescription" instead of "Description". Then you'd have two, separate and unlinked.

                                 

                                Edit: Oh, and I almost forgot the worst of it. I open an old completed drawing to revise. Ignoring the Titleblock, which should not have changed except for its revision level, I complete my task and generate a PDF. The Drawing's "Description" field is not showing in the titleblock as it should! I edit the drawing's custom properties, and its VALUE HAS BEEN REMOVED and left as blank. Good thing that I keep PDF's of all drawings produced, so that I can refill this exactly as it ought to be. For this reason alone, I have been tempted to rename this custom property in my default drawing templates and sheet format. Has anyone else had disappearing Descriptions in drawings? *boggle*

                                • Re: Part Numbers & Descriptions
                                  Joe Miller

                                  Thanks for all of the replies and great suggestions! I think Andy hit it on the head with the Config Properties tab data being a bit of a mystery as to what variables are actually associated with that data. I switched us over to using the Custom Properties tab exclusively about a year ago and that works fine, except when it comes to selecting configurations inside of an assembly or exporting an assembly to eDrawings and trying to look at the BOM. The data entered on the Custom Properties tab doesn't show up in the drop down to select a different configuration when inside of an assembly, nor does it show up in the BOM in eDrawings. I think I will run a test, creating a configured part and putting in the configuration part number and description in the Config Properties tab only, then seeing if I can find those variables upon creating a design table.

                                    • Re: Part Numbers & Descriptions
                                      Joe Miller

                                      Well I found some interesting things when running my tests and it makes me want to put in a disenhancement request. The variables that act as the configuration name and description on the Configuration Properties tab are set up like file wide variables with the $ in front. Most of the other configuration specific variables have $PRP in front. If you try to drive changes in these two variables through the Custom Property tab it doesn't work. You can drive changes to the configuration description using a design table, but not the configuration name. Seems to me SW should reassign the two blanks on the Configuration Properties tab to variables that are configuration specific and unlock the configuration name so it can be changed using the Custom Property tab.