Blocks and multiple visibility

[GIB39]

Hi

 

I'm getting back into cad and starting to develop some dynamic blocks. Can anyone give me some tips on how to do multiple visibility parameters in LT possibly using look ups. Should I be using blocks within blocks if that makes sense?. Does anyone have any ideas for creating electrical distribution boards using dynamic blocks with attributes. Your help would be much appreciated. Thanks.

[Dana W]

Unfortunately one can't get too complicated with visibility states. You can have only one visibility PARAMETER in any one block, whether it is in LT or full AutoCad, but you can have multiple visibility ACTIONS attached to that one parameter. And, the visibility parameter is itself a look-up (drop down list) which is built by picking the visible and invisible objects for each action.

 

I may be doing it wrong, but I have never once gotten a nested child block to keep any of its dynamic functionality while living inside another parent block. What I get is the child block's basic default state upon insertion, with no dynamic grips showing. Apparently the child parameters don't become parameters of the parent block, and that includes Annotative scaling.

[GIB39]

Hi Dana thanks, that's what I'm struggling with tbh as well. Hopefully the more I tinker on the more it all makes sense and becomes more user friendly.

[steven-g]

Can you post a dwg with a good description of what you are trying to achieve. There is apparently a Lisp around that at least used to allow the creation of multi visibility blocks but that is only in Full Autocad, and it does give some people problems. Multiple visibility is not a built in feature. But you can do various tricks in LT it all depends on what you are trying to do?

[GIB39]

Can you run LISPs in LT?

[steven-g]

Nope I only mentioned it to show that even in Full Autocad multiple visibility states isn't a standard option, and a Lisp someone created still gives problems, it's not what dynamic blocks were designed to do, but you can sometimes fake it.

[GIB39]

It's just a dynamic block to represent say a number of different size distribution boards (schematic view) some with a meter some without. If I could have a block with a drop down for each size and a separate option to show a meter that would be great.

[Dana W]

It's just a dynamic block to represent say a number of different size distribution boards (schematic view) some with a meter some without. If I could have a block with a drop down for each size and a separate option to show a meter that would be great.

That sounds easy.

 

Before applying the Visibility Parameter, get ALL your objects into the block editor. At this point, if any other parameter/action thingies are needed, like stretches for instance, do them before the visibility stuff. You'll want to include the stretch grips and parameters in each relevant visibility state. I simply avoid selecting ANY dynamic grips to be invisible.

 

Then proceed. You can place the visibility parameter anywhere, and then move the visibility grip where it will be easy to see in modelspace, once all the stuff is in there.

 

Once the visibility parameter is in place, in the block, there will be one default visibility state. Re-name it what you wish, if you wish. Then add the other visibility states, one at a time. Re-name them anything, like BIG BOARD WITH METER, LITTLE BOARD WITH METER, BIG BOARD NO METER, ETC.

Then select the proper current visibility state, and tell the program which items to show/not show in that state. Then move on to the next state.

 

I have found it easier to draw (or insert, copy/paste, whatever) ALL the objects in the block side by side before selecting any visibility. Then I move the objects within the block to where I want them to appear in each state AFTER I am happy that the appearing and disappearing is working the way I want it. It is easier to pick out (eventual) overlapping objects before they are on top of each other.

 

To follow through on my examples, I'd draw the big board, then the little board beside it, then the meter beside that. Once the objects are appearing and dissapearing propperly, then move each object smack on top of each other if that is where you want them.

 

It's pretty intuitive once you've done a couple in a test drawing.

 

Make FULL use of the TEST BLOCK feature within the block editor.

Edited August 10, 2018 by Dana W

[Dana W]

Here is a block I did with five visibility states (not 5 visibility parameters).

 

It is in Imperial units, with units display set to decimal.

 

It has two stretches, one for width and one for length, and a non-plotting note.

 

I do Commercial cabinetry and millwork drafting, so this block is a simple plan view of a plastic laminate kitchen counter (PLAM = Plastic Laminate).

 

The visibility states all have to do with how the backsplash (blue line) is displayed on the counter plan view, depending on where the walls butt to the counter. A counter will usually have a 4" high "backsplash" along each edge that adjoins a wall.

 

This block probably saves me 2 minutes per straight run of counter I have to draw.

 

I have other blocks that pretty much fill up the whole break room/kitchen with cabinetry; plan views, elevations, and sections. This includes cabinet door and drawer elevations with three visibility states and two, 2 way stretches, that is they stretch in two directions from the middle at the same time, with one grip adjustment. There is one 2 way stretch per axis (2D X, Y).

 

We also do a ton of high end completely custom work where I don't get to use blocks at all.

Counter top Dynamic Block.dwg

[GIB39]

I am currently not at a PC to try this but this sounds like what my fall back plan would of been. I thought I could of rationalised the list distribution board sizes by half if I had a separate meter option as well if that makes sense? I'll respond later when I get chance to look through your post properly. Many thanks for responding.

[GIB39]

Can you tell me if i am able to use blocks with attributes and parameters within dynamic blocks? Thanks

[steven-g]

Attributes are definitely possible, but I think LT is restricted to just viewing existing parameters and can't create them. Here's a block with various drop-down menus, it's a door block I made a long time ago for keeping track of door opening sizes from site surveys, it uses Dutch so might be a bit hard to follow, but it basically lets you put in door opening sizes to visually see if a door leaf fits within the opening, but it has a few drop-down menus, to let you select room names, floor levels, door numbers, also choose the fire rating type of handle used (all text-based). And visually it uses drop-down menus to let you choose the door handing (or sliding door) architrave (yes/no). Plus dozens of attributes for keeping an inventory list of many of door properties. This was a great help when I used to be producing door lists.

DoorBlock(old).dwg

[GIB39]

Hi steven-g thanks for that great block, i certainly think i can utilise lookup tables once i know how they work. One query is that i have to regen the block everytime say the door number is changed, is this normal?

 

I also have a number of similar symbols (blocks) which i was thinking of creating dynamic block for, is the best way to create these using blocks in the dynamic block, dynamic blocks in the dynamic block or just use exploded entities in the dynamic block? I'm not sure if its possible to have a block with parameters and attributes in another dynamic block and make those parameters functional? i cant seem to get it to work.

 

Is just knowing where to start as i can see me changing my mind as I'm going and having a lot of abortive work

[Dana W]

Before applying the Visibility Parameter, get ALL your objects into the block editor. At this point, if any other parameter/action thingies are needed, like stretches for instance, do them before the visibility stuff. You'll want to include the stretch grips and parameters in each relevant visibility state. I simply avoid selecting ANY dynamic grips to be invisible.

There is more to this part, and since I don't know your experience level, I will go ahead and elaborate at least for those just trying it out for the first time.

 

If you don't plan to have any items overlapping or right on top of each other, then this part is a no brainer. If you do have items that are going to overlap and hide each other in the block editor before the visibility conditions are applied, they will be difficult to select for the visibility states.

 

Place them close to each other so anything like stretch frames can be applied to them together, making the stretch frame large enough to accommodate the moving, then once the visibility states are set, then move them to their final positions on top of each other.

 

I ran into this problem while putting together a block for a detail section of a cabinet door with three different center panel configurations, a simple flat slab, a shaker style, and a raised panel door.

 

Since all three sections occupied the same space in the editor, I drew all three configurations up very close together, side by side in modelspace, then used them as the objects in the Create (Block) feature.

 

I first applied all the stretches and things, including two cabinet door hinges with move parameters, and then did up the three visibility states, then moved the "shaker", and the "raised panel" configurations smack on top of the lowly simple slab door section.

 

Since my stretch distance parameter was vertical, my three section views were placed side by side at first. Then moving them horizontally to be on top of each other didn't corrupt the stretch distance parameter.

[Dana W]

Attributes are definitely possible, but I think LT is restricted to just viewing existing parameters and can't create them. Here's a block with various drop-down menus, it's a door block I made a long time ago for keeping track of door opening sizes from site surveys, it uses Dutch so might be a bit hard to follow, but it basically lets you put in door opening sizes to visually see if a door leaf fits within the opening, but it has a few drop-down menus, to let you select room names, floor levels, door numbers, also choose the fire rating type of handle used (all text-based). And visually it uses drop-down menus to let you choose the door handing (or sliding door) architrave (yes/no). Plus dozens of attributes for keeping an inventory list of many of door properties. This was a great help when I used to be producing door lists.

What parameters are we referring to, if you would explain further please?

[Dana W]

One query is that i have to regen the block everytime say the door number is changed, is this normal?

You mean like changing the prompt and/or default attribute value or adding new attributes?

 

Yep. it is normal, but you don't need regen. Try the command ATTSYNC in modelspace, after the block attributes have been modified in the block editor. ATTSYNC will ask you to select a block, or type in a block name. Then it will ask you to confirm, (I think), and it will synchronize (correct) all the attributes in all the occurrences of that block in the drawing at once.

 

ATTSYNC will not change any of the user entered variable data typed into the attributes during or after insertion, it will only show changes in those blocks where the attributes were left at default values after insertion or where new attributes were added.

 

For instance, you have a block that is a title block and border line which gets inserted on each layout. You have five layouts with the block, but only one of them has had the page number attribute edited to "01" The rest of the page number attributes still read "XX" which is the default value you entered when creating the block.

 

You decide the default value should be "PG" instead and change it in the block editor, and save. Then you notice that page 2 through 5 still read "XX".

 

Execute ATTSYNC, and all of them except for page "01" will be changed to "PG" all at once, then you will lecture yourself for not editing page 02 through 05 as you created each new layout,

[Dana W]

Like I mentioned before, if you nest (insert) a dynamic block into another block, the nested one will lose all of its dynamic functions. You'll have to explode it, and add back in the dynamic functions as part of the parent block.

 

This also applies to annotative scaling. You can have a block that will scale annotatively, that is, change size depending on the view scale, but if say, annotative dimensions and text are used inside of a block, they will not scale annotatively by themselves. However, they will change size depending on the view scale along with the rest of the block if the whole block is annotative.

[Dana W]

It's just a dynamic block to represent say a number of different size distribution boards (schematic view) some with a meter some without. If I could have a block with a drop down for each size and a separate option to show a meter that would be great.

 

How about one block for all the different size boards with a meter, and another block without the meter.

 

Within the block the visibility states for the boards will be one for each size. Rename each visibility state to the size of the board it shows visible and select all the other boards to be invisible for that state.

[steven-g]

What parameters are we referring to, if you would explain further please?

Hmmm confusing, I thought the OP is referring to the parameters associated with the parametric tab in the ribbon or menu, so dimensional or geometric constraints(or user defined in the parameters manager), and these to the best of my knowledge can't be created in LT. But then you also have the Parameters/Actions in the dynamic block editor which of course LT can fully utilize.

[steven-g]

 

Is just knowing where to start as i can see me changing my mind as I'm going and having a lot of abortive work

 

I have to be honest, although you can do some amazing things with dynamic blocks, the original intention of blocks is to save time and memory by having repeatable content, but experience has shown me that you can spend many hours even days and weeks, creating really complicated extravagant blocks that do everything, when in reality several simpler blocks would perform just as well and take a fraction of the time to create the only difference being you have to select more blocks when using them.