In the last year or so, in my (clears throat) “spare time”, I’ve been working on a conversion that would allow us to create our P&ID’s (Piping and Instrumentation Diagrams) in AutoCad Electrical instead of straight up AutoCad. I’m finally close, having solved the more challenging issues I was facing. I still have some symbols to create, but we should be doing our first trial run project in the very near future.
Not everything went as smoothly as I had hoped, but in this post I will share some of the things I did to make this happen. One of the steps will be a bit of a repeat…. but it’s worth putting in here as a part of the whole project.
Above is a sample of one of our standard P&IDs. The symbols are based on ANSI/ISA-S5.1 (R1992) A little background might be helpful…
Back in 2012, when we got our upgrade to Autodesk Product Design Suite 2013, we realized that it now came with AutoCad Electrical. I was sent to training that summer to learn the basics, and tasked myself with converting all of our schematics and panel layouts to this program, since it incorporates a lot more intelligence than the simple ladder diagrams we were producing. I’m not going to go into the details of that transition, but will say that it’s still sort of an ongoing process. It took several months of working in my spare time to tweak the symbols libraries to our liking, create templates for both drawings and projects, and convince the project managers that this was indeed a good thing. We continue to tweak the look of our drawings, as well as add components to our catalog database. I, personally, continue to learn more about how this program works in conjunction with the Vault, as well as learning more of the intelligence behind it and how we can use it to extract BOM’s and other reports.
As I was familiarizing myself with the program interface, I noticed it had a menu of P&ID symbols. Not very many, and in my opinion, fairly simplistic… but it seemed the potential was there. While in San Francisco meeting with some other users, I had a conversation with a couple of electrical gurus whose specialty is this software. They told me that one major benefit to using Autocad Electrical to produce P&IDs is the fact that you can link the tag numbers between those and your electrical schematics, in such a way that the project database sees the instrument or device only once per tag number. The trick is to use the attribute that is on all P&ID symbols; WDTAGALT. This attribute allows for the link between these devices, so that a change in one, such as changing a catalog number for instance, will be reflected in both the electrical schematics, and you P&ID’s. And when a BOM report is run, the device, though shown in multiple places throughout your drawings, will be shown with the correct quantity. This sounded very interesting, so I began working on the conversion.
It has taken a long time since most of my symbols had to be recreated in the Autocad Electrical symbol builder. This was the easy part, and I didn’t mind doing it since our symbols were in need of a face lift anyway. Creating some new templates was easy.. no challenge there. But there were several stumbling blocks along the way that I had to find work arounds for, and therein lies the bulk of this story.
One of the first things I decided to tackle was how to arrange the symbols in the AutoCAD Electrical icon menu. But the more I looked at it, the more I hated that idea. I’ve never been fond of this menu structure in the first place, as it requires you to open the icon menu, search for the correct page and then find the symbol you’re looking for. Anyone who has been reading this blog for a while knows that I am all about minimizing mouse clicks. I wanted to figure out a way to put all of these symbols onto tool palettes that would be quicker and easier to navigate. Rather than retell this story, here is the link to the blog post I wrote after figuring this one out.
The next big challenge, and one that gave me more than a few headaches, was line tags. In P&ID’s, each unique line is normally tagged in some way for identification. In our case, these line tags consist of 4 parts; Line size in inches, a fluid code identifying what is in the line, a unique tag number, and a pipe specification. The spec itself represents the pipe material, end treatment, gasket and fasteners.
My first thought was to try to use Wire Numbers, set up by layer. This held some promise at first, but the program requires that you set a starting wire number for each layer. With P&ID’s changing all the time, there was no way of knowing ahead of time how many wire numbers I would need for each layer. This also would change from one diagram to the next, as we use different sequence numbers depending on the process being described. Add to that all of the variables I listed above, and this was just not going to be a good method for placing line tags. I needed something that would allow me to select these variable from some sort of list, AND automatically sequence the tag number as needed for the number of lines on the diagram.
I turned to the gurus on the forums in the Dynamic Blocks discussion group. I thought there might be something there that would help. I learned about block property tables and lookup tables. A block property table allows you to build a table inside of a block attribute, and then as you place the block, select the value for that attribute from the resulting list. If the table is structured properly, you can nest the options by certain values, in order to further narrow the final selection. The table I constructed is shown here:
When placed into the drawing, and this lookup tag selected, the result looks like this:
I simply wade through the options until the correct fluid choice is selected, and the Value for that fluid is then placed in the correct spot in the block. Now… to explain what I mean by that. As you can see in the image above, there is more than one lookup tag on this block. I wanted to have a lookup for each different section of the line tag, and some of them… like our pipe spec…. have several sections themselves. So, to construct the block out of only one attribute, this is how I set up that attribute:
A series of Fields inserted into the attribute are mapped to each of the lookup tables, so that the value selected when placing the block will populate that portion of the attribute. Messy,… but it’s working so far. But, since I can only have one block property table per block… the rest have to be regular lookup tables. These cannot be nested, so each one has to populate a different section of the pipe spec. I’m confusing myself,… I’m sure I’ve lost you by now. Let me try to explain…..
Let’s break this LINETAG down by Lookups. Lookup1 is a list of the available pipe sizes, in inches. Next in line is my Block Properties Table, which gives me the selector for my fluid code. Lookup2 thru Lookup6 are the different codes that make up our pipe specs. These are pulled from this table which is used by engineering to generate a new spec. I simply created a lookup table for each piece of the spec.
The last piece of the attribute is the tag number itself. This is actually populated by mapping a field (seen in the image above as a series of dashes) to the value of a separate attribute in the Linetag block. This second attribute is set to invisible. And how I get THAT value, is probably the best trick of all. I need to be able to have these tag numbers increment by a set value, and it is hard sometimes to remember the last number used, especially on a very busy document. Enter Lee Mac Programming. Lee is a programming genius, and shares his code on his website free of charge. He does accept donation to offset his time and costs. i find this very generous. Lee has a program on his sight call NUMINC.LSP. It, very simply, takes a number you enter and places instances of that number incremented by whatever value you set. This number can be placed as text, or set to the value of a block attribute (this is why I liked it!). There is much more you can do with this program, but I’m going to let Lee describe what it does.
In order to place a linetag, I call this program, which is already pointed to the correct attribute in the LINETAG block, set the starting number and increment, and place as many copies as I need. I then use the lookups to modify the other parts of the attribute, and hit regen. It’s a bit of work, but then I wanted to be able to capture a lot of different values in one block. Why not have a separate attribute for each value? I could, but then it is near impossible to maintain a Middle Center justification. This is much cooler anyway.
I’m going to break this post here, and make the rest into a part 2… this is getting away from me quickly. Part 2 will deal with symbol creation and other challenges. I may also get into nesting projects in Autocad Electrical, something I learned about at Autodesk University this past December.
I haven’t forgotten about this follow up post, I just haven’t been back into working on implementing this due to some big projects hitting my desk. Stay with me and I’ll get to it… soon, I hope. Thanks!