Dynamic Block with visibility states and file size issue

[Anonymous]

Attached are Cable Ladder Rack Dynamic Blocks with several Visibility states and a flip and rotate parameter. The blocks are only 147kbs and 167kbs but when I insert them into a design layout the file becomes @Anonymous,000kb. I have 230 instances of the "BOM-600mm Radius" and 512 instances of the "BOM-Non-Radius" blocks in my design Things I have read and tried to reduce this size include the following

• Scalelist edit - only 2 scales 1:1 and 1:100
• -purge, Regapps - nothing
• The mindblowing test is that when I deleted several Visibility states the block size actually got bigger
• The functionality of these blocks is great but file size is a huge issue

Anyone can troubleshoot the issue and provide a solution

[ahmed.abdelmotey]

Your block contains a large ammount of entities try using "Block Property Tables"
to set values of different parameters and actions .. this can significantly decrease the size of your block.
the only draw back is that you will need to modify your inserted blocks to match the new settings of the block.. so whether to change it to reduce file size or just keep up with it and avoid this problems the next time you use them

[Libbya]

Here is an example of how to greatly simply the block.  This example only has one set of linework and one visibility state and uses a lookup to create all the different sizes of crosses.  You could do the same for the various other views/shapes.  

[Anonymous]

Thanks to both of you! I will look at the sample look-up drawing ASAP that will probably answer some if not all of my follow-up questions. Without looking at the sample drawing (can't access autocad until tomorrow hopefully) I am thinking

• I Wouldn't I create a lookup table for all the visibility states because that would be redundant and probably add to my file size?
• I am guessing I would keep just one visibility state per type of BOM (ie Horizontal Crosses, Horizontal Tees..) and make distance parameters along the perimeters that reflect the various sizes that would be used in the lookup table?
• Can you walk me through the steps you would use to create the lookup tables (never did these before) and again this may answer itself once I get into the sample provided

Again, thanks, I appreciate you

[Libbya]

I would set up the block in the way you suggest.  I would use visibility states to switch between the types and then use lookups to sctretch/scale/move the geometry as necessary.  The reason I would use lookups as opposed to a block properties table is that you can have more than one lookup table and make them contextual.  With the block properties table you can only have 1 and I believe it would be a fair amount more work to get worked out.  

When you have a chance, take a look at the sample file I linked.  If you have questions let me know.

[Anonymous]

Libbya,

I was expecting the sample block to be something random - you actually took the time to provide a sample with one of the blocks I posted - that is awesome and you have no idea how much I appreciate it. I have begun disecting it to reverse engineer it so I can continue on but before I do:

• How did you tie the stretch commands with the distance look-ups?
• If I am understanding correctly my next stpes would be the following: 

1. create visibility Parameter for the Crosses and then Horizontal Tees (as an example)
2. Would I use the same distance and stretch parameters as the crosses and modify the selection set or do I need to create new parameters for each component visibility state?
3. Create a new lookup table for the Horizontal Tees or add to the Lookup table you created?
4. Finally, you saw how I had a boat load of visibility states which when brought into a drawing 700+ times made my file 37MG - I won't hold you to it but if you had to guess - how much would my file size decrease with this new method? I just want to assess whether it would be significant enough to go through this excercise or if I should just go with a BOM library of independent components and throw them on a Pallette (old school)

Thanks again - I appreciate You! 

[Libbya]

The actions are added to the parameters.  The lookup controls the parameter values.  Any action or any number of actions can be added to the parameter that is being controlled by the lookup.  With complicated shapes I have turned grips on for the various parameters and worked with the various actions until the parameters stretched/moved/rotated the linework properly and then I turned off the grips, added the lookup and put in the proper values for the desired options.  

You can use a parameter in more than one visibility state and your block size will be reduced accordingly if you do.  

I would use separate lookups for the different visibility states for a couple of reasons.  One is that the list would be shorter.  The other is that setting up the lookup to control the visibility state also would be more complicated (although certainly doable) and having options on there for a different visibility state would not work.

I have no idea what the difference in memory would be with 200 iterations of the different block versions.  As far as it being 'worth it' I would mention that in my opinion, learning to use dynamic blocks, lookup tables, visibility states, etc... is worth the time and effort regardless of whether or not the end result meets the need.  I also believe that the ease of use of a well-crafted dynamic block with all of the various desired options easily accessible can save time and make the experience more enjoyable and that added value is hard to quantify.   

[Anonymous]

Libbya,

What is your recommendation for the content that have radius bends (elbows) - should I use visibilty states for these or look-up table? I can't figure out the action parameters to use for a look up table, particularly for the arcs within the bends.

Thanks

Tim

[Libbya]

Here's one way to set up the parameters for the elbows although considering there are only (6) 90° elbows and (6) 45° elbows I suspect visibility states would be easier and less memory.

[Libbya]

Oops, I posted the wrong version.  Here's the right one.

[Anonymous]

Libbya,

Thanks for the reply. I am in the home stretch and will soon be able to report the success or failure of significantly reducing my design file size. Regardless, you have been a tremendous help and I have learned alot about dynamic blocks because of the time you have taken to respond to me. I appreciate you!

I did go with the visibility states for the bends since it's just 12 pieces. Attached is a separate block for the reducers and wyes. Can you confirm that visibility states are the way to go with these as opposed to look-up tables as well. The geometry is so different between pieces I have no idea how many or what parameters I would need to utilize a look-up table for these. Unfortunately, there are quite a few variations which means keeping my design file size down will be challenging, but it seems to be a necessary evil in this case.

Thanks again

Tim

[Libbya]

If I were making that block I would have one visibility state for straight reducer, one for the left/right reducer, and one for the left/right wye.  I would use a flip to switch between left and right on the reducers and wyes.  Attached is a way to make the parameters work for the reducers.  

[Anonymous]

Libbya,

I would have never figured out the reducer parameters and still am having trouble seeing how you did it. Particularly, determining the thought process with the various stretch windows and Override values of the distance multipliers and angle offsets, but it is awesome.

Attached is the block you sent me with lookup tables added - when I get to the offset reducers the smaller sizes don't work properly ie 300mm to 150mm - it looks like when I put in those values hard coded in your native block it doesn't work as well.

Any chance you can take a quick look and give some more insight in how you determined the override values and see if you can figure out why the offset block is not working for all values?

I owe you big time for this education!.

Also, as a side note, since we will be using data extraction for determining our bill of materials, I think we need to separate the left hand and right hand visibility states, although I considered extracting the "flipped" status as a way of counting left vs right hand - what is your opinion? I started to try to use your left hand reducer to create a right hand reducer but am struggling a little bit, so maybe I should just go with flipped?

Thanks again for everything

Tim

[Libbya]

The reason for the lookup discrepancy is because I made a mistake in the previous version of the offset reducer.  The two main dimensions need to be able to be altered without altering the other.  Unfortunately I made it so that when you change the larger dimension, it changes the smaller dimension at the same time.

As far as the angle offset and distance multiplier adjustments, those are to compensate for the fact that you have that 30 degree section that makes up for the difference in dimensions.  In order to keep that at 30°, there are times when the linework needs to be stretched at that 30 degree angle (or 330) and the distance multiplier is the hypoteneuse length of a right triangle with a hypoteneuse at 30 degrees and long leg equal to 1.  There are times when the stretch needs to be perpendicular to the direction of the parameter and that distance multiplier needs to be the short leg of the same right triangle.

Here's a screencast that shows the process of the right offset actions and the diagnosis of flipping the correct actions.    

[Anonymous]

WOW! I will have to really slow that video down to duplicate the effort and appreciate the lesson. Any chance you can send me the updated drawing too? I am interested in learning the process instead of being just given the answer (learning how to fish as opposed to just be given a fish), but could benefit from the block you fixed as a comparison because I can tell it is going to be a challenge for me to replicate that video.

You are definitely a cad master, though

Thanks again for everything - Hopefully I won't need to bug you anymore and the next post will just be to deliver the design file size reduction results.

Tim

[Libbya]

I didn't actually save the file.  I meant to but the latest saved version I have is the one I posted.  The screencast was not rehearsed so it has some dead spots but I tried to incorporate various ways of doing things.  The small triangle I drew gives the values for the distance modifiers.  The Quickcalc from within properties is very useful for getting those values accurately.  

[Libbya]

I went back and played with that last block a bit more.  Here is a finished version that shows how I would set it up.

[Anonymous]

Libbya, Thanks for the completed block - I have been going through the screencast and have just grown in amazement of your knowledge. Going on 4 hours to dissect your 11 minute video - I guess I am not the sharpest knife in the drawer. I will let you know how the file size issue turns out when I complete my actual design drawing with the new block. Tim

[Anonymous · Accepted solution]

Can't thank Libbya enough - my design file size went from 38meg to 8meg going from all visibility states to a combination of visibility states and lookup tables - thanks for all your help and patience with a rookie to dynamic blocks. 

Tim