Schematic question - which is proper?

[stasis]

Tim, I like the second one better...more linear. Even if the coil is inverted, it's still easy to follow as the documentation is there.

 

[Tom Jenkins]

A few comments:

... it is very "rare" if/when any single input has a bearing on when an output activates or deactivates ...

One of the regulars (Bernie) has a signature line that says "Controlling outputs is the PLC's way of getting its inputs to change". The converse is also true. For example, in our logic if the "Valve Closed Limit Switch" is indicating that the valve is at 0% then then ladder logic causes the "Close the Valve" output to turn off. This kind of inerlock is common.

Another observation: Over the years I have had many more problems with field devices and wiring than with I/O, and many more problems with I/O than with logic.

So, let's assume that the valve isn't travelling closed when it should. The tendency is to assume there is something wrong with the output card, and start swapping parts. If the input card is on another sheet it may not even occur to the electrician that there are devices wired to an input card that will impact operation. If the inputs and outputs are grouped into a valve operation schematic, then the electrician will at least be aware of the existence of the limit switches, and it may occur to him to see if the "Valve Closed Limit Switch" input is On, and check the cams to see if the limit switch is tripping early.

Tom - I like your style, and I can see that the big advantage is freeing yourself from the constraints imposed by representing the wires as direct physical connections. Nevertheless, yourself and Terry Woods are the only two I've ever seen doing it this way. Which is not to say you are wrong, but perhaps your method is particularly suited to your design style?

That's probably because Terry and I are both contrarians. When we see everyone doing something a certain way we just have to think about other ways of doing it!

It is partially true that my design style is aided by this drawing method - I tend to have more external interlocks and external parallel devices than most systems.

Mostly, though, I think (and I have no proof) that some bad habits got started in the very early days of PLC applications, and plain inertia keeps most people in slavish bondage to that drawing style. In the early days the objective was to replace relays with PLC stuff, so there weren't a lot of hardwired interlocks and such. Field devices and relays were simply wired right to the PLC, and the logic was all inside in the program.

Furthermore, since this "newfangled PLC" stuff was kind of obscure, it naturally assumed a prominent place in the minds of electricians and engineers and panel builders. They simply couldn't imagine treating the PLC just like a relay or an indicating light! No one knew how to wire those really high tech new concept PLCs, so they created wiring diagrams instead of electrical schematics. I'm guessing that the pattern, once established, was probably hard to kill. (Just look how shocked some forum members are by using the same drawing technique they use for everything esle on the PLC too!)

I really think there are advantages to my approach. I've had more than one contractor tell me my drawing package was the easiest to follow and use they had ever worked with! On the other hand, I've had engineers complain - but what do they know, stuck behind those desks all the time!

 

[kamenges]

Tom-

It's been a while since I've seen a copy of your drawings so I may be speaking with little reference. And I can see your point about being a slave to a drawing style simply due to history.

However, you make a point that you see as a strength that I contend may be a liability. That is the (apparently) logical relationship that can be made between inputs and outputs in your drawing style. I like the implied abstraction that the module-based drawing brings. It tends to reinforce that there is alot happening inside that little black box with the blinking lights. It leads you to look at individual devices as individual devices and troubleshoot at the device level. Yes, you need some information from somewhere that relates individual I/O points to functions. But I don't know if I could do that on the machines I work on without quadrupling my print set.

Granted, the drawings don't lead you to make any determinations on machine or sectional function. But in my case there usually isn't a particularly straightforward relationship anyway. That's why I have a plc. If I could easily show the relationships on a drawing I could probably do the thing fully hardwired just as quickly.

Keith

 

[CharlesM]

I like to put the module number at the top of the print along with the part number. I also put a small graphic at the bottom of the page showing the rack and an arrow showing what module in the rack I am showing. This answers the question of what slot number. Does it start with 0 or 1? Is 0 the CPU or is it just another slot. If I have a big rack or a small network. I do a layout of the plc racks showing part numbers and how the rack is assembled.

I also like to put my DC wire numbers in brackets [24]
and my AC wire numbers in parns (120). Most people dont notice but my guy's like it.

 

[stasis]

as far as wire numbers, I usually label the wire according to the relevant input/output. As I mostly deal with AB, this tends to be alot easier to follow on paper. Wire # I:2/00 will land in slot 2, point 0 on an input card and wire # O:7/15 will be slot 7, point 15 on an output card.

 

[sportster]

I'm a young buck here, but both Tims's and Tom's styles have there place. The "module" based schematics are great for install and chasing wires because one look at the print tells me exactly what points the wires are supposed to run to/from. However, they are not very friendly to troubleshoot from for all the the reasons Tom mentioned. Flipping pages on a print only leads to more confusion IMO. Tom's style is great for troublshooting because I can see everything that is going on with a particular device in one place. When I have to draw up prints I follow Tom's style and it drives the first shift guys nuts. They like the "module" style prints because if there is a PLC in the cabinet; there should be one on the print. I guess it comes down to being six of one and half a dozen of the other. Both work well in different ways. My two cents.


Patrick

 

[oldgearhead]

I like to use line numbers and I/O numbers for many of the wire
numbers..

 

[brucechase]

It looks like there are 2 wires with the number 220 on it. Am I reading this correctly. Most of my systems use the line number from the print as the wire number but I have recently ran into major difficulties when I've added some items (not in the plc I/O section). If the line is pretty full with interlocks and I have to add several more that causes the line to shift down and everything else shifts down, then the numbers no longer make any sense or I have to go relabel all the numbers in the field (not likely). How does everyone else handle stuff like this when using line numbers for wire numbers?

 

[kamenges]

We used to use wire numbers based on a page number/line number combination. We ran into the same thing you did. So we came up with what we refer to as columns. This is basically a page header. We didn't want to call them pages since, if we needed to add enough stuff in the middle of a page that a new page is required, it would screw up the numbers also.

The wire number is a combination of the column number and an arbitrary wire number. For example, all wires on column 20 would start with 20. You end up with wire numbers that look like:

20-1     20-2     20-10     20-30

If I need to add enough stuff to a page that it requres a new page the column numbers become 20A and 20B, but the base column designator for the wire remains '20'. We also use column cross-references to tie contacts to coils and pilot lights to pushbuttons.

This isn't the best system. It doesn't get you to exactly the right spot immediately. But it gets you immediately to the right page (or within one of two at least) and, because of the way people design, the number progression tends to go left to right, top to bottom on any given column. For us, this seems like a usable compromise between design stability and end user friendliness. In my experience, once I explain to people how to get around in the drawings they don't mind the format.

Keith

 

[mellis]

Interesting how a simple question can illustrate just how different our "standards" are.

A lot of the differences are based on the industry you are in, and the role you play. OEMs do things differently than engineering firms. In house projects get done differently from corporate ones. Process control, machine control and HVAC control generate some very different looking drawings for very similar hardware.

Generally on the projects I work on, we do PLC I/O drawings that are card based. For a lot of devices, that's the only drawing. For motor controls, we do motor schematics similar to what Ron and Tom use. Some I/O shows up on both drawings and that's OK, they have different uses. The panel fabricator only gets the I/O drawings, they are perfect for him. His responsibility ends at the terminal strip anyway, the motor schematics don't help him. However, the people that maintain the equipment really prefer motor schematics. That's why we provide them.

In general, my drawings tend to be very plain. I don't usually use pictures of I/O modules like Tim's example. My focus is on conveying information in a clear, concise manner. Readability is important too. It's difficult to maintain standards like minimum text size when the I/O module is drawn to scale. For instance, on Tim's drawing, the terminal numbers on the M12 connectors are going to be the first things to turn into little black blobs after a few generations of reducing/copying/faxing since they are the smallest text on the drawing. That's important to me. (Not picking on Tim here, just stating a preference. I see plenty of drawings in that style, so obviously some folks like them.)

About TheDave2's gripe about "-24VDC"... I agree, "-24VDC" is just misleading. There are plenty of better choices out there: COM, 0VDC, 24VDC-COM and variants. I'll even go for "24VDC-" but it's not my first choice.

Wire numbers... Any system of wire numbers that is based on arbitrary numbers is missing the boat in my opinion. Especially if they are related to physical position on a drawing sheet. I much prefer wire numbers based on PLC I/O address and/or device tag number. For instance, if I have a motor schematic for pump 984, then the wire numbers are 984A, 984B, 984X2 etc. The main idea for wire numbers is they should be reasonably unique. It's easier to achieve this if they are based on another number that is already unique. In a drawing line number system, keeping track of what numbers have already been used can be a major housekeeping issue for a large plant. Who needs to manage yet another list of numbers?

Oh well, enough rambling for now...

 

[Tom Jenkins]

I number rungs in increments of 10 (1020, 1030, etc.) As I go through a rung the wire number increments after each device. Wire numnbers 1030, 1031, 1032, etc. are all in the same rung. I don't recall ever having more than nine devices in a single rung.

 

[plcisgreat]

I couldn't agree more, on DC Voltage and DC negative as common and not ground. We have some electricians that firmly believe that DC negative is Ground, and that's why they can't understand why they get fluctuating voltage readings. It's important that the same voltage reference is used when testing DC Voltage. So what is the difference between a ground and a isolated ground?

 

[rsdoran]

The attached doc file shows a simple machine drawing. Numbers are sequential per se. Bruce the reason I like sequential numbers instead of line numbers is that you can use the original number and add the alphabet...ie wire 14, 14A, 14B etc., that can be extended if the alphabet runs out..ie 14A1, 14A2 etc

It depends alot on the PLC but the I/O numbers are relevant to the rack, group, and/or module. It depends but make the numbers high, 10000, 11000 etc so its easily understood that it pertains to plc I/O plus allows room to expand hardwired numbers. I can not use my laptop now but have "cad" drawings for many plcs and modules that show the brand, model etc, I like this because it simplifies locating the access point especially when there are alot of I/O modules used AND you know exactly what module you may need if it must be replaced.

A PLC's actions can not be represented "electrically", all you can do electrically is show the "connections" pertaining to the plc. This can assist in installation and wire chasing during troubleshooting. Just like a transformer you show "WHAT" the device is AND the wiring connections but its "assumed" that anyone looking at the drawing KNOWS what the transformer is doing.

A "pure relay" drawing will represent the actions of a system BUT a PLC is "more" than a relay..it is a controller, therefore MORE is needed, than a schematic, to understand how the process works...that is why so many engineers, techs, maintenance types etc have a problem with PLCs.

As for "WHY" people think it is necessary to display it this way, I think because "industry" and "government" has pretty much made it a "de-facto" expectancy (or requirement). Just look at the fact most manufactures provide cad drawings of their I/O modules AND and that Standards Committees also use this method.