Jump to content

Dynamic Block with Dynamic Attributes


McTodd

Recommended Posts

Hello,

 

I posted this in another thread, but I think it has gone stale.

 

I have a problem whereby I would like to be able to change the default attribute when using a dynamic block. I spent ages on the learning curve trying to get it to work, I created a block that seemed to do everying I wanted and I did a "WB" (writeblock) to a file and inserted the block into a drawing to find the attributes did not change like the original block.

 

I have set up three different visibility states to hide the attributes and to effectively change the code for each type of block (in this case, light fittings). I know I can do it with text, but I want the flexibility of being able to change descriptors. There may be more than one similar type of fitting for example.

 

Anyone have any ideas?

 

Is it just a fundamental lack of understanding on my part?

 

If I "attsync" the block, the same happens.

 

Surely this is a pretty common type of use for dynamic blocks and there is a workaround or a fix.

 

In the attached drawing, the top left fitting is the originally-defined block, with a direct copy of it below. The fitting on the right is an inserted block. You can see the type descriptor change for the original and the copy of it, but not for the fitting that was done by block insertion.

 

Any help appreciated.

 

Todd.

Dynamic block Eg 2.DWG

Link to comment
Share on other sites

I opened your drawing did a wblock on your original and then inserted it back in. I got the same results as you did. I also placed your original on my tool palette and brought it in that way with the same glitchy results.

 

I took a look at the block and can't find anything wrong (I'm by now means an expert with dynamic blocks). One thing I would ask is why did you use editable attributes rather than just text. I'm not seeing the advantage unless you plan on manipulating the block with your move parameters and then editing the attributes. Are there that many different configurations that would warrant this? Hope you will take this text/question as me trying to understand and help. Sometimes text doesn't convey what a person is trying to communicate - body language, tone and all that being missing.

Edited by Ryder76
grammer dag nabit
Link to comment
Share on other sites

Ok took another stab at it....

 

What I did was erase everything in your dwg except the working block; then, I purged the drawing and saved it with "NEW" on the end of it. Next I inserted this dwg in a blank drawing and made sure the 'explode' box was checked when inserting. This brought the block in and made it available to use as I think you intended. Another thing I did was move the block by it's basepoint to the 0,0,0 position in it's respective drawing file. Previously when I inserted it would come in at a location far from the crosshairs.

 

I am attaching the "NEW" file. Hope this helps. I can't explain what was wrong, but if you insert this drawing as your block and check the 'explode' box it will come in ready to use. You can bring it in without checking that box, but you will need to explode the block before you can use the dynamic aspects of it.

 

Dynamic block Eg 2 NEW.dwg

Link to comment
Share on other sites

Thanks,

 

I think the "encasement" in the second block definition seems to be protecting it. If you explode the block after it is ddinserted it works a charm, thanks for that, it is not something I had tried.

 

However, if you then insert the block itself, it goes all weird again so it does not exactly solve the problem but we may be able to work around it. I can put the "encased" block onto a toolbar with a lisp or script to insert it and then explode it straight away. It does limit me to what I can do because I can't have a lisp linked to a tool for every possible block we use and it would be annoying to have to "explode last" randomly.

 

It is bizarre that to copy the block works but to insert a new one, it doesn't. Warning! May contain traces of nuts!

 

The whole idea behind the variable attributes (as opposed to text) is that we do a data extraction for a bill of materials for tendering contractors and there may be, for example, two twin 28W troffers which differ in regard to diffusers or finish (or something) but essentially they are the same block. We want to limit the number of blocks to something manageable, so being able to simply edit the attributes makes things simpler - there are THOUSANDS of permutations.

 

A reliable data extraction is a whole other problem - R2005 did a perfect job and they holed it in R2006.

 

I would have thought this would be an extremely common thing to want to do. It seems logical that if you have different items - say bolts - of varying length then the item descriptor should change according to the visibility state and update the Bill of Materials.

 

I have another little company (public electrical infrastructure construction) that uses a limited number of light pole and luminaire types (just as an example). We have a library of those pole types and all the nuts and bolts and washers, terminations etc are included in the blocks as we insert them. At the moment, we insert the block that corresponds to the column, height, outreach and luminaire type we want. There are only a few pole types, a few mounting heights, a few outreach types, a few lamp types and a few luminaire types, but as soon as you consider all the permutations, it gets boggy. We have three screens at each workstation and one is dedicated to toolbars full of blocks with associated lisp to insert, rotate, offset etc as they are drawn. Dynamic blocks would sort the whole thing out quite well except it just does not work.

 

Anyway, it is a silly problem that just does not seem to have a decent solution at this stage. If Autodesk was not such a behemoth, it might be possible to request a bug fix. I did that with Bricscad once and a week later they emailed a message with thanks for pointing it out and a link to a point release with the bug sorted. Pity we have a couple of of incompatible customised applications.

 

Anyway, I will keep working on it. Might have to try a different tack with how we design but it is hard to fundamentally change the way people work and implement completely new procedures across the board.

Link to comment
Share on other sites

Hey McTodd, welcome to the forums, i took a look at your block yesterday and couldn't immediately find a solution, i took a look again today and i think i've found it!

 

The key is the way you create the block, the "correct" way i think is, first make the visibility state, then in each visstate make a new attribute (no copy/paste!), so you'll have to delete the attributes you have now and start again.

Also very important is to purge your drawing (PU) so no old version of the block is left in it.

 

Attached is a small test block i made, i saved it with Wblock, re-inserted it, copied it... i can't break it anymore :).

 

good luck!

test.dwg

Link to comment
Share on other sites

Thanks,

 

I have managed to do the same and actually gave the same answer to someone else in a similar thread. It is quite mad that attributes behave like this when normal drawing objects don't.

 

However, having found a solution, we find it was a complete waste of time because data extraction does not differentiate between the attributes in the varying visibility states. This is utter madness - surely there are many instances of people wanting a bill of materials from drawings with dynamic blocks.

 

There is the additional problem of us having hundreds of blocks; being unable to copy attribute definitions makes the whole thing completely unworkable.

 

This makes two fundamental flaws.

 

Looks like dynamic blocks really need some work before they are actually useful in the real world in many instances.

Link to comment
Share on other sites

Hey McTodd, at my work i also draw electrical installations and we use data-extraction to make a bill of materials, the way we work is; for every different type of material (lighting,outlets,...) we make a separate block with a fixed set of attributes (circuit nr,text,type,...) we only use the visibility states to add options, for instance on a lighting fixture we use the visstate to add options: emergency lighting, dimmable on a power outlet we use it to add a letter which indicates if it is surface mounted or recessed and so on.

 

1 tip for data-extraction: make sure all the attributes of all your blocks have the exact same name, otherwise you will end up with loads of different colums.

You can make the dynamic blocks work for you but it's a whole lot of work and needs a lot of thought to implement correct.

 

good luck!

Link to comment
Share on other sites

Thanks,

 

We already have data extraction working quite well with non-dynamic blocks. All our materials are ordered from data extraction. Every nut, bolt, washer, lug, lamp, luminaire, connector, cable etc is embedded in the assemblies the blocks represent.

 

It would have been nice to have been able to use dynamic blocks to simplify the library of blocks we have to maintain (reduces the chance of errors too).

 

for the second company, I have limited the attributes to a key field an accessories field and an "additional" field and then linked the codes to a database, so the columns basically all come from that database. It is quite elegant really. Again, dynamic blocks would have been ideal if attributes worked properly. It is not to be, I have developed a workaround.

 

Anyway, it has been an education and we have put dynamic blocks to use in other ways now that I have become familiar with them.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...