advertisement
from the Automation List department...
Control system wiring numbering schema
Engineering and workplace issues. topic
Posted by Victor Zaltsman on 18 December, 2000 - 7:38 am
We are trying to establish a standard for Plant Control(PLC) system wiring numbering. Two methods have been proposed and we have a problem to pick up a right one.
Method 1: Start a numbering at PLC TB (our PLC TB are numbered according to RACK:SLOT:SIGNAL pattern, so a terminal, belonging to RACK 1, Slot 5 Signal 14 would be numbered as 1514) and keep the number unchanged all the way via various junction boxes up to the field instrument terminals.
Method 2: Start a numbering at PLC TB and change the wire's number (according to terminal's number) each time the wire entering/exiting a terminal up to the field instrument terminal. This way both ends of the same wire will have different numbers.
What method would you recommend ? (one of above or any other "good practice").
Thank you,
Victor Zaltsman


Posted by Thomas Swift on 18 December, 2000 - 12:59 pm
ISA Standards and Practices for Instrumentation. ISBN 1-55617-051-3

These standards cover control systems documentation from device to electrical elementary drawings. Your tags (numbers) should be consistent throughout the project.


Posted by D W Heinecke on 18 December, 2000 - 10:34 pm
Victor, I would think that the first method would be more appropriate, I have in the past designed, built and supported systems in both formats. I know when it comes to trouble shooting systems I want to know that I have the same wire at each test point and usualy I would also put an Identifier Letter for type of signal I= input O= output this is important if you are using isolated source power for each area of your circuit. In systems with remote racks or networks then a drop identifier is added as well as a prefix as you listed. these schemes can make your wire numbering a bit of a pain for your assemblers but when it comes to analysing a fault it pays for itself in downtime reduction. The second method I find that it is often used in the "electronic" type circuits where your prints are in a point to point wiring scheme, Good Luck


Posted by Brian Kukulski on 20 December, 2000 - 10:25 am
We have adopted the following:

Panel Wiring side of PLC panel T/Bs. - Use the acutal PLC I/O address as a wire label. When troubleshooting from the PLC outward, you know the address and this makes the field wire and T/B is easy to find. Good for finding blown fuses fast. The addresses being sequential mean you terminal blocks are sequential. I tried using the Rack/Slot approach - good but but now I need a cross reference to the PLC I/O address - addresses and slot location are not necessarily the same . This works if the I/O cards are wired
sequentially out to terminal blocks and also quickens loop sheet drawing design. You can now have the panel built before you assign I/O to process instruments.

Field wiring side of PLC panel T/Bs - Use the Instrument tag (say LSHH123 ) and keep that tag until you touch the next device. Then change the tag to LSHH123-1 , -2, -3 etc. until you get back to the PLC. Now when you get back to the PLC you have a set of terminal blocks with the Instrument tag and a suffix on 1 side and the I/O address on the other side. This makes finding the PLC I/O point easy for ladder troubleshooting.

It will be interesting to hear other good ideas.


Posted by Bruce Axtell on 21 December, 2000 - 12:34 pm
Similar to this, I have seen where the wire number at the PLC terminal is the Device Tag Number that the wire goes to. So LS-123 would be the wire number at the discrete PLC input. At the other end of the wire, at Device LS-123, the wire number would be the PLC address that the wire goes to, Perhaps I:010/00. Thus, a maintenance person can walk up to any device
without schematics, and know exactly where the wire goes to, or at the PLC know exactly what device is connected to that input. You have a different wire number at each end of the same wire, but it identifies where the wire goes.

FWIW

Bruce Axtell


Posted by John G. Boland on 27 December, 2000 - 12:26 pm
Hi, Brian,

> Panel Wiring side of PLC panel T/Bs...
> Field wiring side of PLC panel T/Bs...
> It will be interesting to hear other good ideas.

Starting with a process and control diagram, a customer labels each wire (or twisted shielded pair) with the instrument tag, followed by the destination termination point.

Following a thermocouple signal through signal conditioning in cabinet "10", to an analog input in cabinet "5", each wire segment is labeled like this:

TE_123_A/CAB_10/Rack_04/12 (at t/c)
TE_123_A (entering sig cond)

TI_123_A/CAB_10/TBS_04/014 (leaving sig cond)
TI_123_A/CAB_10/Rack_04/22 (entering tbs)

TI_123_A/CAB_05/TBS_05/032 (leaving tbs)
TI_123_A/CAB_10/TBS_04/014 (entering tbs)

TI_123_A/plc_rack_i/o (leaving tbs)
TI_123_A/CAB_05/TBS_05/032 (entering plc)

The nature of the signal and its destination are labeled at each terminal point, so someone can start at any terminal point and work through the entire wire path.

The "real" wiring method also includes specifiers like "/CBL_xxx/" for multi-conductor cables and "/+24VDC/" or "/SIG_RTN/" when appropriate.

HTH,

John


Posted by Troy Stearns on 20 December, 2000 - 10:35 am
> We are trying to establish a standard for Plant Control(PLC) system wiring
> numbering. Two methods have been proposed and we have a problem to pick up
> a right one.
>
> Method 1: Start a numbering at PLC TB (our PLC TB are numbered according
> to RACK:SLOT:SIGNAL pattern, so a terminal, belonging to RACK 1, Slot 5
> Signal 14 would be numbered as 1514) and keep the number unchanged all the
> way via various junction boxes up to the field instrument terminals.
>

I am not a fan of the method you describe above, but I have encountered many who use it. If you use this method, make sure that leading zeroes are
strategically placed. Your example of wire # 1514 could also mean RACK 15, SLOT 1, SIGNAL 4. If leading zeroes are used these wire numbers would be 010514 and 150104 respectively.

> Method 2: Start a numbering at PLC TB and change the wire's number
> (according to terminal's number) each time the wire entering/exiting a
> terminal up to the field instrument terminal. This way both ends of the
> same wire will have different numbers.

Having the same wire with different numbers depending upon where it is connected, each time, would be a nightmare. If you have any daisy-chaining of wires you could have several different numbers for the same electrical signal. I would not want to have to debug anything labelled in this fashion. YUK!!!


Troy Stearns


Posted by Paul Tolsma on 20 December, 2000 - 11:42 am
I have always taken as invarient the idea that a terminal does not change a wire number. Method 1.

Speaking of which... I am currently working on a project with a German company and they do not use wire numbers at all. Connector numbers, harness
and cable numbers, terminal numbers, and wire colors and pin numbers... but no wire numbers. I am told by my vendor this is typical for Europe and IEC schematics. It's different, to say the least.

Paul T


Posted by Bouchard, James [CPCCA] on 20 December, 2000 - 11:45 am
I would not recommend using the PLC address as part of the wire number. Four major reasons:
1) if you change the addressing of the I/O point you have to change all the wire numbers
2) If you have more than one PLC you will have
duplicate numbers
3) you will need a different numbering scheme for wiring that does not go to the PLC
4) Using the PLC address does not allow you to
have devices in series connected to the PLC without going to suffixes etc.

We use a sequential numbering system which requires you keep a list of numbers used and where they are used.

For more discussion see Chapter 9 in "Fundamentals of Industrial Control " by Charles Albert and Don Coggan published by ISA

James Bouchard


Posted by R A Peterson on 20 December, 2000 - 4:02 pm
I would beg to differ. Using the PLC I/O address dramatically simplifies troubleshooting in the field, and makes it much easier to find wires on
drawings, and improves your ability to go directly to the PLC I/O point.

Most systems using PLCs do not have a lot of wires connecting between different PLCs so duplicate numbers is rarely a problem. The few wire numbers that interconnect between such systems can be handled separately if needed. In the few cases where I have added interconnections, generally I have appended a prefix to the wire number to indicate what PLC the wire comes from. For example: 01:I001300 is I:13/0 in PLC #1, and 02:I001300 is I:13/0
in PLC #2. I usually use the PLCs highway address for the prefix. In a few cases I have just used A, B, C, ... for the prefix.

Keeping track of a long list of random-like wire numbers is a much more daunting task.

Changing the I/O address is a problem, but is not that big of a deal in most cases. Most of the time when you change I/O addresses, its because you have changed PLCs. You can either renumber the wires to the new I/O address when you do so, or just live with it (not any worse then the more or less random number you advocate for the wires), as long as the drawings are accurate.
Changing the wire numbers is not all that daunting a task. You can print up new ones and install them fairly quickly (maybe a couple hundred an hour if you use self laminating wire labels). In a few days they can all be
converted to the new numbers.


Posted by Bruce Durdle on 20 December, 2000 - 5:10 pm
The most user-friendly system (for maintenance and troubleshooting) I have used is based on the tag number - after all, in most cases, this is the
common reference for operators, maintenance, engineers.

If a tech is looking to fault-find on LSH421, and sees a wire labelled LH421-1, it's probably the right one. If the number is 02-I12:24, who knows?

And then there are the grid-based systems - OK if you have the drawings.

If possible, base numbers on tags.

Bruce.


Posted by Blanco, Felix on 21 December, 2000 - 2:44 pm
We use a combination of the tagging procedures posted to the list. We have a ITB (Intermediate terminal Block) which uses Rack/Slot/Group/Channel (R/S/G/C) numbers (octal). For instance 0/1/0/1 means Rack #0, slot #1, group #0, channel #1. This ITB is in between PLC I/O and FTB (Field Terminal Block). The FTB uses the P&ID tag numbering, say LSH421. With this schema, both Operator and Instrument people can troubleshooting an instrument easy, from the field to PLC memory data table.

Felix Blanco
Venezuela


Posted by Richard King on 21 December, 2000 - 12:36 pm
Hi all,
I just though I would add my 2-bits worth on this topic. PLCs change, using PLC address on cables going to the field could be a big mistake.

regards,
Richard King


Posted by Bouchard, James [CPCCA] on 21 December, 2000 - 3:53 pm
We have machines with several different PLC's on them along with servo drives and lots of other equipment so the multiplication of addresses is a
concern. Since only about one half of the wiring is associated with the PLC I/O you still have to maintain the wire list.

Recently we had to relocate two cards in a PLC rack to make room for a module that had to be installed in a particular place. Changing the wire
numbers on those two modules took a technician 4 shifts so it is not negligible. We have also in the past combined two PLC's and had to change two racks of addresses.

When you consider that PLC's that use device net do not assign I/O addresses but only internal registers the argument for using the I/O as the wire number is less useful.

When you consider that newer PLC's and the IEC 1131 standard uses aliases instead of hardware addresses the reason to use the I/O address is even less valid.

What I prefer to do is to use the device number of the field device as the tag or unique identifier in PLC programming software. This allows you to simply search on the device number and you will get the part of the program you want. Since we put a device number tag on each field device the tracking is easy to follow.

James Bouchard


Posted by R A Peterson on 22 December, 2000 - 11:22 am
> We have machines with several different PLC's on them along with servo
> drives and lots of other equipment so the multiplication of addresses is a
> concern. Since only about one half of the wiring is associated with the PLC
> I/O you still have to maintain the wire list.

Maintaining the wire list in this case would be relatively easy if you made the wire number keyed to the drawing page number and index for wires not
connected to a PLC I/O point. This is by far the most common way of assigning wire numbers for PLC based control systems.

> Recently we had to relocate two cards in a PLC rack to make room for a
> module that had to be installed in a particular place. Changing the wire
> numbers on those two modules took a technician 4 shifts so it is not
> negligible. We have also in the past combined two PLC's and had to change
> two racks of addresses.

Four shifts to change the wire numbers on just 2 cards? Even if they were 16 point cards, and there were three wires on each point that had to have new wire numbers, thats less then 100 new wire numbers. 32 hours seems really excessive unless you were using something other then self-laminating wire labels. Thats 20 minutes per wire number. I would expect more like a minute
per.

> When you consider that PLC's that use device net do not assign I/O
addresses
> but only internal registers the argument for using the I/O as the wire
> number is less useful.

But device net is a very small part of installed systems. I would grant that some thinking may need to be done when/iff you use device net or other similar busses that do not have traditional I/O addresses. But for MOST PLC based control systems, this is not an issue.

> When you consider that newer PLC's and the IEC 1131 standard uses aliases
> instead of hardware addresses the reason to use the I/O address is even
less
> valid.
>
> What I prefer to do is to use the device number of the field device as the
> tag or unique identifier in PLC programming software. This allows you to
> simply search on the device number and you will get the part of the program
> you want. Since we put a device number tag on each field device the
tracking
> is easy to follow.

This does make some sense when you have tag numbers for all the field devices (such as in a chemical plant). Most of the time PLC based controls make the device tag number a function


Posted by Bouchard, James [CPCCA] on 27 December, 2000 - 12:04 pm
*> We have machines with several different PLC's on them along with
*> servo drives and lots of other equipment so the multiplication of
*> addresses is a concern. Since only about one half of the wiring is
*> associated with the PLC I/O you still have to maintain the wire list.

*Maintaining the wire list in this case would be relatively easy if
*you made the wire number keyed to the drawing page number and index
*for wires not connected to a PLC I/O point. This is by far the most
*common way of assigning wire numbers for PLC based control systems.

Tying the wire number to the sheet poses the same problem as tying it to the I/O address. If you change the order of the sheets or redraw the drawing the wire numbers no longer match. It is not as common as you state. I have seen all three used in about equal proportions.

*>
*> Recently we had to relocate two cards in a PLC rack to make room
*> for a module that had to be installed in a particular place. Changing
*> the wire numbers on those two modules took a technician 4 shifts so
*> it is not negligible. We have also in the past combined two PLC's
*> and had to change two racks of addresses.

*Four shifts to change the wire numbers on just 2 cards? Even if
*they were 16 point cards, and there were three wires on each point that
*had to have new wire numbers, thats less then 100 new wire numbers. 32
*hours seems really excessive unless you were using something other then
*self-laminating wire labels. Thats 20 minutes per wire number. I would
*expect more like a minute per.

They were 32 point cards and it took a long time because of the crowded space and the numbers had to be changed in several places in the
machine that are not the most accessible

*>
*> When you consider that PLC's that use device net do not assign
*> I/O addresses but only internal registers the argument for using the
*> I/O as the wire number is less useful.

*But device net is a very small part of installed systems. I would
*grant that some thinking may need to be done when/iff you use device
*net or other similar busses that do not have traditional I/O addresses.
*But for MOST PLC based control systems, this is not an issue.

Actually it is becoming more common especially for larger machines that are fully assembled in the factory for testing then taken appart for shipping and reassembled. The reassembly time savings for a single machine can amount to several man weeks.

*>
*> When you consider that newer PLC's and the IEC 1131 standard
*> uses aliases instead of hardware addresses the reason to use the I/O
*> address is even less valid.
*>
*> What I prefer to do is to use the device number of the field device
*> as the tag or unique identifier in PLC programming software. This
*> allows you to simply search on the device number and you will get the
*> part of the program you want. Since we put a device number tag on each
*> field device the tracking is easy to follow.
*>
*> James Bouchard

*This does make some sense when you have tag numbers for all the field
*devices (such as in a chemical plant). Most of the time PLC based
*controls make the device tag number a function of the I/O address (such
*as I10100PB).

Again this depends on your machine builder and your own standards. We have always requested unique tag numbers for devices and we are not a process industry at all. If you go back and look at some of the earlier standards on schematics the standard was tags.


Posted by Paul Tolsma on 22 December, 2000 - 1:15 pm
Very well put. We are also grappling with the "wire number" question, and I am not pushing for controller I/O numbers on the wires for the same reasons James mentions. I have in the past been successful with wire numbers that are derived from line numbers on the schematics rather than I/O numbers or the device numbers themselves. The wire numbers on each side are the same when the wire passes through terminal blocks. There are some wire numbers that for convenience are not schematic line numbers- those related to phase conductor feeder and branch circuits, or the neutral conductor, or to a DC
+ and the corresponding DC common for example- but using line numbers from the schematics does a few things.

First, you can assign line number ranges to particular types of I/O. For example, we're presently using 2000 - 2499 for DI. When I grab the wire in the field, I know what it is and since the line numbers are unique, I can also find it in the prints quickly. If I have more than 500 DI on the machine (not often) there are some "overflow numbers" in the scheme that are used if a range runs out.

Second, I can have multiple people working on the drawings at the same time. Since the wire numbers are not assigned by the software and they are not sequential, I can work on DI loops, you can work on DO loops, somebody else has AI/AO, etc. Nothing is stepped on by someone else.

Third, as I design the machine my numbering stays consistent. If I start out with 40 air solenoids and leave 48 outputs to drive them, then solenoid
41, added during debug, falls after the existing solenoid 40 and the wire numbers follow as well. If all wires were numbered sequentially as they
were drawn in, then any grouping you might try to do is lost. Quickly. <g> Trying to leave unused numbers in a sequential scheme is possible but hard to manage.

Fourth, as I physically make and apply wire lables, I have at most 5 characters- the number and then A, B, C, etc. if the wire runs through
multiple devices. If the wire runs through a device the number changes (2000A, 2000B, 2000C, etc); if it runs through a terminal block it does
not. Which way you want to work the A, B, C- from the final element or from the controller- is up to you <g>.

Is it perfect? Nope. I've used most of the schemes put forth in the last few days and they have all worked. I do think that as we move to
controllers without fixed I/O addresses as in the past, that some sort of wire numbering that does not depend on the controller I/O address is
important. Also, I freely admit that your mileage may vary; I've used the above approach on OEM process equipment and machines that are typically run by a single PLC, with less than 500 points and 100 analog channels. For large systems, spread over several thousand square feet, something else may be more appropriate.

Paul T


Posted by Michael Griffin on 22 December, 2000 - 4:31 pm
At 11:15 22/12/00 -0500, paul_tolsma wrote:
<clip>
>Is it perfect? Nope. I've used most of the schemes put forth in the last
>few days and they have all worked.

I think this is part of the problem. Everyone has at least one method and each method has some merit to it. I have used several methods,
and have been dissatisfied with all of them. I should think this would be a suitable topic for an official standard. I hate creating my own 'standards'. I have a copy of an old JIC standard, but this uses the simple 1,2,3 method
on a small relay logic system.
The most common method I have seen involves wire numbers being derived from PLC I/O addresses or drawing page/line numbers (for wires not directly associated with I/O). The PLC I/O based numbers haven't really been a problem for us, it's the page/line number ones that seem to have the most trouble. Some designers seem to get so obsessed with maintaining the purity of it that they let it affect their electrical design.
Is anyone aware of a recognised standard suitable for numbering wires on small PLC controlled machines whose drawings are layed out in typical JIC ladder format? This standard should cover assigning wire numbers, how wire numbers relate to device tags, etc. If such a suitable standard does exist, is there any reason why everyone is not using it?


**********************
Michael Griffin
London, Ont. Canada
mgriffin@odyssey.on.ca
**********************


Posted by Bouchard, James [CPCCA] on 28 December, 2000 - 9:37 am
Since you have limited the scope to small PLC controlled machines you have part of your answer why everyone is not using the same standard. To be
really useful a standard should cover a wide range of machine sizes and applications. Many plants have a variety of machine sizes and would like to have one standard for all instead of different standards for each size or type of machine.

James Bouchard


Posted by Michael Griffin on 28 December, 2000 - 4:58 pm
There may be a reason why a single standard may not apply to every possible circumstance, but I cannot imagine why a single standard does not
even exist for something as limited in scope as I have specified. I believe I have seen every method mentioned so far used on small machines. If a single standard is useful and practical for all possible machine sizes and types, then that is fine. "Small" is a relative term. Most machines can be considered "small".

This still leaves the question though; given the potential usefulness of a common standard, why is one not being generally used? What would be a suitable body for publishing such a standard?

I do agree with you that the page/line number system does not work very well when a machine requires anything other than a minor retrofit. It is really only useful for the convenience of the person doing the initial
design. During subsequent modifications you are back to assigning numbers arbitrarily. Attempts to preserve the numbering system always seem to
sacrifice the readability of the drawings.


**********************
Michael Griffin
London, Ont. Canada
mgriffin@odyssey.on.ca
**********************


Posted by Ken Brown on 28 December, 2000 - 5:01 pm
Michael,

Perhaps this can be best illustrated with a few metaphors . . .

Why can't we have a standard for how steak should be prepared?
Why can't we have a standard for how people should dress?
Why can't we have a standard for how you should comb your hair?

Times change, options change and everyone works a little differently than everyone else. I don't believe that any measurable benefit will come from
standardization of the sort you are dreaming of - at best, you will have a standard that works for you but is a PITA for the rest of us. Look at the
attempts that have been made thus far and they are anything but "standard". Take Rockwell for instance, if you standardized on any kind of wiring number system that could be logically applied to the PLC5 or SLC5 family of
controllers, you would be hosed when you graduated to the ControlLogix platform. The same could be said for any forward thinking PLC manufacturer who is bent on improving their products and upgrading the software tools you
use to configure the machine. I am not discounting the value of having a standard, but at the same time I have not identified anything of universal value in the standards that have been proposed to date - each machine has a
different set of requirements. The cost savings realized by following a standard across a diverse group of machines (or even within a single
machine) are rarely ever realized and if the truth be known, adherence to standards often costs more due to the simple fact that the standards change every couple of years (or months) due to market forces / advances in
technology leaving you in a state to where all your machines are no longer built to the standard OR in a state where all your machines are built with older, more costly and less capable components that fit within your definition of the "standard" . . .

OK, I feel better now . . .

Ken Brown


Posted by Michael Griffin on 29 December, 2000 - 9:44 am
At 16:52 28/12/00 -0500, Ken Brown wrote:
<clip>
>Perhaps this can be best illustrated with a few metaphors . . .
>
>Why can't we have a standard for how steak should be prepared?
>Why can't we have a standard for how people should dress?
>Why can't we have a standard for how you should comb your hair?

Actually, there are "standards" for all three, they are just called "styles" or "recipes". People don't often create their own "standard" for any of these items, they tend to conform to the general practice they see
around them. Why can't we do the same for wire numbers? Why does a factory need more wire numbering systems than a restaurant needs steak recipes? Do I need to point out that a "steak" comes from a standardised way of butchering
cattle? I think you are arguing my point here, not your own.

<clip>
>Take Rockwell for instance, if you standardized on any kind of wiring number
>system that could be logically applied to the PLC5 or SLC5 family of
>controllers, you would be hosed when you graduated to the ControlLogix
>platform.

I believe that one of Mr. Bouchard's points was that a wire number system should not be based on the I/O characteristics of any particular model of PLC. If he has to change the PLC in the machine to a different model or re-arrange the I/O, he doesn't want to have to renumber all the I/O wires. This has not been an especially large problem for me so far, but I
can see that his point has merit.

<clip>
>I am not discounting the value of having a
>standard, but at the same time I have not identified anything of universal
>value in the standards that have been proposed to date - each machine has a
>different set of requirements.

I agree that no one has demonstrated a numbering system with which we can all concur has "universal value" - that is precisely the point and that is the reason why this debate was begun. The original problem being discussed was that some of the numbering systems often used don't even have value in the particular applications they were being used in, let alone in
any others.

>The cost savings realized by following a
>standard across a diverse group of machines (or even within a single
>machine) are rarely ever realized and if the truth be known, adherence to
>standards often costs more due to the simple fact that the standards change
>every couple of years (or months) due to market forces / advances in
>technology leaving you in a state to where all your machines are no longer
>built to the standard OR in a state where all your machines are built with
>older, more costly and less capable components that fit within your
>definition of the "standard" . . .
<clip>
What is so difficult about numbering wires? What is there about "market forces" or "technology" which would invalidate any of the numbering systems which have been discussed so far? I believe the original point discussed was that certain methods of numbering wires had deficiencies. All of the problems discussed were problems that would have been equally true
ten years ago as they are today.

My own point was that surely there is no value in me creating still another numbering "system" of my own. If certain methods work better than others, why should I have to discover these solutions for myself? Would it
not make more sense for me to learn from the experience of others? Is this not the means by which knowledge is advanced? Perhaps we could even discover something which solves Mr. Bouchard's problem.

The question still remains, can anyone point to a publicly available standard suitable for the numbering of wires in small PLC controlled machines?


**********************
Michael Griffin
London, Ont. Canada
mgriffin@odyssey.on.ca
**********************


Posted by Mike Ryan on 2 January, 2001 - 1:41 pm
Ken, that's an interesting point in light of our method. We use Rack/Slot/Point for the wires in the I/O cabinet. But notice that these are not addresses, instead they are names for physical entities. We have ControlLogix, PLC5 and SLC.

We name our ControlLogix racks RAC01, RAC02, RAC03... and our cards R01S00, R01S02, R01S03... So it makes perfect sense to us to label the wire
"DI010015" for point 15 of the digital input card "R01S00" which is in slot 0 of rack "RAC01".

Mike Ryan
Aerojet Fine Chemicals


Posted by Bouchard, James [CPCCA] on 29 December, 2000 - 10:51 am
The old JIC standard actually did what you wanted but it was probably not well publicized nor supported. Probably the biggest problem with a standard of this type would be getting copies to everyone who does electrical design or purchases equipment so they know it exists and should be used.

James Bouchard


Posted by Michael Griffin on 2 January, 2001 - 12:37 pm
At 10:40 29/12/00 -0500, James Bouchard wrote:
<clip>
>The old JIC standard actually did what you wanted but it was probably not
>well publicized nor supported.
<clip>
I have an old JIC spec that simply uses the 1,2,3,... method. I have seen a variety of different methods which various people claimed were a "new" JIC method. None of these people actually had a copy of this spec (nor do I), they just clained to have heard about it from someone else and added their own twist to it. None of these methods seemed to address the concerns
you had.

>Probably the biggest problem with a standard
>of this type would be getting copies to everyone who does electrical design
>or purchases equipment so they know it exists and should be used.
<clip>

To perhaps re-phrase your statement, there would be a problem if people had to each individually purchase the standard from some organisation. If people doing electrical design could freely e-mail copies to each other, and if people puchasing equipment could send out a copy with
their RFQ, it would in fact diffuse through the industry rather quickly.

I don't however want to start the "free standards" debate over again. I thought though, if there were a suitable standard published we
could discuss its relative merits.

**********************
Michael Griffin
London, Ont. Canada
mgriffin@odyssey.on.ca
**********************


Posted by Rufus on 2 January, 2001 - 1:52 pm
No doubt standards would come up with variations in a similar way the Fieldbus "standards" are made or the 61131-3 languages are "standard".

Opposite endpoint labeled? Otherendian.
Terminal block/point numbered? Termblockated.
Global unique numbered? Gluniq coded.
Harcopy page/coordinate labeled? Hardcoppaged.

The point being, if there were several standards, all with their own relative merits, life could still be simplified by using one of a half dozen
documented techniques, it would still be better than a different system for every machine.

And If I could say: here's the URL of our wiring standards, that would be slick.


Posted by Anthony Kerstens on 2 January, 2001 - 1:56 pm
Standards, standards, standards.... Ugh.

I have seen many people attempt to "standardise"
many different things. There is something that
my english teacher in high school taught me that
is very applicable.

When you write, you have to consider:
- Your subject.
- The detail required to properly treat the subject.

and most importantly,
- Your audience (customer/user).

Basically, a "standard" is not just a template,
it's a communication to your audience on how you
view things (and want things done). You have to define the subject with sufficient detail that the audience will understand. Your writing (design) has to be sufficiently interesting (useable/likeable) for the audience to pay attention to it.

I'm not going to suggest a wire numbering schema simply because I've done things different ways to
suit particular circumstances, and particular audiences.

Take the pick of the crop and run with it.


Posted by Ken Brown on 2 January, 2001 - 2:45 pm
Thanks Anthony,

You put into words something that has bugged me about this entire thread.

Ken Brown


Posted by Ryan, Mike on 8 January, 2001 - 12:38 pm
Why do these threads always degenerate into pseudo-philosophical rants. A guy asks a simple question in this case: ---------- Forwarded message ---------- We are trying to establish a standard for Plant Control(PLC) system wiring numbering. Two methods have been proposed and we have a problem to pick up a right one. Method 1: Start a numbering at PLC TB (our PLC TB are numbered according to RACK:SLOT:SIGNAL pattern, so a terminal, belonging to RACK 1, Slot 5 Signal 14 would be numbered as 1514) and keep the number unchanged all the way via various junction boxes up to the field instrument terminals. Method 2: Start a numbering at PLC TB and change the wire's number (according to terminal's number) each time the wire entering/exiting a terminal up to the field instrument terminal. This way both ends of the same wire will have different numbers. What method would you recommend ? (one of above or any other "good practice"). ------------------------------------------- Victor is looking for guidance, recommendations, support from the community. He asked for help choosing one of two proposed choices and left it open for us to suggest other "good practices". This seems healthy to me. So, I follow the thread hoping to see what others consider to be good practice. Instead, we get rants about standards.


Posted by Anthony Kerstens on 8 January, 2001 - 5:26 pm
Mike, This is a discussion group. Things go off on a tangent, and that's just as natural as any other conversation. If you've been part of this for some time, you may have noticed that some discussions have gone far away from the original topic, and have been quite interesting and informative. There's more to this group than just tech support. That said, I suggest you re-read Victor's message. The first thing he said was he was trying to pick the "right" standard for his plant. When the thread began, there were good suggestions and alternatives presented. Also note the final part of my response to which you had responded (here it is).... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'm not going to suggest a wire numbering schema simply because I've done things different ways to suit particular circumstances, and particular audiences. Take the pick of the crop and run with it. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The part I suspect you are interpreting as a rant is the prelude and explanation to this advice. Do you agree or disagree with this advice, or are you just ranting? Anthony Kerstens P.Eng.


Posted by Amr Elaguizy on 29 January, 2001 - 5:30 pm
One method I have seen that worked great for troubleshooting and installation was have both numbering at the end of each wire. One closet to the TB has the chosen numbering for the this side then a space and the numbering for the next device this wiring is going to. For an example, if the wire is landing on device 107, TB identification TB9, terminal #5, then the wire number closet to the TB will be 107TB905. And if the same wiring going to device 105 TB 6 terminal 7, then the same wire at 107 will be number 107TB905 105TB607, while the same wire at device 105 will have 105TB607 107TB905.


Posted by Bouchard, James [CPCCA] on 27 December, 2000 - 11:16 am
My experience has been that trying to leave free wire numbers, inputs outputs pages or just about anything else eventually breaks down and you
have to go out of sequence. As a result I do not try to keep things grouped. Our machines have from 100 to 1000 digital I/O and a lot of hard wired safety circuits ( a large machine can have over 100 guard switches ) We also make changes, often significant and major, on a regular basis as often as yearly so a grouping scheme can soon break down.

I have avoided wire numbers based on line numbers because we add and subtract sheets and move things around which messes up an line number based
system ( we base our line numbers on the sheet at the first 3 digits ) Also it becomes difficult to assign numbers if you have wires that appear on
several pages. This is a problem with European manufacturers as then create a lot of sheets with very little on them. I have schematics that are 450 sheets long as a result and a wire can easily cover a half a dozen pages.

James Bouchard


Posted by Roderick K. Duet on 21 December, 2000 - 1:00 pm
We use the I/O type input or output followed by address.
Ex:: I:1.1/04
This scheme is used from the PLC to the field device.
The input and output devices or then labeled as type of device and address.
Ex: AV-1.1/04
AV = Air Valve
SV= Solenoid Valve, Etc.
Analog is done in the same scheme
Ex: I:4.0
LT-4.0
LT = Level Transmitter

From the time we implemented this wiring scheme the familiarization of a system and devices seams to be easier followed by plant engineering
staff. The wire labels can get wide depending on the system but thats what high cpi on the printer helps. I use as high as 17 and or still very
legible. Labeling the device with the address extension also helps in labeling panel components. Ex: MS-1.1/04 or CP-1.1/04 or PDP-1.1/04
Well you get the idea.


Posted by Ryan, Mike on 21 December, 2000 - 2:40 pm
Our plant prefers 'destination-based' labels. We use the Rack/Slot/Point label inside the PLC cabinet so from the IO card to the intermediate
terminal the wires are labeled like: DI010215 for a digital input, rack 01, slot 02, point 15. Then from the intermediate terminal out to the field the wires are labeled with their destination. An example might be:

Wire from PLC IO card to terminal in PLC cabinet:
IO Card Terminal Strip
-------- --------------
DI010215 <-----> DI010215

Wire from terminal in PLC cabinet to field junction box:
PLC Cabinet Field JB
----------- -------------
JB00201-19 <-----> CAB00205-1-25

Wire from field junction box to device:
Field JB Device
-------- ----------
LSH-0001 <-----> JB00201-19

That is a worst case example. Usually, there isn't a field junction box, so the intermediate terminal in the PLC cabinet shows the PLC IO point as the internal label and the device tag as the outgoing label. This makes trouble shooting a total breeze for our techs.

Mike Ryan
Aerojet Fine Chemicals


Posted by Scot Sutherland on 22 December, 2000 - 11:48 am
The system I typically use is based upon Chrysler's controls design standards.
The wire number is based on the line number.
For instance, on line #324 the wire number would be 324.
If there is more than one wire on line 324 (if there are a series of relay contacts, for instance) then the subsequent wire numbers would be 3241, 3242, 3243...
Additionally, the devices are numbered per the line number they are drawn on.
A push button drawn on line #512 would be named 512PB.
This method accomplishes a couple of things:
1) Choosing wire numbers is easier. There is no "Did I use wire number 53 already?"
2) Finding the sheet number where the wire is referenced is easier.

Scot Sutherland
Software Engineer
Spire Corporation
1 Patriots Park
Bedford, MA 01730
(781)275-6000
ssutherland@spirecorp.com


Posted by Bouchard, James [CPCCA] on 27 December, 2000 - 10:36 am
With this method you can never change the line number without changing the numbers on the wires or devices. If the line number is based on the sheet number you can't change the sheet number either.

James Bouchard


Posted by Paul T on 27 December, 2000 - 1:22 pm
You don't typically need to change either the line numbers or the sheet numbers in the print package. The line numbers are fixed at some convenient spacing on the sheet, for example every 1/2" or 1", and serve as a reference; they are on the blank page and the drawing is built using them. They are not added after the schematic is drawn, so if you fill in blank
areas on the sheet during the job, the numbers are already there. As far as sheet numbers, you typically leave blank sheets for each slot in the rack if you have unused slots. If they're used later, the sheets are already there. You're correct that you can't change the line number without re-labeling the wires, but that applies to any system once you've actually started building to a print.

Paul T


Posted by RA Peterson on 29 December, 2000 - 2:28 pm
>The old JIC standard actually did what you wanted but it was probably not
>well publicized nor supported. Probably the biggest problem with a standard
>of this type would be getting copies to everyone who does electrical design
>or purchases equipment so they know it exists and should be used.

The old JIC standard basically followed the concept of using page and index numbers for the wire numbers. This was before PLCs. Once PLCs became common, most of those using JIC type standards switched to using I/O addresses for the wires attached to I/O points.

With the advent of the new I/I like Devicenet, there is not a real great way to do it anymore. Fortunately for most of us, we are stuck with regular I/O and probably will be for the forseaable future. Devicenet is not a big part
of the I/O business and probably won't be for some time (if ever).

Maybe by the time it hits we will have figured out some standard that works well for all concerned.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
"Laughter is the closest distance between two people."
-- Victor Borge
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive