Configuration Strandards

Before I ask the question, let me preface it by saying that I came from the DCS world to the PLC world. I am used to tags and logic based off of the tagnames. Now for the question;

In hiring out your PLC work, is it pretty much up to the individual doing the work to organize logic into the format requested, or is it just pot luck?

I am asking because I am troubleshooting ladder logic, and I am not following it too easily. Part of the problem is that out of 20 controllers I have looked at, there are about 10 different styles of logic used. Also, I am used to having a PIC100100 and a PI100100 and Logic assocoated with it at INT_PIC100100 or a run indication like MI100100.

I have been happy to find a program or 2 grouped in such a fashion, but not as a standard.

Any thoughts?

When farming out controls work for any platform, if you do not specify everything, then you get whatever the vendor supplies.

We have a document called general design principles for controls systems programming that covers almost everything. Naming, tags, colors for graphics etc...
We then have individual packages for each job, called "Project application specification". This covers exactly how the logic executes, in what order, faults, interlocks, etc...

For many small companies they don't have the staff to support this level of documention, so they give the PLC vendor some very vague process description, and then the vendor makes it work. No uniform structure from machine A to B.
Because of the expense and applications usually associated with DCS systems, you're talking large Companies, with lots of staff, perhaps Corporate mandates on automation etc...

Bottom line, money. Uniform programming and documentation is nice, but expensive.

Just my opinion.

Ken

Since this field is unregulated, and there are many competitors (each with their own idea of what a good standard is) you will find that there is not one, and only one, industry-wide standard.

You will find that "non-standard" is more common than "standard".

There are a couple of "standards" floating around out there, however, there is absolutely no way to enforce any kind of industry-wide standard.

If a standard exists at all, for any given project, it is only because the purchaser specified a particular standard, or, if the purchaser didn't specify a standard, then the builder has a particular standard that works for him.

The purchaser might have specified one of the existing standards or he might have specified his own custom standard. The purchaser can define his custom standard in any fashion he wants. Let your imagination go wild... that's how many variations there can be.

If the purchaser doesn't specify a particular standard then the builder is free to use whatever standard he wishes... if he uses any kind of standard at all. Again, let your imagination go wild... that's how many variations there can be.

Since you say that you come from DCS, I'm going to venture a guess that your experience is with one of the "Object-Oriented" Languages.

A linguest told me: "Language changes the People; the People change the Language"

Shoeman:

Much of what you see is simply a result of the programming environment.

In a DCS, you have a "SCADA" which is married to a "PLC". As such, there is something closer to object-oriented programming. When you create an object (a motor, say), you will have the graphical object and all the tags and connections needed for that object (Output and Feedback, Auto/Manual statuses and commands, Interlocks, etc., etc.)

In the basic PLC programming environment, you don't have any of that structure inherent in the programming enviroment. All you have are inputs and outputs, and lots of directly accessable memory. There are no "motors" or "valves" or "sensors". There is no graphical interface that needs to keep track of where to put information from the operator. Certainly, one can be added on (and, not by coincidence, you can add the same software that a DCS uses (such as Fix/DMACS in Honeywell DCS's). But because it's not a requirement, the imposed structure that they bring is missing.

What many of us have done is "re-invent the wheel". That is, we impose a structure that will compliment the way that the HMI/SCADA package we're going to use, and make it easier to find addresses.

But since many of us have never even SEEN a DCS, much less programmed one, our "re-invention" turns out differenct for each one of us. And then there are those who don't even bother making the attempt. They are often time-pressed, and just program by "the seat of their pants", throwing code in and grabbing the next likely looking address, until the thing is in some sort of working order.