1756-en2t Cad Drawing

[Marquez Feliciano]

Iam creating a drawing standard for ACADE, and one of the issues we had with regular CAD drawings was the constant struggle to keep schematics and network communications drawings synced together. Someone would make a change on the schematic and not update the communications drawing to match, or vice-versa.

Most of the issues have been resolved in ACADE using parent/child relationships, but there is one particular sticking point that I cannot seem to resolve. That is properly tying the PLC modules on the network comm drawings to the PLC modules in the schematic, and that's due to the inherent differences in the attribute setups for schematic symbols and the PLC/IO modules.

The idea is that I want to insert a schematic symbol on the comm drawing, use the PLC module on the schematics as a parent, and pull that information from the PLC to the comm symbol so that if the PLC module gets edited, the comm symbol will update as well.

I've tried everything I can think of, including the creation of new attribute templates, but have had no success other than pulling the tag number and RATING12 over (RATING12 is what I am using across the board for IP address). The things that are not transferring are the LINE1 (rack number), LINE2 (slot number), and DESC attributes.

It's not really a project per se. It's a testbed for implementing AutoCAD Electrical within the scope of my company's standards. The specific blocks I sent you were meant to serve as a way to create a network communications drawing and have it pull the relevant data from the schematics, specifically the tag name, descriptions, and the IP address (which is why there is a RATING12 attribute). The purpose is to connect them up so if someone changes the information on the schematics, the network drawing will update with those same changes. I managed to get everything talking except for the PLC modules, which is why I started this thread.

This particular "project" is actually the baseline template for our ACADE projects and is me testing ACADE and its capabilities and working with new ideas to improve the process. Once the system is up and running to the satisfaction of myself and others, the drawings themselves will be deleted. This particular set of drawings is based off a small project we recently did, with me replicating the look and feel of the standard ACAD electrical drawings while implementing ACADE's abilities.

Well, I have yet to get to the other PLC modules. In our company, we use the footprint-esque versions you saw for things like backplane powered control and ethernet modules, as they don't have any wiring from the 24v ladder or any controls. They were created using the symbol builder in a traditional schematic component fashion.

And yes, everything transfers correctly with the footprint-esque versions, but the problems will occur when I use a traditional PLC module and have to move/rename it. The PLC tag and descriptions will update as usual, but the defaults (as seen in a REFEDIT) remain as they were originally, which means the TAG1 and DESC1-3 attributes won't update as they should, and things will get out of whack again.

PLCs are special blocks, check the ACADE help on this...

They weren't meant to have the same type of parent/child relationship as a relay/contact. It's more focused on addresses and collecting them all to one parent insert, then linking that parent to a panel footprint that represents that card installed on a panel.

So when you create one using the "HORIZONTAL/VERTICAL" "FAMILY" "PARENT/CHILD" blockname concept... some stuff works... but much doesn't.

I used your 1756-EN2T block, added a TAGA# (I just linked it to a plc module in one of my projects, it's a 1794 but it doesn't matter), when I edit the TAGNAME on the main plc module all children are updated, except your child block, but the one I modified by adding a TAGA# updates that TAGNAME... the rest still does not update as PLC children don't get the LINE/DESC attributes normally.... (at least not when it's setup the way you have it).

there may be another solution... properly created children, use panel footprints (you can have more than one pointed to a parent)... panel footprints will pull the line1, line2, desc attributes to the footprint. Your EN2T "child" already looks like a panel footprint...

I don't see how the child block is set up wrong. It has all the requisite attributes of a child schematic component and was created through symbol builder with zero issue. I am 100% certain that it is created correctly. One of the first things I did when I discovered this issue was to verify that the blocks were created correctly.

The purpose of these child blocks is to serve as a separate communications block for a network drawing that will update accordingly when a parent block is updated, no matter if it's a schematic component or a parametric PLC module.

The only problem I see is that the default values for the TAG1, DESC1, DESC2, and DESC3 attributes, which use fields to copy the value from the TAG, LINE1, LINE2, and LINE3 attributes, will not update behind the scenes if the module is moved or edited. On the surface, things look perfectly fine. The information will update properly on the module. However, if you insert the child and search for the PLC module to connect to, the system finds it under the previous tag name.

We insert PLC module and it is assigned the tag name based on the naming conventions. As an example PLC15510. That number goes into the value of the TAG attribute. The rack and slot numbers (specified upon insertion) get put into LINE1 and LINE2, and the description (located in the PLC database) is put into DESC.

Everything is all hunky dory and perfectly aligned at this moment. However, if we use a move component or an edit, like if we wanted to move it to line reference 15547, change the slot to 2, and change the description to ETHERNET BRIDGE MODULE, the red attributes will update, but the blue attributes will not, leaving us with this:

The child blocks are working exactly as intended, pulling the information from the TAG1, DESC1, DESC2, and DESC3 attributes in the PLC module. The issue is that those specific attributes are not updating when the module updates, so the information the child blocks are pulling is incorrect.

This goes back to the issue I talked about before. When you do a REFEDIT on the PLC module after moving it and double-click on the TAG attribute, the default value continues to be the original value (PLC15510, in this example), despite the displayed value being PLC15547. Same goes for the slot number and the description. The default value of the TAG, LINE1, LINE2, and DESC attributes are not changing at all, and the TAG1, DESC1, DESC2, and DESC3 tags are picking up that old information. Once we can figure out how to change that default value to match the actual value, everything should right itself.

I know that if I were to put the field after the module is inserted, I don't have that issue, so the problem must be like you said before, where the fields are getting locked down upon insertion. I don't know coding, but I bet there's a way to automatically copy the values of those attributes to the others after the PLC has been fully inserted into the drawing. I've no idea how to do it, though.

All I do know is that if we implement a solution to simply update the child, the parent/child relationship will break, as the child will be looking for PLC15547, while the parent value is PLC15510 (attording to TAG1).

the fields work for the initial install because of the way the block is built on the fly. But after that the links to the fields are no longer linked to the inital thing they were linked to (an ATTDEF in the HPW2...L.dwg drawing) because that ATTDEF is now an attribute on a block, not an ATTDEF.

Once all the little drawings that make a PLC are blocked... the ATTDEFs are gone. And that is what you linked to, an ATTDEF, not an attribute. At least that is my suspicion as to what is going on with the fields.

Then my tool will work to put the line1, line2, desc on your child. Since the tagnames will now be linked I can find that child when you click on the parent (it actually goes either way... as long as the child tagname is linked to the parent, you can click the child, or the parent, the child will be updated).

3a8082e126