Dynamic Block - Detail Update Issue

Chris,

A recent change attempts to purge out any blocks in a detail when updating, this must be interfering with dynamic blocks.

If you could send in the source detail to us, we can take a look at it.

While I still want to fix this, I'm also curious - from the PDF, it appears to just be a rectangle.  Is the stretching limited in increments or something?  I'm just wondering why it can't be a polyline.

--J

Jeremiah,

Where should we send the source detail? The plain rectangles were a test block that we created to see if the problem was specific to one block or a larger issue.

The block where we first noticed the issue is an expansion joint and it includes backer rod and sealant at the top of the joint. The joint filler can be stretched to any depth needed. We prefer to have it as a block so that everything stays together and so that the expansion joints are graphically consistent across our details/drawings. 

Thanks for your help!

Chris 

Chris,

Ah, so of course the test block looked simple then!  Haha.  Excellent then, yes, that's a great use of a dynamic block.

You can attach the detail to a technical support ticket and we'll take a look at it right away.

--J

The .dwg file is has been submitted with a support ticket.

Chris,

Thanks for sending that in.

However, unfortunately I was unable to replicate it using 2020.

I inserted the detail, and then then edited it several times, sometimes changing the length of the dynamic block, sometimes just editing other things in the detail.  And whether I run update details, or delete it and then re-place it, every time the hatch within the dynamic block matched the length.

(I do get a message during the update process that duplicate block EXPANSIONJOINT_DYN is ignored, which makes me wonder if having more than one such detail on the sheet could cause it?)

I also checked the recent code that attempts to purge any sub-blocks from a detail, and it is expressly avoiding dynamic blocks, so that doesn't seem to be the issue.

So I have a few thoughts.  First, the detail has thousands of proxy objects.  Nuking the detail took it from 522k to 123k.  That's a lot of gunk!  It is certainly possible that proxies are to blame.

Alternately, I found this forum post:

https://forums.autodesk.com/t5/dynamic-blocks-forum/hatch-association-settings/m-p/8388064

In there, it was recommended to remove the hatch from the selection set of the stretch action.

And lastly, it is possible that this is an issue that affects 2019 but not 2020.

I hope this helps a little in tracking it down, please keep us posted of any progress.

--J

Jeremiah,

Thanks for looking into this. I just tested a few different things.

I removed the hatch from the selection set, nuked the detail, and started a new file to place the details into which I also nuked. I created a new project and only placed this one detail on the sheet. When first placed, the dynamic blocks appear correctly. I opened the detail, did not edit anything, and then saved the detail. I then clicked "update details" and I got the same result as before with the hatch areas changing/reverting back.

If I remove the detail from the sheet, purge the block definition and then replace the detail it displays correctly. But as soon as I go through the same process as above (open detail, save, update) the same issue shows up.

When updating the detail I get the same message that the duplicate block definition was ignored.

If the block definition is already in the sheet when the detail is initially placed the issue occurs.

I decided to place the blocks directly into the sheet to see what would happen. The blocks display correctly when inserted directly into the sheet.

I edited the placed detail block directly in the sheet via Block Editor. If I adjust the lengths of the dynamic blocks the hatch areas adjust and display correctly. Upon saving changes in block editor the hatches show correctly on the sheet. After opening, saving, and updating the detail the issue shows up again.

The blocks that were placed directly into the sheet never have a display issue.

Additional information:

We have been running AutoCAD 2021 for about 4-5 months. No updates to the software have been made since initial installation.

This issue first noticed this issue in mid march of this year. Not sure if that helps pinpoint a particular update? Prior to that, we had not seen this issue with the same block which was widely used. This problem never showed up in our last version of AutoCAD (AutoCAD 2019) and the block was widely used at that point as well.

Any thoughts?

-Chris

Chris,

Excellent troubleshooting, thank you.

The timeline does match up with the automatic purging when placing a detail, that was implemented with version 17.09, and you guys installed on February 22.

Luckily here, everything Land F/X is doing is clearly visible at the command line, so that should give us our best hints.

Up to 17.09, the system would attempt to purge out the detail block before inserting it.  After 17.09, it also attempts to purge any blocks within the detail.  You can see this at the command line, as it fires the Purge command (you might need CMDECHO set to 1).  After that, it fires an INSERT command, also at the command line.

That is the only thing that changed near that timeline.

However, that is only when *placing* details from the Manager.  Meanwhile, over in the Update Details function, it uses an entirely different method of inserting the updated details that is not visible at the command line, and it does not attempt to purge anything. The only clue at the command line as it fires is the duplicate block warnings (this can be compared to the similar output when Placing).  Yet this code has not been modified since May 2017.

There are several Autodesk forum threads regarding this, for instance this one:

https://forums.autodesk.com/t5/net/dynamic-block-with-associative-hatch/td-p/10023207

Which would support this behavior - that when placing the dynamic block with a command call, like Place Detail does, it works fine.  But using an internal insert method, the hatch association is lost.

But where that doesn't line up, is as you mentioned, this was all working fine in 2021 for a period of a few months.

You mentioned your 2021 has not been updated.  Yet there is a 2021.1.1 update that was released on April 26.  I don't see anything in the release notes that look promising, but it would certainly be worth a shot.

--J

Jeremiah,

After more research and digging around AutoCAD forums, it seems that this problem has been around for many releases of AutoCAD (earliest instance I found was 2009...) but it only affects certain users. There is no real explanation as to why some experience this problem and others don't.. and it does not seem that anyone has really found a good way to fix it. Most of the work arounds are too time consuming to be practical.

What I can't figure out is why this just started happening to us now! The block worked great for about 2 years with no issues..

I think our only solution at this point is to move away from a hatch that is associated with a stretchable boundary. We'll have to use a linear array for the expansion joint infill or something similar.

-Chris