Dynamic Blocks with Constraints, Block Table, and Rotation Action

[Dynamically_Static]

I am having issues creating what should be a very simple and logical dynamic block.  The first part is easy.  I created a square that adjusts its size based on a block table selection.  I also have a piece of text that shifts with the change in dimensions of the square to keep it centered.  NO issues there.

So now on to Rotating it.  I have a few choice curses I've come to chant on this topic.  When rotating it multiple times using the grips it starts going off the rails.  You rotate it once... behavior is as expected.  Use the grips to rotate again... bam!  See the attached picture for the second 90 degree rotation. 

HOWEVER, if you just type in the rotation numbers using the Custom Properties for Transformer Rotation it works FINE. 

I cannot figure out why...  Any ideas?  

[Dynamically_Static]

Did not add the block for some reason...

[Libbya · Accepted solution]

It's because you mixed constraints and dynamic parameters/actions.  There's no reason for the constraints in this block.  It is easier, faster, and works more consistently if you make it using only dynamic parameters/actions.  Delete the constraints and replace with dynamic parameters/actions and it works perfectly.  In future blocks, you will generally have a much easier time if you avoid constraints unless the block cannot be made without them.  See screencast.  

[Dynamically_Static]

Beautiful.  

I'm trying to learn "the proper" way of how to do this and the few tutorials I started in for blocks indicated generating the constraints first.  Am I'm misapplying Constraints by using them with Actions and Parameters ?

I thought I was doing it right by starting with a well constrained block and then adding the actions...  is it either or and no mixing? 

(This may be a stupid question since I clearly just saw how poorly it worked when mixing them lol)

[Libbya]

There are specific cases where it can accomplish something that is otherwise impossible or difficult to accomplish, but generally, mixing constraints with dynamic parameters/actions is a bad idea.  Most dynamic blocks can be made more easily and will behave more consistently if no constraints are used at all.  In most cases, adding constraints to dynamic blocks will not do anything helpful and will actually cause the block to misbehave.  Learn to use the dynamic parameters/actions and avoid using constraints at all unless there is something that cannot be accomplished using the dynamic parameters/actions.  

[Dynamically_Static]

Libbya,

One other follow up question.  I am making a different, albeit similar block, that has to rotate more then just the 90 degrees needed for the sample block I uploaded. 

Making the CAD elements and other grips move isn't a problem... but the Block Property grip is not rotating no matter what I do... How can I rotate the Block Table grip when the block elements rotate?

[Libbya]

The block properties grip will always stay at the same in-block coordinates.  You can fudge that and make it 'move' by adding a basepoint parameter under the block properties grip, then add a chained gripless point/move to move the basepoint parameter.  The block properties grip will move accordingly.  You might also consider lookups instead of block properties.  They accomplish most of the same things but more than one can be added and they can be moved independent of the block base point.  See screencast.  The shenanigans at the end of the screencast have nothing to do with the lookup.  The linear parameters became bugged from moving them.  

[ahobby]

@Libbya

Hi there I saw your expertise on the question above and I have a sort of perplexing block issue along the same lines. I have a dynamic bolt but some some reason, I can get one version of it to have a nice "dynamic grip" with the block, but a different size fastener w/ a shoulder wont do the same. Is it only because it has 2 stretch actions?

Block is attached for your persual. Any help here would be much appreciated.

[Libbya]

When you have 'Block properties must match a row in the table", grips can only be displayed for parameters that have different values for every row on the table.  You cannot show the 'Threads' grip because Threads has 1 1/2 as the same value for 5 different rows on the table.  If the grip were visible and you switched Threads to 1 1/2 it would be impossible for the block to resolve itself as it would not know which row to switch to.  In the following screencast I add another linear parameter to control the block with its grip in that position.  

[ojuris]

No - it's because Threads column don't have all unique values.

You have 5 rows with value 1.5. How do you think what block must do when you slide with nice grip to Threads value 1.5? How Autocad can know what row it must choose?

[ahobby]

Thank you!!!

I figured it might have something to do with the shoulder value but I just couldn't figure it out. This is exactly what I was looking for. I realized as well that I had a user parameter of "Length" which was just superceded by the overall distance parameter and made it one less thing to look at in the block table as well.

[Kyle_Anthony]

Is there a way you can show me how to do this with the attached block? 

[h_s_walker]

@Kyle_Anthony Have a look at the block I posted in your thread