Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

design tables

Status
Not open for further replies.

sojouner

Industrial
Apr 26, 2003
29
0
0
NZ
At work I am in the process of coming to grips with excel and design tables.
Now what i was wondering was what are some good basic "rules" for keeping design tables easy to edit and easy to handle and easy for others to see how you have set it out?
The company I work for manufactures products from tubular steel and MDF wood (retail shop fitings)and we are heading in the direction of design tables for the stuff we manufacture.
Thanks in advance for any advice
Brett

 
Replies continue below

Recommended for you

Sojouner,

Have SolidWorks create the Design Table for you if you already have the part drawn. When you Insert the Design Table, you can choose to have it automatically created. This way, you can see how SW would do it, and you can then figure out what all that stuff is, and know whether to leave it or remove it.

The "rules" vary from place to place. Some like to have everything in the design table, others just like to have certain stuff in there. On;y you all can decide what works best for you. I like to have everything in there, and set SW to NOT allow changes directly (must use design table). Another level of "are you sure you want to change it?" this way.


-----------
Mr. Pickles
 
I'm of a slightly different mind in that I control the minimum amount of dimensional data necessary for any given item that I choose to control with a design table. For example, a 1/4-20 Socket Head Cap Screw's head geometry won't ever change so I only control the length dimension in the design table (D1@Extrude1 = 1.5).

I find that it makes the design table easier to read/follow. Also I'd like to second the recommendation (by CMcF) to give meaningful names to dimensions controlled by a design table. This also aids in understanding what's what in a design table.

Another thing you might want to consider is embedding configuration specific custom properties in your design tables. This is helpful if you make use of the BOM functionality in SW and would have use for saving such info as a custom property. For example you can have your design table setup to concetenate certain fields into a description that is display in a drawing BOM:

SCREW, SHCS, 1/4-20 UNC X 1.5 LG, STL

Hope this was some assistance to you.




Chris Gervais
Sr. Mechanical Designer
Lytron Corp.
 
I would advise that you build some of the configurations in the design table and then test the part, save it, close the file and re-open, then test the part configurations again. I am having problems with configurations & derived configurations "adopting" the dimensional value of the last saved configuration.
The only "fix" I can come up with is to separate the original file into multiple files to minimize the changes from config to config. I haven't implemented this yet hoping that I can find a fix for my files (socket head cap screw & o-ring).

Louis
 
I like using excel functionality in my design tables. As an example, when filling out a description that will appear in a BOM (for the screw mentioned above) I would use the length cell to change the length, however I would not manually input the length into the description field. I would have something that lookd like this =&"SHCS, 1/4-20 UNC X "&B3&" LG". Where B3 is the cell that has the length. Using this type of format, you can quickly make multiple configurations where all data propagates correctly simply by changing a few cells.

You can also use design tables the way you would use SW equations. Simply by having your formulas in the cells. If I ever feel the urge to use an equation (which is rare) I would rather use it in a design table.
 
Something I find handy is to think ahead about what types of models will be controlled by the design table. Manually create those configurations that incorporate all the dimensions, etc. that will change between configs, then auto-create the design table.

The purpose is to let SW know what needs to go into the table - it adds only those things that are different among the configs. So if you know the length will change, make sure you create more than one config with a changed length. If a description property will be different, make sure you have more than one variety.

SW will allow new items to be added, but once you recognize how it works, it's easier to do it from the beginning.

WT
 
thanks guys
1) what are some problems with design tables that you have had and what did you do to overcome these probs?
 
I noticed that sometimes, if you have linked dimensions in your model, and you simultaneously create 3 or more new parts from the design table, that the linked dimensions MAY NOT come thru correctly until you manually activate each new config, and do a rebuild.
 
Here are some useful tips which have worked for us. Read the help on DT's LITERALLY. For example there used to be a difference between Insert DT and Insert DT New. Partname row in one all the rows numbers are differnt by one.

It is interesting to note that the "DT itself" extends from the cell A1 down and right until it hits a blank row or column. They actually tell you this in a backhanded way by saying don't leave blank rows or columns. Of course, being me, I had to dive in and figure out why not!!! So if you want to do some Excel stuff in rows and columns that are not part of the DT proper, you just leave a blank row and column and do it off to the right or below. Another use for this is that you can them hide all this. Infact if you do all the ugly stuff off in the ozone and link the results to the cell in the real DT part, you can prevent anyone from accidentally screwing it up. (Remember you can't protect worksheets in a DT - they have to be able to change.) Some of ours actually hide the DT itself and just show some pretty tables of the data which are just cells linked to the DT cells (the actual values are linked in from outside). You can also do boleans, checkboxes, etc. and have all nice pretty colors and borders. You can even OLE link data in (IN only if it is an embedded DT) from external Excel and other sources. We are using Access to input data into a large database which then drives our optical and mechanical HUD configuration design, including complex mechanism geometry. We even have Access pop-ups in SW now. We also have hyperlinks in our DT's which link you into a help file. It can be a lot of fun...........

Be naughty - save Santa a trip.
 
>>So if you want to do some Excel stuff in rows and columns
>> that are not part of the DT proper, you just leave a
>> blank row and column and do it off to the right or
>>below.

It actually looks for the "Family" label on the spreadsheet, so you can also use above and/or left.

>>Another use for this is that you can them hide all this

That is great. I may put a drop-down listbox in the worksheet allowing users to select from a list of materials. This is located in a column that is PAST an empty column, but the empty column is hidden, so it seems as 'part' of the DT. Selecting the material also inserts the text value of the selected list item into a hidden column BEFORE the blank space, which inserts the value into a custom property. No worrying about typos.
 
Interesting. I have not played with DT's for a while. When I did most of this stuff there was no Family label issue. It had to be the top left set of cells. Mind you I think still I like it best. It is simple, you always remember where it is and if some dufus starts poking around when they shouldn't, they can rarely figure out how to unhide from cell A1!! Sometimes the vagueness of MS help files is an advantage..... Heh, Heh!! :)

Be naughty - save Santa a trip.
 
Status
Not open for further replies.
Back
Top