Tabulated vs Detabulated
Tabulated vs Detabulated
(OP)
I'd like some insight from people that work in a multi-user environment on how they handle drawings of items that are tabulated. My company continues to flip-flop between tabulated and de-tabulated drawings. In the AutoCAD days, everything was tabulated. When we switched to SW in '97 it was decided to de-tabulate drawings due to being "scared" of configurations and the multi-user environment (and unfamiliarity with SW). During '00 they tried to revisit tabulated drawings, but ended up manifesting their fears, creating a lot of confusion and going back to de-tabulated drawings.
Now it's '05 and the company finds itself with SW05 SP4 (probably skipping SW06 as they did with SW04), and once again toying with the idea of tabulated drawings. I'm trying to avoid past mistakes, reinventing the wheel, and under utilizing SW. I'd like to know what methods and successes others have had.
Some examples of our parts that could benefit from tabulated drawings:
hydraulic hoses
expanded metal mesh panels
structural tubing
hardware
ring terminal-terminated wires
weldments (for S, M & L products)
Thanks all, looking forward to your posts.
Now it's '05 and the company finds itself with SW05 SP4 (probably skipping SW06 as they did with SW04), and once again toying with the idea of tabulated drawings. I'm trying to avoid past mistakes, reinventing the wheel, and under utilizing SW. I'd like to know what methods and successes others have had.
Some examples of our parts that could benefit from tabulated drawings:
hydraulic hoses
expanded metal mesh panels
structural tubing
hardware
ring terminal-terminated wires
weldments (for S, M & L products)
Thanks all, looking forward to your posts.
"I think there is a world market for maybe five computers."
Thomas Watson, chairman of IBM, 1943.
Have you read FAQ731-376 to make the best use of Eng-Tips Forums?






RE: Tabulated vs Detabulated
Regards,
Regg
RE: Tabulated vs Detabulated
Chris
Sr. Mechanical Designer, CAD
SolidWorks 05 SP3.1 / PDMWorks 05
ctopher's home site (updated 06-21-05)
FAQ559-1100
FAQ559-716
RE: Tabulated vs Detabulated
RE: Tabulated vs Detabulated
SOLID Solutions Advanced
Solutions Review
Volume 2, Issue 3
March 18, 2003
Tabulated Drawings
By Lee L. Bell
Edited by Wayne M. Tiffany
By leaving a blank row and column in your design table, you can utilize the rest of the spreadsheet to make the tabulated area look as you want it to appear on the drawing.
I think that the tip came from SolidWorks Community at www.swcommunity.com.
Regards,
Christopher Zona - Senior CAD Designer
Litens Automotive Partnership
Concord, Ontario
RE: Tabulated vs Detabulated
We have been through a similar debate in the past, but tabulation was the way we went. Pro's are, only a single
drawing is created vs multiple non-tabulated drawings. Creating configurations is simple (once you remember, when creating a new config to select the "this config only" when changing a dim!). We show the largest configured part on the drawing, and use letters in place of dims that reference the tabulated chart. Con's are typographical errors may crop up in the Excel table due to manual entry.
The alternative is creating the configurations, and then creating individual drawings per each config. It is time consuming, but there is no table that may confuse others reading the prints. The question you need to ask is how many configurations of a master part will be created. We average about 5 configs. If your number is higher, tabulation is probably your best bet.
Jeff
RE: Tabulated vs Detabulated
"I think there is a world market for maybe five computers."
Thomas Watson, chairman of IBM, 1943.
Have you read FAQ731-376 to make the best use of Eng-Tips Forums?
RE: Tabulated vs Detabulated
Good luck in that. Have you questioned the people who will be using the drawings for their preference? I know it's easier to read a non-tabulated print, but if all configs are on a single drawing, it has it's advantages.
Jeff
RE: Tabulated vs Detabulated
So we use both. The rules are:
- one drawing per configuration in "mass production" standard products (this is an heritage of the RPM system, as each part/configuration as it's own code and management)
- tabulated drawings for costumized products (as they are treated differently in production, this will simplify the drawings preparation and use)
Regards
RE: Tabulated vs Detabulated
I am glad that you realize that you need to devise a system that can handle everything. Not many people realize that. A system like this will use Object Oriented Technology. What it means is that each object, be it a part or an assembly, has its own model and/or drawing. SolidWorks is an 100% Object Oriented software program. It works best when parts or assemblies are not tangled each other (but they can be depended on each other). We do not need to debate about this as it was proved some 20 or 30 years ago. That is why all modern ERP software are object oriented.
Tabulated drawings are not here to stay.
Alex Chen
P.S. Old ideas can die hard - especially when they were
once based on fact - but this is not true today.
RE: Tabulated vs Detabulated
Object oriented?
Object Oriented Programming (OOP) is a computer programming concept. Everything is an object. Objects have names. They can contain each other. They have scope, meaning that the object's entire existence is in the context of the object that contains it.
That last OO concept of scope is absolutely incompatible with good mechanical design practice. The more unrelated things each of your mechanical parts do, the fewer parts you have.
The policy where I am is to not tabulate drawings. I am annoyed by it. Tabulation is meaningful when I have a series of parts that are around 98% identical. My design intent may be that a set of critical dimensions are identical across a range of parts. Having all these features on one view of one drawing clearly communicates this. If you do not want to change form, fit and function of an existing part, tabulation is a quick and dirty alternative to a new drawing, and it provides design history.
What are you tring to communicate? Who are you communicating to? How do you need to communicate it? The whole point of SolidWorks is that it can cope with this.
JHG
RE: Tabulated vs Detabulated
I am glad to learn that your company has right policy and vision for future. I do not understand why you are annoyed by that. I do not know if you are fimilar database and ERP systems. A tabulated drawing is just like a spreadsheet. It is static. One drawing for each object (part or assembly) is based on database. It is dynamic. It is far more efficient.
Most companies created tabulated drawings for a family (or series) of products. These products are normally very similar. What is "Very Similar"? There is no thick line between them. Putting many simlar parts in a tabulated drawing sounds very logical, but it is not. They are tangled each other. Also, I am pretty sure that you realize accasionally your tabulated drawing using SW multiple configurations may not always be able to handle the product series.
If you goes to WalMart, none of their items are tabulated.
If you do some mechanical design automation, you do not want to have tabulated drawings.
Just like MadMango mentioned, you need a system that will work for everything. Your tabulated drawing will not be able to handle for everything for sure. This is why MadMango is searching such a system.
Alex
RE: Tabulated vs Detabulated
I don't understand the object oriented comment, while our drawings may be tabulated, the parts are still separate objects.
Also, configurations are separate objects that represent each part. If you choose to put them in one file is just a method of storing the data, but each config has it's own attributes.
Jason
UG NX2.02.2 on Win2000 SP3
SolidWorks 2005 SP5.0 on WinXP SP2
SolidWorks 2006 SP0.0 on WinXP SP2
RE: Tabulated vs Detabulated
If a database forces me to change the way I work I say get rid of the database. Databases can be configured to support the way work has to get done, by me and by production and sales.
Whether or not I tabulate, I generate drawings with numbers that can be managed by PDM. The drawings generate part numbers that can be managed by ERP and MRP. Either way, each drawing has a unique number and each part has a unique number. ERP should not care less if a bunch of numbers are generated off the same drawing.
Take the case that I am designing a space frame to be screwed together from aluminium angle. I have fifteen different lengths of angle, but I manage to set up the exact same hole arrangement at each end. Instead of taking the time to produce and manage fifteen drawings, I do one, with the length and part number tabulated. PDM saves the time required to manage the other fourteen drawings. The fabricator sees that each of the fifteen different parts has the exact same hole arrangement at each end and they make one drill jig. Purchasing orders whatever quantities of the fifteen different parts are required, and ERP keeps track of them, unaware that they cost less than they should have. I do not see a problem here.
Your distinction between static and dynamic is meaningless in the context of tabulated drawings. In the above case, I cannot easily change the hole pattern in one part only. Probably, I would have to generate a new drawing. But, this is my design intent. I want everything to be identical so that tooling is simple, and I want to point this out explicitly to the fabricator.
Dynamic data and ERP are a bad combination anyway. I design a bunch of parts to be assembled together. I finalize the drawings and submit to PDM. The parts are registered in ERP, ordered and stocked. Meanwhile, I modify the drawings, moving holes and interface surfaces around. ERP orders more parts. With SolidWorks and a complex set of assembly constraints, this can almost happen randomly with parts changing their dimensions depending on what drawing I have active when you request a printout. I have seen this done.
ERP's database is now a disaster, because it has no way of knowing whether the parts in stock can be assembled to each other.
If I am assembling a one-off system at my desk or at home in my back yard, I can make dynamic changes. Once the thing goes out to manufacturing, I cannot change form, fit or function.
JHG
RE: Tabulated vs Detabulated
Chris
Sr. Mechanical Designer, CAD
SolidWorks 05 SP3.1 / PDMWorks 05
ctopher's home site (updated 06-21-05)
FAQ559-1100
FAQ559-716
RE: Tabulated vs Detabulated
You may want to take another look at this. ERP's database is not a disaster. It is not an ERP's job to determine whether the parts in stock can be assembled to each other. The parts in stock do not interfere each other until they are used. So, it is parent assembly that needs to know if its children (components) interfere with each other.
If you are using a system that can not handle a situation, then you have a problem. You DO have a problem, don't you?
By the way, using SW mechanical design automation, it is faster to generate 15 drawings than maintaining a tabulated drawing.
As also a database programmer, I can tell you the whole world is marching toward database. There is nothing you can do to stop that. One of database requirements is that objects must be independent (technically, it is called "Data Normalization"). This means in SW that parts or assemblies should be independent.
Alex
RE: Tabulated vs Detabulated
I no it's not faster to generate 15 drawings and 15 models than to building one model with a design table and 15 configurations pointing to one drawing with the design table inserted as a table showing the differences. And any future changes is only made once, not 15 times.
Databases have been around forever. Solidworks IS a database full of internal table storing the data, including a table of configurations that represent parts, all separate.
Jason
UG NX2.02.2 on Win2000 SP3
SolidWorks 2005 SP5.0 on WinXP SP2
SolidWorks 2006 SP0.0 on WinXP SP2
RE: Tabulated vs Detabulated
I am not surprised by your opinion. I know there are most companies using tabulated drawings right now. But more and more companies are switching to detabulated drawings.
I had been using tabulated drawings for many many years. Three years ago, I realized the foundation of tabulated drawings was not solid. We made the switch, and we never looked back again.
Thanks for your feedback!
Alex
RE: Tabulated vs Detabulated
Jason
UG NX2.02.2 on Win2000 SP3
SolidWorks 2005 SP5.0 on WinXP SP2
SolidWorks 2006 SP0.0 on WinXP SP2
RE: Tabulated vs Detabulated
Flores
SW 2005 SP 4.
RE: Tabulated vs Detabulated
You are right. I am working with a disfunctional PDM system. It is a nice pretty database. It obfuscates mechanical design data, and it provides poor support to manufacturing and sales. I can see ways the database could have worked, but it was not implemented that way.
What dumb ideas went into this thing?
SolidWorks models can be used as an ERP database. They (mostly) represent real parts. The profile cards can be used to populate the database fields. Of course, database people know all about mechanical design.
SolidWorks is a mechanical design and documentation tool. If you optimize it for non-mechanical tasks, you mess up mechanical design. There was probably a better tool for that other task, anway.
In ERP (or MRP), the objects in the database are physical parts, not documents or CAD models. It is important not to get confused. The part numbers you read off the drawings are all ERP needs to know about. If your part numbers are based on document numbers, you know what document you need.
Mechanical design automation is a very limited technology. It works really well when a company builds one-off similar system based on a small number of design criteria. Our VAR claimed that such a customer increased his productivity by 800%. Most of my stuff is not automatable.
If I run into an automatable problem, I will solve it within SolidWorks. The PDM, ERP and MRP provide me no usable resources.
JHG