Programming Style

[andydaoust]

I'm working on a project in which someone wrote the lamest program I've ever seen. I'm am basically a beginner in the PLC programming world. I have however been an instrument technician for 20 years and have had to fix a number of bonehead programs. I feel a guideline would make the end users job easier and more cost effective in the end. For example, we always use a certain brand of pressure switches. They work in our environment, save labor because they hold there setpoint and don't need calibrating. We had a contractor save $50 per switch on a project with 200 pressure switches by using a brand different from our standard. Good for him, he made more money. Bad for us. We had to replace half of them. This required buying the new switch, redoing the conduit and costing who knows how much in down time and lost production. To be fair our management in the interest of maintaining a high level of bonus allowed the contractor to use the inferior switch.

Back to my bonehead program. This person used physical outputs in their logic. Now if I force an output, I also force many other pieces of the program with unknown results. If they had done this consistently it would be better, they did not however. So a standard which said the outputs will be addressed only once would keep that from happening. It wouldn't be dictating the body of the program just how the outputs are being addressed. Then if I want to stroke a valve, for example, I don't have to worry about some other valve opening or motor starting. The program would be meeting our maintenance needs. There are many other things in this program that are poorly written. Such as how is a component failure is handled. A guideline would've helped here as well. Thanks for letting me rant my frustrations. I will be asking for help on many of the problems as it looks like I will be re-writing the whole thing.

 

[Ron Beaufort]

From the previous post by andydaoust:

This person used physical outputs in their logic. Now if I force an output, I also force many other pieces of the program with unknown results.

Now you’ve got my curiosity up. What brand of PLC is this? I’m mostly familiar with Allen-Bradley. With those, if you force an output address it will not affect the rest of the program. That’s because the status of the output bit (in the data table) will NOT change - even though the real-world output will be forced (off or on) to the desired state.

On the other hand, when you force an input address on an Allen-Bradley, the status of the input bit (in the data table) WILL change.

I don’t doubt what you’re saying (and I THINK I understand what you mean) because I know that all PLC’s are NOT the same. But I’d like to know more about the one you’re working with. Sounds like something that ought to be added to my little notebook of knowledge.

Thanks in advance.

 

[Guest]

Ron,

AB SLC 500. Maybe I’m screwed up on how forcing is accomplished. I’m a beginner and have only written a couple of programs SLC 500 and 100. When I wrote them I assumed that if I forced an address, the address was forced throughout the program. This is the way it worked on a Turbine Control system I cut my computer control teeth on. You could force any point internal coil or whatever on that system however. Dangerous things could happen if you did not know what you were doing. I see from your other post in the other threads that the PLC writes to an output image table and you cannot force any internal logic. Is that correct? I see your point as the PLC does not read from the Output table to execute the ladder. If I force an Input then the program will execute just like the PLC was seeing the input change, correct? This project I’m working on is the first time I’ve had to find the problems in someone else’s program. Everywhere I look, nothing works right. Reading your post have really helped me understand the Basics and realize I know enough to be dangerous. So I will use caution and ask for help along the way.
Thanks

 

[andydaoust]

Ron,

I guess I can't figure out how to post either! I did so as unknown above. Ignore the verification on the Input force as you answered it. I didn't fully edit it prior to posting and I couldn't edit my response since I'm not unknown.

Sorry

 

[Rick Densing]

You learn something every day. I never knew that about output forcing. In retrospect, it jives with what I have seen, but was puzzled about. I often force outputs off when commisioning a machine, but some of the logic will act like it is on. That 'splains that.

 

[Ron Beaufort]

Yo, Andy,

NOTE TO ONE AND ALL: The discussion which follows is based on an Allen-Bradley SLC-5/04 processor. Other brands and models may function differently.

As to your statement:

Maybe I’m screwed up on how forcing is accomplished.

You wouldn’t be the only one - this dog has bitten many “should-have-known-better” butts. Take a look at this:[attachment]
To answer your specific question:

I see from your other post in the other threads that the PLC writes to an output image table and you cannot force any internal logic. Is that correct?

Your question is ambiguous. Here’s what you CAN do. You can force an input ON or OFF. Specific definition: an “input” is an address which starts with the letter “I”. You can force an output ON or OFF. Specific definition: an “output” is an address which starts with the letter “O”. You CANNOT force any other type of address. Specific definition: “any other type of address” is one which does NOT start with either a letter “I” or a letter “O”. In other words, B3/0 cannot be forced.

Now notice that I specifically said: “You can force an input - and you can force an output”. More importantly, notice that I did NOT say “You can force an input BIT - and you can force an output BIT”. That’s the part that confuses most people. You never force the BIT (the box inside the processor). Instead, you force the signal going-to or coming-from the processor. Specifically, when you force an input, you force the signal leading INTO the processor - that’s why the input bit changes. Input forces are applied “upstream” of the bit inside the processor. But when you force an output, you force the signal leading OUT OF the processor - that’s why the output bit does NOT change. Output forces are applied “downstream” of the bit inside the processor.

Another specific question:

If I force an Input then the program will execute just like the PLC was seeing the input change, correct?

Correct - because forcing an input reflects the forced status (OFF or ON) in the input bit. Then anything in the ladder program which examines that bit, will see the FORCED status.

On the other hand, forcing an output does NOT reflect the forced status (OFF or ON) in the output bit. That means that anything in the ladder program which examines that bit, will NOT see the FORCED status. Instead, anything in the ladder program which examines that bit, will see the status which has been commanded by the ladder logic instructions.

That’s why the oil pump won’t run when the compressor is forced on.

Finally, It sounds like you REALLY want to understand this. So if you’re still confused, you can send me a private message with your phone number. I’ll be happy to try to talk you through this by phone. I’m running out of typing time.

 

[andydaoust]

Forcing

Ron,

How could I be confused with that explanation? Very well put! Even an old dog like me can get it. Thanks for your effort.

Andy

 

[Allen Nelson]

One more thing to consider:

Andy complained about the use of output contacts. Let's say that his bonehead had used inputs instead. In the second rung of logic that Ron posted, let's say, instead of the Compressor output, the Compressor Aux Contant (i.e, input feedback) was used.

Then when you force the Output, the Compressor Start Relay will be pulled in, starting the Compressor. The Aux Contact from the start relay will also come ON. Therefore, if the input is used and the Compressor is Forced On, then the Oil Pump would also come on. This is exactly the result that Andy doesn't want.

 

[Guest]

Allen,

Good point.

Here's another take. If the oil pump was used to lubricate the compressor bearings and therefore must always run, then using the aux contact to start the oil pump would be preferred. In case some bone head maintenance guy like me decides to force the compressor on. Of course I would write the program so some oil pressure switch feedback actually started the compressor. It makes me think that when programming I should consider:

The required control sequence- don't allow the logic to put the machine or personnel in danger

Input or output failures (external or internal)- Will the failure cause an unsafe or undesirable result, if so monitor for failure and write contingency logic. For example, If RTD fails shut down unit and alarm, or if using multiple RTD's, reject the bad one from logic and alarm.

Power failures- Will the data be retained or not? Will the motor restart on power restoration? Thanks to Ron for that example.

Logic forcing- If someone forces this point, what will happen?

Required maintenance- Does a transmitter need to be calibrated while the process is operating? Do we need double or triple redundancies for safety in case a bone head maintenance guy or operator takes a transmitter out of service?

Trouble shooting- Will only regular electricians, not programmers, going to do the trouble shooting? Should we stick to straight relay logic even if it would be more efficient to use higher level commands?


I suppose after a while this becomes second nature.

There is great info exchange on this forum. Thanks to all.

 

[PLucas]

Note for Ron Beaufort's little note book.

Ron

If you ever have the unfortunate experience of having to deal with a GE series six machine then a point to note is that if you override an output, then every contact related to that output within the program is also changed, That goes for auxilary outputs as well (flags)

This is the only PLC that I deal with that does this (GE series 6, S5 and S7 200's and 300's)

Although in the GE beast you 'override' not force, there is a suttle difference.

Paul

 

[Ron Beaufort]

thanks, paul,

that's the type of information i'm always looking for - the exceptions to the "rules" - i'm learning as i go - never say "never" - never say "always" - never say "all" - never say .... well, you see what i mean.

again, thanks,

 

[RMA]

I discovered this thread as a result of the recent "Forces in Rslogix 5000" thread. Since it is so old, I thought it worthwhile to kick it back up to the top for other newbies like me, who might otherwise have missed it.

There's a host of things in here that I suspect I'll come back to later!

 

[Ken Moore]

RMA,
Thanks for reviving this post. I too am a newbie here and had never read it.

We do most of our programming in house, but sometimes we farm out larger jobs because we just don't have the manpower. Over the years we have developed a document that is called a "General Design Principle for PLC programming". We list the documentation specifications. We list what HMI colors to use for what condition, red = alarm, green = something etc...

We then list all the features a discrete device such as a motor should have, alarm, fault, interlock etc...

We have another list for analog devices, alarms, "bad" signals, etc...

We also specify other things such as error handling etc...


So.....
At the end of the day, we specify the end results, what features/functions we require and expect. The vendor can accomplish this however he sees fit. We include the specification with the bid package, so that if something isn't as specified, we can deny payment until the specs are met.

BTW,
We use the same specificaion in house, and like mentioned earlier, we never have two people write the exact same code. But, we do end up with exact same results.


Just my opinion.

KEn

 

[dandrade]

From the previous post by andydaoust:
Now you’ve got my curiosity up. What brand of PLC is this? I’m mostly familiar with Allen-Bradley. With those, if you force an output address it will not affect the rest of the program. That’s because the status of the output bit (in the data table) will NOT change - even though the real-world output will be forced (off or on) to the desired state.

Thanks in advance.

Yes. affirmative. This occurs for some PLCs.
PLC Taian TP02 Taian Electric (Bad link momentary)
It exists other manufacturers, small, that in old models it remains. This is item of the Inspection list - Evaluation hadrware

---

The essence of the question: As to define the contend to programming.

The techniques to define a consistent programming, it exclusively depends on the rules and organization that applies. Clear meanings and opened concepts, the diversity of applications guarantees a covering level, to produce a result consistent uniform and with agility
Directive - Grouping: of methods, rules, not defined with purpose target
Style VS Method- Differentiation
Method - Correspond to follow a set of definite rules.That it, determines the steps contained in stipulated stages, is to
determine the presence or elimination of steps
Style - Correspond way to execute a method.It bases on a conception of thought of as to get a result Therefore a style, it depends on the cognitive process (mind) and resources that
guy supports.(tools)
Model - Decurrent individual conception of the application of style and method.

Grouping methods, it forms a "directive" to evaluate: application, system architecture, the hardware, software.
To divide in categories: machines, industrial processes, manufacture processes... To divide in groups: machines: sequencing, synchronized, stages, ...
At last, to determine rules capable to mainly produce the contend of each stage of development and to define a "relationary structure", that it means which contend possesss dependence or level of linking
with another "directive".
Important when to create a directive(line of direction) to define which the base parameter. Type, parameter domain time or frequency, efficiency, execution, check is...

I.E:
Method of software
Method: Get Input
Primary verification - Rules enable/disabled

• Acquisition;(Moment certain to read)
• Validation;(Verification of the information)
• Interpretation: (To produce the result) Supply: (To deliver the result at the certain moment)

Secondary verification - Rules signific

• Instant that the information becomes available or clear. Analysis: Delay, noise, EMC,
• It determines the validity, level of truth of the information Analysis: Verification of Span, streak for present period of stage and coherence in the variation speed
• Codification - Association to other variables to produce new
  information, integration the software (interlocks, etc)
• Instant that the result must be delivers - Disponible the
  information permanent or determined instant.

Method of the hardware: Processing scans
Determination of the timeline (Balancing CPU): To determine:

• The dependence of signals,duraction signals
• Duration of the periods of stages
• Processing gaps, to define the critical instants.

It wanted to have seen topic, the much time. You unite, I looked for and I did not find. Because, subjects of interesting level are scarce?

Doug_Adam. Already perceived in its answers that it knows to define important aspects, that the difference of 3 years, it brings as add news?
(Translation word-by-word)

 

[RMA]

Another one for Ron's little book!

thanks, paul,

that's the type of information i'm always looking for - the exceptions to the "rules" - i'm learning as i go - never say "never" - never say "always" - never say "all" - never say .... well, you see what i mean.

again, thanks,
__________________

My wife treated me to the current version of Hans Berger's book on programming Step7 in STL & SCL as a present for our wedding anniversary (Awe, shucks!). Browsing through it over the weekend to see what was new, I tripped over the chapter on forcing (2.7.4 in my German copy) and there he makes the statement that while in the S7-400 writing to forced outputs has no effect, with the S7-300 the user program can overwrite the force value.

He then goes on to confuse the issue by saying:

"Forcing in an S7-300 corresponds to the cyclical update: after the Input process image has been updated the CPU overwrites the inputs with the force value; before the Output process image is output, the CPU overwrites the outputs with the force value."

I haven't had a chance to try it out yet, but the only way I can see to square those two statements is that if you directly access the peripheral address in your program using PAW10 (or should that be PQW10 in english?), for example, then this value would actually appear at the output until the process image was updated (and with it the force value) at the end of the OB1 cycle. This would mean that under some circumstances a forced output could actually change it's state for several (perhaps, tens of) ms, which might, under some circumstances, be long enough for it to cause some undesirable consequences!