Design Tables and How to Customize them 1

I'll have to keep an eye out for the article! What are you thinking of doing, writing a series of articles? While my time is usually limited, I would be glad to give you a hand where I can.

I am sure that most individuals interested in automating SolidWorks would like this technique over creating standalone VB applications. This is a handy way to store your data, configuration info and program code in the same place. The latest version of SolidWorks has added a familiar face to their macro editor. This also makes automation a breeze.

The only downside of using VBA over VB is the poor functionality in creating user forms. In VBA, the forms are a little harder to create and you are not able to use control arrays, which are a big plus if you have a stack of user inputs.

Another thing that one will have to keep in mind is the scope of the project. For smaller projects, VBA and Excel would fit the bill. But, if the goal is to automate an entire product line that is rather complex, VB may be a better solution. For example, one of my projects has almost a half a million lines of code. There are almost 20 separate programs used for the automation. The root programs do the engineering calculations and component selections. These were separated so that they could be utilized by an estimating program as well as the SolidWorks automation programs. One of the programs taps into the data for the manufacturing side, creating the CNC code necessary to make some of the components.

Speaking of limited time ... DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

Scott, I'd be interested indeed. "Happy the Hare at morning for she is ignorant to the Hunter's waking thoughts."

Well guys, I have a couple things in mind.

1) I may get a chance to write a book on stuff such as this & about SW.
2) I have also considered writing more articles to SSM.

As in reply to your post dsi, Please do keep an eye out for the Nov-Dec issue of SSM. I’m looking for some feedback on it.

<Snip>
I am sure that most individuals interested in automating SolidWorks would like this technique over creating standalone VB applications. This is a handy way to store your data, configuration info and program code in the same place. The latest version of SolidWorks has added a familiar face to their macro editor. This also makes automation a breeze.
<Snip>
The only downside of using VBA over VB is the poor functionality in creating user forms. In VBA, the forms are a little harder to create and you are not able to use control arrays, which are a big plus if you have a stack of user inputs.
<Snip>
Another thing that one will have to keep in mind is the scope of the project. For smaller projects, VBA and Excel would fit the bill. But, if the goal is to automate an entire product line that is rather complex, VB may be a better solution. For example, one of my projects has almost a half a million lines of code. There are almost 20 separate programs used for the automation. The root programs do the engineering calculations and component selections. These were separated so that they could be utilized by an estimating program as well as the SolidWorks automation programs. One of the programs taps into the data for the manufacturing side, creating the CNC code necessary to make some of the components.

Well as most of this is true I see using Excel and VBA in a different light. In VB all you have is code, all calculations must be done in code everything must be done in code. In VBA you not only get the power of code but you also get the power of Excel. Excel by itself is very powerful. If someone is to find away to harness the power of Excel, VBA and SW then you can get a very powerful combination. Don’t get me wrong VB and SW s powerful too. We have a program here that was designed in VB and SW. It took way longer than anyone thought it would to make, but it is working semi-efficiently.

You can program Excel…VBA in 2 ways with SW.

1) Embedded
2) Not Embedded.

Embedded – This would consist of making a DT in a SW file (Which is the way most of my automations have been made). The first sheet is the DT itself and you build it normally like any DT. You must take pride in building it though. Find the items or Dimensions that you plan to control first then the ones that are optional last. Make a second sheet in the DT. This sheet is a control point to the DT. Make the appropriate options, using combo boxes, textboxes, or make a new userform. (Even though there are some limitations of these Userforms vs. VB Userforms, I have found ways around most of these problems.) All you have to do now is link the Combo Boxes and Textboxes to the DT as they change. It’s easier than you may think linking these settings to the DT. You really do not use SW API callouts on an embedded DT. You just use Ranges, Textboxes, and Combo Boxes names to control the DT. Add a couple of buttons the sheet. One for switching between the 2nd to the 1st sheet and another to for closing the Application (Excel). Then the model updates. You can have certain configurations specifically wrote doing it this away. You can really customize it to do just about anything you desire. I just haven’t had a chance to find all of it…yet.

The downfall to doing it like this is the SW file size you get. It can be Quite large.


Not Embedded - This is making a program in Excel VBA without having the link to SW directly like you do with an embedded DT. You can customize it just like above except you have to use SW API code to get the link between the two.

The good news doing it this away you don’t get the large SW file sizes. Downfall is you have to learn SW API code.

My last automation program had 35 different Modules made in it and a lot of code wrote in each one.

I hope this helps explain,
Scott Baugh, CSWP
George Koch Sons,LLC
Evansville, IN 47714
sjb@kochllc.com

Scott:

I definately agree. Automation is much easier using design tables than the API. I just wanted to highlight the potential bottleneck for anyone who may want to take their application a step further, providing company wide data collaboration. We are incorporating an ERP system, so that's where all of our data is going to have to reside.


A little off topic, but I would value your input:

Have you automated any drawings, or are you just tweaking parts and assemblies? I am just curious as to any problems you have encountered.

For example, let's say we have a template assembly with 10 parts. There is a master drawing that dimensions and balloons each of the items. Then, on a particular job, only 7 of the parts are required. So, we remove the parts from the assembly and update the drawing. I have found problems in which the balloons, dimensions, leadered notes and weld symbols for the deleted items are still left dangling on the drawing. Does this problem go away using your techniques? I had to write a custom routine to traverse through the drawing items, finding and removing the dangling items. Now that it's done, it's not a big deal, but I am sure that others may encounter this problem as well. DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

dsi,

<Snip>
Have you automated any drawings, or are you just tweaking parts and assemblies? I am just curious as to any problems you have encountered.

Yes, I'm making drawings with these models, I'm design and automating. Yes I have been running into problems with the drawings.

<Snip>
For example, let's say we have a template assembly with 10 parts. There is a master drawing that dimensions and balloons each of the items. Then, on a particular job, only 7 of the parts are required. So, we remove the parts from the assembly and update the drawing. I have found problems in which the balloons, dimensions, leadered notes and weld symbols for the deleted items are still left dangling on the drawing. Does this problem go away using your techniques? I had to write a custom routine to traverse through the drawing items, finding and removing the dangling items. Now that it's done, it's not a big deal, but I am sure that others may encounter this problem as well.

Yes, I have run into this. If I go from 10 to 7 parts it leaves dangling dimensions.

What I have done is, if there is a view in a drawing that may portray a different Assembly Config. I go ahead and make the model resemble that config, and SW update’s the view in the drawing. Then I tag all Dims to it. When I change the model back, those dims become dangling, but I leave them in the master drawing file. I do this for every view. Some views are going to have dangling dims depending on assembly configs, and some of them will be constant all the time. Depending on how the user designs the model in the program. Once the user finishes running the program and updates the model, they open up the drawing. Then the drawing will update to the new model designed by the Designer or Engineer. The user deletes the dims that are left dangling. They clean up all the views, by either moving dims to a proper place on the drawing or add dims that need to be added. While some views need to be switched to the active config to show the true model that they want it to portray.

EX:
Let’s say I have a pipe with 4 holes down the side equally spaced. In the Drawing I have made a view, that shows the 4 holes of that pipe. I tag the overall length of the pipe, the 1st offset of the 1st hole, and the distance between the 1st and 2nd hole. That is all the dims I add. If a user runs the program and decides he only wants 3 holes instead of 4…No Problem! The drawing updates and the user still needs the dims running all the way across from hole to hole. (Architectural designers still use all dims even if they are given the overall length) This is where the user will clean up the drawings not only by deleting Dangling Dims and moving them to a better location, but also by adding the dims he or she requires completing a job.

It's been a real hard task here at the company I work for. Even with all these programs I have wrote in SW, I still have to deal with a bunch of Old Faithful AutoCAD Users. This has been a real pain. Management has been saying Automation, Automation, Automation and the Designers thought they would push a button and do absolutely no work. So who catches the crap from the Designers...yes me, but the experience I have received by doing this automation has out weighed that.

I have been working with the people that are running these programs lately, and even though they are not crazy about the idea of manually removing, adding, and or moving dims, they have decided that they are going to try an be more cooperative. (Someone feel my forehead I think I’m going to faint.)

So slowly and hopefully surely they will soon “GET IT”!!! Some have already got the SW bug, but they won’t let those users use it yet. <Shrugging my Shoulders> >:-<

Oh well I hope this has answered your questions, if not let me know!!
Cheers,
Scott Baugh, CSWP
George Koch Sons,LLC
Evansville, IN 47714
sjb@kochllc.com

Scott:

I know exactly how you feel! We, too, have a few &quot;Old Faithful AutoCAD Users&quot;.

I just wanted to make sure that I wasn't the only one running into these problems. Like I said, I have written some code that will automatically delete the &quot;dangling&quot; items (dimensions, leadered notes and weld symbols). When I get some time I will extract the code from the main application and put it into a macro file. Once I get it working in macro mode, I will post the code for you. All you'll have to do is link one of the user's macro buttons to the module and they can save a few minutes. DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

Scott:

I put the code to remove dangling items in faq559-153. Hopefully this will help out some of the more resilient users. DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.

Thanks Dsi...I posted this hoping that I could help someone else, and it turns out you helped me. :-D If I can ever help you out just let me know.

If anyone would like some help in this manner of automating, feel free to send me an email.

Thanks again Dsi, Scott Baugh, CSWP
George Koch Sons,LLC
Evansville, IN 47714
sjb@kochllc.com

Scott:

Glad I could help. If you want to help, just keep up the good work and remain a member of this forum. ;-) DimensionalSolutions@Core.com
While I welcome e-mail messages, please post all thread activity in these forums for the benefit of all members.