Independent control of the same model

Your assembly may consist of many parts. And some of those parts may exist in that assembly as the same file (an instance). Now this scenario is totally acceptable as long as the parts which are the same file remain the same file in each clone produced automatically.

However, you may want those same files to behave individually, i.e. not have the same results for the rules put in place.
Take the model below for example. It is made up of various lengths of I-Beams. In the main each I-Beam used are the same length, but sometimes the I-Beam that falls at the end of the run needs to suit the remaining distance.

In this situation the master component must be given a unique name, something that sets it apart from its sisters. If this is done the same parameters can be captured, but different rules applied for their behaviour.
But what if the rules for this component can result in the same value as its sisters? You don't want a separate line item in your BOM for an identical part.

This can be overcome by giving some thought to your rule for the File Name of each part.
The list below represents a simplified view of the assembly structure: -

• Main Assembly
  
  • IBeam
    
  • IBeam End
    

The rule to calculate the IBeam length is = (OverallLength – EndDistance) /BeamQty
The rule to calculate the IBeam End length is = EndDistance
Now when OverallLength is 3000, EndDistance is 500 and BeamQty is 5 both of the above rules will equal 500.
And if these rules are also used for the File Name parameter of the two files it will result in the clones being produced, named IBeam 500 and IBeam End 500.
Not ideal for a bill of materials when these two components are the same.

What we want is for the IBeam End file to have the same name as the IBeam file, as you can see from the resulting clone file names, all that is different is the word End, used in the master file. To remove this DriveWorksXpress allows you to use the wildcard symbol. Using this at the start of your rule will remove the entire original name, all we need to cater for is to include the portion of the original name we want to keep. So the File Name rule for our IBeam End component will be: -

= "*" & "IBeam " & EndDistance

"*" will remove the original file name
& is used to join text, functions and named ranges together
"IBeam " is the file name description we want to add back into the file name. Note the space before the end quote, this spaces out the description from the number.
EndDistance is the calculation that results in the length of the part.

Hope you find this useful.

Sharing Master Models

In my Naming the Master Models post I advised that master models can be shared across different assemblies.

The information captured from the models will be identical in each assembly it is used in. Whatever is captured from the model in one assembly, will appear in the model from the other assembly.

Although the captured information remains the same the rules will not. This is because there is a very high chance that the behaviour of some, if not all, of the parameters will be different between all the assemblies the model exists in.

So with that in mind don't expect to see the rules applied to the model in one assembly to ripple through to the same part in the other assembly. You will need to apply the rules again.

A good example of this can be seen with the 2 different window designs below. They both use the same extrusion model to form the top member. And both extrusions have the length controlled by DriveWorksXpress.

But in the single window the length of the extrusion is calculated by the rule: -

Opening Width – (2 * SectionDepth)

While in the window with the centre mullion the length is: -

(Opening Width – (3* SectionDepth))/2

Here is an Idea...

Do your customers use your products within their own designs? Do they use SolidWorks? Would they be more inclined to use your products if they could design them?

Using DriveWorksXpress to automate your designs internally has great time saving benefits. But if your customers could specify your products themselves, and instantly get a good representation to use within their design; would that increase your sales?

Obviously you would not want your IP, the design intent, the rules to get into your competitors hands. So now you have a project that does create all of your engineering data, why not create a dumbed down version that your customers can use?

Take a steel door for example, in house we need the developed (flat pattern) steel sheet that form the door blade to have all the punched cut outs for hinges, door furniture, apertures for windows, louvers, etc. The assembly needs to depict infill materials used, reinforcement positions, fixing lugs, etc.

Your customer does not need that much detail he may just need overall frame size, clear opening through the door, how far the door swings and relative positioning of furniture.

So instead of a fully engineered assembly consisting of many parts – you could probably get away with a 3 or 4 component assembly and the rules to drive this would just consist of simple maths and not disclose the real engineering rules used to design the product.

You could even drive a custom property value that creates a code you can use to enter into the full automation project once the order is accepted.

Naming the Master Models

The name you give the master models will allow you or anyone else to easily identify rules that need to be applied or maintained going forward.

There are a few points to keep in mind: -

1. The name you give the top level assembly is used to identify the rule set.
2. Sub-assemblies and parts can be shared across multiple assemblies.
3. Models that need to be controlled independently must have different names.
4. The original name can be overridden for the new file that gets created.
5. Assemblies cannot have the same name as parts.
   

I'll explain some more about the other points in subsequent posts, for now I'll start with the first item.

Rule Set identification

This is critical if you have many products in the database. If your database just contains one product, clicking run from the welcome screen on the DriveWorksXpress wizard will take you straight to the inputs required to specify that product.

However, chances are you have more than one item that can be automated. The Lintel example on the DriveWorksXpress website shows a good use of descriptive naming of the top level assembly. Here we have 5 very different models that can be selected for automation. Each one has a clear name given to the top level assembly that helps the user select the most appropriate one for specifying.

Once selected the user forms and rule set to automate that product are loaded and can be ran to generate the new engineering data.

Sharing

So, you have automated your product and are pleased with your results.

What about letting some of your colleagues in on the secret of your newly acquired ability to get work into production at lightning speed?

You have a couple of options available.

1. Work from a common location using the same files.


2. Distribute the files amongst your colleagues.

The first option is not straightforward. The main drawback of this is that the same database can only be accessed by one person at a time. This is a limitation of using Microsoft Access, and one that is overcome by DriveWorks (full version) and its adoption of the SQL Server databases. So once a DriveWorksXpress database is opened on one machine, SolidWorks will need to be closed down to release the database for another machine to open. Painful.

My personal recommendation is to distribute your files. But to do this effectively I recommend the following: -

1. Create a common directory on your C: that can easily be created on all the computers on the distribution list. C:\DriveWorksXpress for example.


2. Create or Move your DriveWorksXpress database into this folder. (the .mdb file)


3. Create sub folders within this folder to store the models of each product that will be automated.

Using this method also means you can be further developing the rules while others are reaping the benefits of what is currently automated. Over the coming days I will be giving advice on naming, so the essential files can be easily located for distribution.

Under the hood

I think the best place to start this journey into design automation is at the beginning.
I want to explain what is happening behind the scenes in DriveWorksXpress as you capture parameters, construct the user form and apply the rules that automate your designs.
When DriveWorksXpress is launched for the very first time a Microsoft Access database is created. By default this is stored in your My Documents (just Documents on Vista) in a folder called DriveWorksXpress; the database is given the same name.

Tip: The Welcome screen clearly shows where the current active database is located, but I recommend creating your own at a location that can be easily recreated on a colleague's computer so your work can be shared.

This is important because DriveWorks keeps a record of the full file path where each controlled model and drawing is stored. It needs this information so the file references, stored in SolidWorks, can be swapped effectively by DriveWorksXpress.

Now, if you have many products that you will be automating there is no need to create a separate database for each product. However you do need to be aware of how your master files are named. I will expand on this in my next post.

Here we go

More engineers each day are discovering the benefits design automation can bring through DriveWorksXpress.

The community site at http://www.driveworksxpress.com/ provides valuable examples, tutorials and forums for learning how to get the most from this tool.

What I want to do here, is give you help, advice and a good insight into just what can be accomplished with this powerful tool.

Stay tuned...