Panel footprints Shift after a Item number re-sequence

[btavares123]

Has anyone experienced their panel footprints shifting after an item number re-sequence or the automatic panel footprint replacement? ACE 2016 SP1 being used. The attached picture shows what the footprints look like after this happens. I have moved these back to being aligned many times. It only seems to happen in this drawing to the fuse blocks but I have seen it on terminal blocks and other footprints. Is there a setting associated with this? When they are originally inserted the center point on some blocks created by others are in the middle or a corner, or way off somewhere else etc. In trying to start utilizing the schematic to panel feature I just put in the number of blocks from the schematic randomly and then align them until I can go through the blocks and fix the center locations. It seems that the blocks are getting shifted to the same position each time. This looks like it could be the position I originally put them in the drawing the first time. 

[TRLitsey]

Hi there,

So you think they are moving back to the original insert position?  When you move the component do you use the ACE MOVE COMPONENT tool from the schematic ribbon or do you use the AutoCAD MOVE tool from a toolbar or command line?

Good luck

[btavares123]

I use the Autocad Move command. That is what I use for everything in the panel layouts. I will try moving these again using the ACE move command and see if it works.

Thank you.

[jseefdrumr]

I'm inclined to think something else is going on here. The AEMOVECOMPONENT command should be indistinguishable from ACAD MOVE, since there are no wires involved. In fact, the only ACADE command I regularly use when laying out panel footprints is 'insert footprint from schematic list.' In fact, when I think about it, that command and the icon menu are the only commands I use in panel layouts that AREN'T vanilla. And I've never encountered anything like this.

My first guesses here would be along the lines of, what kind of edits have been made to the block, if any? The blocks that are shifted, are they the exact same block as the ones that didn't shift? It seems very weird for only some to be affected. are the affected ones the ones that had their item numbers change?

Also, be aware that each of your footprints, which to you look like a single block, are usually compiled of at least two separate blocks: one is the graphic representation of the footprint, the other is a few attribute definitions to handle the catalog, tag number, etc. These pieces of text are inserted at a point that ACADE calculates based on the overall shape of the footprint. For this reason, text for footprints sometimes appears in weird places.

When you 'go through the blocks and fix the center locations', what exactly are you doing? The workflow you're using for that may be introducing the issue.

Can you post the drawing file?

Hope this helps,

Jim

[btavares123]

I am not aware of edits being made to these particular blocks at this time. We have 4 guys here all working with the same blocks and there is no way of knowing who made what edits when right now. 

The blocks that are shifting are all the same blocks. In this drawing they are all the same fuse block footprint. In other drawings I have seen it happen with terminal block footprints as well. These could be all the same as well as the accesories. 

The blocks that are shifted have not had the item number change. These have stayed the same for a while for these items in this drawing. These are the standard items for this panel that really don't change. A little history, I am redrawing all of the schematics that were done in the past using the tools in ACE that were not being used. For example, in the panel layout all balloons were being added manually etc. that was not with the ballon tool. The workflow was more along the lines of traditional cad. None of the blocks were inserted via the schematic option, BOM not being used etc. All very manual. Lots of the block work were good to use. The panel layout drawings before were not linked with the schematic in anyway and I found it easier to just redraw the entire thing. So this drawing is a new from scratch drawing. I am trying to iron out a few of the issues I am having to try and get the rest of the group onboard with using the tools in ACE. This seems to be my last hurdle. I am sure it is something simple that I am just not understanding. Documenting some of these problems internally will help ease people into knowing how to fix issues when they come up. That way they can use the intended workflow. Maybe I am just not doing it right and that is why this is happening. 

I then try and use the schematic align command to get these all straightened out. Sometimes they straighten out OK. Sometimes the balloons get all screwed up and I have to then delete the balloons and add them back in using the Panel ballon command. Sometimes I just use the move command. Either one should work. On this drawing I have probably fixed these footprints at least a dozen times. 

The blocks I am using for panel footprints have most of the tags already in the blocks. The original creators didn't use the insert from schematic feature and were filling the tags in manually per footprint for some reason. I fight with this with some blocks. New blocks I have created for panel footprints are just a footprint. No attributes added. Maybe this is my problem with these blocks that are moving? But lots of the blocks I am using are like this and are not moving. 

Fixing center for some blocks I have encountered the block was placed way off center for some reason. So for some footprints, VFD's for example I put the middle of the footprint at 0,0. This way when inserting the block from the schematic it is in the middle of drive and not way off in left field some where. For these fuse holders and others, it is nice to have a corner of the footprint at 0,0. Maybe the middle of the footprint left etc. This way when inserting the footprint for multiple instances you just line up the corner or side. We have done this with IO modules and it works well. Why for some reason other footprints are all over the place I don't know. I understand this can effect the text of the footprint. But for the most part if I have to move the text, with the proper ACE attribute move command it is not big deal. 

When I encounter this I will delete the originally inserted footprint from the panel layout. Then purge the drawing of these footprints and save the drawing. Then, fix the block by adjusting the center location, purging the block drawing of anything else in it and saving it. Then re-insert the new footprint that has the center location corrected with the schematic to panel tool. If it makes sense I can delete all of these footprints and re-insert them. Still really doesn't explain why some are changing and not others. The same few seem to be moving.

I will post a drawing on Monday. 

Thank you for your time. 

[jseefdrumr]

When ACADE inserts a footprint, it actually scans the block for attributes, too see whether it needs to add anything. If the attributes in your legacy blocks are properly named, there should be no issues. At least, not with the shifting footprint thing.

As for using the schematic align command on footprints...I want to say you shouldn't, but I can't think of a good reason to. I'm certain that all this command does is align entities by their insertion point, regardless of what they are. Note that it will align a signal arrow with a wire number. The only thing those two things have in common is, they're blocks. So, insertion point.

Now, with your added information, I'm beginning to suspect your library locations.

By default, these are installed on the local hard drive. When you edit the blocks and fix them, those changes would only be stored on your machine. If another user were to then run an update, it could force the change. (Explained below)

How do you manage your installs for multiple users? Do you share the AeData folder on your network? If not, then IMHO you should. Not doing so could be the reason for your issue here. If you are set up with a shared AeData folder, then I would check to make sure each workstation is pointing to the correct one, and/or that its local AeData folder has been renamed.

Is everybody on the same version of ACADE?

I think this is the most likely root cause for your issue so far.

Now, as to why an update may cause a block to change. This assumes that you and another user are pointing to different libraries, and/or different footprint lookup databases.

Bear with me a moment: I've noticed that during certain update functions, what ACADE actually seems to be doing is not updating per se, but rather deleting the old block and reinserting it with the new info. Keep that in mind...

Let's say you fix a block. As is correct, you have purged the old block definition from the drawing before reinserting the edited block.

Now let's say another user opens that drawing. Runs an update. When ACADE kills/rebuilds the block, perhaps it is looking at the local AeData folder during the reinsertion, rather than the block definition that's already in the drawing (that you fixed earlier). If that's the case, it would explain why an update could shift a footprint.

That's my best wild guess, at any rate.

You seem to be in a situation I've seen before, and it sounds like you're doing all the right things. Clean up the old blocks, maintain connectivity between schematics and layouts, find ways to keep things familiar for the others while easing them into new workflows. This problem seems odd - and to be clear, ACADE has its fair share of quirks - but I think it's fixable.

Jim

[btavares123]

OK. Good to know about the attributes. Thank you.

I am using the schematic align on the footprints. This does seem to work. I have used it in the past as it is faster to use for multiple footprints. 

We do share the AeData folder on a network drive. We are all pointing to this location. Local AE data folders have been renamed. At least I know it is on my machine. I have modified my catalogs to be local to get the workflow down for others and fill the database with our older catalog data and sort it out. This will then move to the network location once everyone agrees on moving the workflow over. But, my location to pull blocks from is on the same network drive as everyone else. The drawings I am having problems with are local to my machine and are not being used by anyone else at the moment. 

All the software installs are managed by our IT dept. We are all on the same version and SP. 

Thank you again for your time. I will post a drawing tomorrow. 

[btavares123]

Here is the drawing I have been having the troubles with. 

[jseefdrumr]

Nothing stands out in the drawing, or in the blocks. I ran AUDIT, nothing there. Without having access to the project database, there's not much else to chase down.

I'm still leaning towards some sort of pathing issue. You said you're running everything off your local machine, but that you were pulling blocks from the network. You probably already have, but I would verify that: 1) the local version of the block matches the network version; and 2) the footprint lookup database is pointing to the correct block.

Have you tried AEREBUILDDB? Sometimes this clears wonky/unexplained behavior.

It seems like only the legacy blocks are doing this, at least in this drawing. All of the affected ones in the drawing you posted have attributes in them, but you said that when you draw new blocks, you don't include attributes. So I'm wondering if perhaps there's something about the old blocks that is causing this. Not the attributes, necessarily, but something. Since you didn't create them, the only way to be 100% sure that they aren't the problem is to kill them and replace them. I seriously doubt that it's the presence of the attributes in the blocks that is causing this...but I'd leave them out of the new blocks anyway. Personal preference, mostly, but in your case it's also one of the things that is different between the footprints that work, and the ones that don't. To be extra sure that everything is 'right' I would even draw the replacement blocks in Symbol Builder, even though I normally just make all my symbols from scratch.

Unfortunately, I don't have much else to offer. The only things that jump out at me are ACADE's paths, and perhaps a couple of wonky block files. I'm certain that this isn't an issue with the software, otherwise it would have been posted on the forums before now. As a final fix, you might try to repair or reinstall on your local machine.

Jim

[btavares123]

I am pulling the blocks from the network. The only thing local is the drawing and the catalog database. The footprint blocks and schematics blocks all come from the same networked location everyone else points to. 

I have tried the database rebuild. It does fix lots of issues but unfortunately not this on. 

Thank you for looking into this. I am just going to rebuild the block from scratch and see what happens. 

Thank you again for your time. 

[rhesusminus]

have you tried to turn off OSNAP (F3) before running the function that replaces the footprint?
Also, try to set OSNAPCOORD to 1.

[btavares123]

I was not replacing the footprint. I was doing a function unrelated to replacing the footprint, Item number re-sequence. Then noticed the blocks were shifted. I will try your suggestion but at this point I am just going to rebuild the block from scratch and blow the old ones away. I have a feeling lots of small problems I am experiencing are due to the old block library I am using that were created by others. Some of these blocks have never been purged, have lots of unused layers etc. They really need the be gone through and cleaned up. New blocks I have created have not been a problem with. So, as I come to problems with blocks I just make new ones.

Thank you for your help.