Footprints with multiple blocks not exploded on 2nd insertion

[jmatel]

I insert a panel footprint assembly through the schematic list and it works fine the first time, the smart block takes the catalog number and I am able to move the dumb blocks. However, everytime after that it inserts all of the blocks as one smart block instead of exploded into a smart block and other dumb blocks. This error only occurs with parts inserted through the schematic list, enclosures worked fine everytime as they were inserted through the panel icon menu. I have tried 4 different catalog numbers that I have assembly footprints for and they all do the same thing, fine the first time but wrong everytime after that.

To make the assembly footprints I first made a smart footprint through the symbol builder, inserted it into a drawing, added the dumb blocks and then wblocked it all. I have the asterisk in the footprint lookup database to excplode the drawing. I use the multiple catalog feature instead of the assembly codes.

I have been working on this all day with no luck, any thoughts or suggestions would be appreciated.

Thanks,

Joe

[btavares123]

Still broken in 2020 version. Please fix this. Same results as stated earlier. First block inserted explodes correctly. Delete the block, purge the blocks from the panel layout, save the drawing then try and reinsert the footprint from the schematic. Now it is just one block with the P_Tag1 attribute in the wrong location. 

[james_moore]

Using the asterisk method "used to" insert drawings WITHOUT defining the block.

IMHO, somewhere along the way, some Autodesk code editor didn't learn the reason for this, or ignored it.  At one time the purpose of using this method in the first place, was to NOT get a block definition in your drawing.

[dougmcalexander]

You are correct. But a block can be saved with multiple blocks inside of it; called nested blocks.  When inserting a block that contains nested blocks, the asterisk will instruct the software to explode one level, keeping the other blocks that were inside it intact, so their attribute(s) can be edited. AutoCAD Electrical needs access to each block, in order to edit attributes. It won’t see attributes that are inside a block that is inside a block. In other words, it cannot edit an attribute that is inside a nested block. 

The stock enclosures can have a side view, a door view, an inside view, etc., all as separate blocks. They are then saved as one block; nested inside that block. The entry in the Footprint Lookup database has an asterisk at the beginning. Upon insertion, the “master” block explodes, so each of the blocks within it become separate blocks and are no longer nested. I mimic this in my classes. We insert a panel with a door view block, an inside view block, and a side view block. We then move each block to its own separate drawing, so each view can fill its drawing. 

[james_moore]

Yes Doug, I have many library items with embedded blocks, and they are designed to insert exploded.  It's also been important to control the order of the embedded blocks in the source drawing, if you expect the ACE edit dialog to work on the correct block after inserting.

My point was, if Autodesk had remained true to the old operation of * meaning do NOT define a block, simply insert the contents, I don't think we would be having this issue.  As Pat pointed out, the problem is with AutoCAD having written an unwanted block definition and referencing that upon subsequent insertions, and the "*" is not being carried over as necessary in the process.

Insert *<filename> should not be "insert block then explode."  This has been forgotten somewhere along the AutoCAD development path.

[Thomasbatson]

We use this regularly not only for panels but for other items like larger drives, power supplies, transformers, etc. to put the side view on the side view layout of the panel to make sure it won't hit the door.  The problem is it doesn't explode each consecutive item so we have to explode and then connect them to the schematic component.  Kind of a hassle and aggravating, but there is a workaround just slows down production.