Glitchy Dynamic Blocks?

[Anonymous]

Hi,

I have created some quite complex dynamic blocks using stretch variables to create a dynamic parts list for products we make. I have found that a block works fine until I paste it to another file (purged, blank files) when it sometimes gives incorrect values. Has anyone else found this? And has anyone a recommended way to stop it happening?

I have also tried to make stretchable dynamic blocks with hatches, which almost never work once duplicated into a new file too; they become strange and unmovable and change draw order. I have checked my Blocks and there doesn't appear to be an issue with how I have created them, I wonder if others have had the same problem?

Cheers,

[steven-g]

Dynamic blocks have been around for a long time and in general, are very stable and reliable, if you are having some issues it would be best to post a copy of the blocks and explain how we can try and reproduce the problems.

[timothy_crouse]

I have seen odd behavior in dynamic blocks. It seems the more complicated it is the more chances there are of it becoming glitchy.

One technique you may find helpful to transfer blocks between drawings is to create a block of the dynamic block.  Cttrl+ C  >> Crl + Sht + V.

Copy that nested block to the other drawing.  Transferring it as a nested block stops the block from resetting to a default state.

Sometimes you may find it useful to WBLOCK the dynamic block out then _classicin it into the drawing of choice.

On my systems, I see issues more often with dynamic blocks that have attributes inside of them.  Depending on the situation copying and pasting into a second drawing literally strips the attributes of the block.  Autodesk has not found any solution for this that has been relayed back to me.  I have open multiple support cases related to dynamic blocks or the dynamic block editor and they seem to fall into the black void.  After the first tier support looks at them and has no answer they state they have forwarded it to the developers for further review.  So you pretty much have to find workarounds for buggy dynamic blocks.

Hatch stretching is another area that becomes buggy.  My workaround for that is to create a hatch boundary that gets stretched (be sure not to include the hatch in the selection).   The hatch boundary is then turned off for all visstates.  The object lines that need to be displayed are duplicated on top of the hatch boundary.  The hatch seems to behave better inside closed boundary vs individual object boundary containers.

If you are interested in some of the techniques I use look under the "Share your dynamic" thread.  I have many posts there.  One of my later posts is related to Data Center Building blocks.  There is a raised access floor tile block with many visstates and many hatches.  It took a couple of attempts to get it to be stable in acad 2018 then a bit more to get it to be stable in other versions.  I agree that things should not be breaking when going between different vs but it has happened and to that end, time was spent fixing bugginess.

My last tip for you is to never work on a dynamic block in a drawing that has multiple dynamic blocks.  There is an issue with the block editor that will add duplicate objects to dynamic blocks.  You will know when this is about to happen from inside the block editor when:

-you try to select a parameter action but the cursor is prevented from hovering directly over the action icon

-many objects stay highlighted, REA will not clear the highlighting of the objects.

Close the block editor purge the drawing and Ctrl+S to save  >> Restart Acad

If you open the file and it asks to recover DO NOT allow it to recover this is the  point that the duplicated objects

are added to ALL the dynamic blocks in the drawing.

Purge the drawing and Ctrl + S.  Close Then reopen the file

Sorry for the lengthy reply :),  it is frustrating that Autodesk will not fix this behavior.  Searching through the forum you will see this has been an issue for 10+ years now.

Best Regards

-Tim

[Anonymous]

Could you please share the file to test and maybe a screencast of the issue and expected behaviour as well.

[Anonymous]

I have attached below an example. This block is an aerial view of a cupboard with an open door. The door is at a fixed angle and the intention is that the solid white hatch should match the width and depth of the cupboard.

I would be please to know what I am doing wrong here. It appears to work in some circumstances but not others!

[timothy_crouse]

This turned out to be more of a mis-application of hatch and parameters,  see the revised file.

Best Regard

-Tim C.

[timothy_crouse · Accepted solution]

A second look at the file:

It turns out there was something a bit off about the file.  The hatching would not behave correctly no matter what I did to attempt to fix it.

The v2 has the door set flat such that it is resized with the enclosure, then you can rotate the doo into position.

It was simpler this way as stretching the door at the predefined 20 degree angle was mis-shaping the door.  The quick fix would be to use constraints but they bring there own set of issues.  So this was the compromise.

I also tried having the with a chained stretch linked to the enclosure width but it too was a bit wonky.

anyways, hope this helps

Best Regards

-Tim C.

[Anonymous]

Thanks Timothy, making a door which scales to size first and then rotates makes a lot of sense. And I see what you mean about version 1, it still has a few of the issues.

Thank you for your help here!

[c1041485]

three years later and the situation is still the same. Dynamic blocks are just a big waste of time. They cannot be transported from one drawing to another because every time you do it you only create problems and then it takes you less time to do it all over again.

[timothy_crouse]

Dynamic blocks may truly be glitchy or some of the glitches comes down to work flow.

Admittedly dyn blocks with visstates & attributes require planning regarding re-use between drawings.

The block revert to an original state when pasted into a new drawing.  Depending on how you setup the block you may be able to access the setting via the properties panel there-by making short work of setting up the blocks as required. 

Dyn Blocks without attributes may not appear to be so glitchy.  

I find when money is on the line and something like a dynamic block could open you up to a change order due to a block being set in the wrong state (Eg a door facing the wrong way)  or a length of a dynamic equipment block is set at the wrong length it is better to use the dynamic block as tool to get the graphics you want then explode the dynamic block and turn it into a standard block.

My 2-Cents

Best Regards

-Tim C.

[mcumborRL89D]

Dynamic blocks are garbage & infuriating. Constantly screwing up draworder & losing 'shape' when adjusting stretch, scale etc. Full fat Cad is £6k and is, and always has been, full of bugs in my experience. AutoDesk are seemingly incapable of fixing anything but every year manage to roll out more & more bloat. The internet is awash with posts questioning problems and almost always the sycophants insist it's the user and their equipment that is at fault.!

[michael_kamback]

For the past couple of weeks I've been attempting to create a LISP expression that will auto-dimension blocks from the nearest polyline on a chosen layer. The blocks are simple rectangles (one is 2'x4' and the other is 4'x4'). I need all the auto-generated aligned dimensions to be snapped from the closet edge of these blocks to the polyline. I was pretty quickly able to create an expression that reliably auto-dimensions all the standard blocks, but the newer dynamic blocks that are being used more often in our projects have been seemingly impossible to account for in this expression. I'm able to calculate the position/rotation of the standard blocks, determine the closest point from the polylines and then auto-generate aligned dimensions between the two, but the dynamic blocks with rotation grips are never dimensioned correctly. I've exhausted every possible avenue that could be causing these inconsistences but have found no solution to the conundrum. Interestingly enough when the custom LISP command is executed, the field of view seems to be the biggest factor in getting different results, but none of the results are reliable to be used in drawing production. It's particularly unfortunate that these dynamic blocks aren't able to be integrated into some of the LISP expressions I've been using reliably with standard blocks. If anyone has and experience with this issue I'd appreciate a reply.

                                                       Thanks,

                                                            - Mike

[Brock_Olly]

You should create a fresh post and supply us with some example drawing and I'm sure people here are willing to help you out.
I've also found a few auto-dimension lisps on sites like the swamp that could help you out.