Programming Style

[hein123]

Hi

I have a question about programming style. What I know is it is better to have a few sub routines grouping the functions together, like controlling valves in one moving motor in another so it is easier to debug.

However my question is what is a good programming style to control the sequence of events that occur?
What I currently do is do everything sequencily in steps, like step 1 is move Valve A, if valve A is forward go to step 2, then step 2 is to move Valve B, etc.

This works great for troubleshooting and messages to WinCC as you know exactly in what step it is in and what has to happen next.
But the problem is if the sequence is broken, then the entire sequence has to be resetted, parts have to be taken out if they are in inappropriate places, etc.

So what I would like to find out is is this the best structure of doing things as I can't find any standard?

Any advice would be appreciated

 

[LestatZA]

Hi Hein

Before I answer to your question, I also lived in Uitenhage many years ago.
Nice to see someone from my old home town on the forum.

As for your question.
I have FB's that control the data exchange to my drive etc. and everything that has data exchange(Read Write) via Profibus, profinet, Serial. etc. for example.
Then I break up my machines in its stations.
Each station will have a manual FB and an auto FB, the respective FB is only active when the respective function is required.
In the manual FB I drive the markers(m100.0 example) to do the manual functionality.
These I use in a FC to actualy drive the outputs. Each station in the machine will have a FC with its respective outputs.
In the auto FB I do the cycle for each station that drives the outputs in the FC for that station. Then with one bit(release) I will start the next station or stations as required in the autocycle.
Then I have a FB that does my error handeling and alarming.

Everybody has their own style of building a program dependant on the type of machines they build.
Good Luck

 

[rdrast]

Do what makes sense.
Almost everything I do now is a continuous process, not sequential, but each process has anywhere from 5 to 30 'zones'.

I start basically by breaking things down into a group of routines for each 'zone', which is often, but not always, related to variable speed drives on the machine sections.

Each section is broken down into at least two or three parts as well, usually "Sequencing or Digital Control", and "Analog Control". Some sections might have another sub-section for ancillary functions (load/unload, etc).

On top of all that, I toss in a ramp generator somewhere, some individual drive status, line interlocking, line sequencing, and line analog. That is the basic skeleton.

 

[TConnolly]

I try to break the program down into smaller and smaller pieces until I have something that can be programmed in a few rungs. As a general rule of thumb, if I can't code a function in 20 rungs or less I haven't broken it down enough. Now I want to stress that this is a general rule of thumb, not a hard fast rule - there are times when its logical to keep certain parts of the program together and a subroutine might end up being 50 rungs. But that is pretty rare. When that happens I take a second look and see if I can break it down more. I allocate subroutines either by machinery area or by process function, or by both - and that varies by project. Go with what seems most logical to you and stop occasionally and ask yourself "will this be logical to me 7 or 8 years when I come back to this program and try to remember what I was doing, or will this be logical to another programmer?" The most important thing is to write for readability. And document everything.

 

[dogleg43]

Read up on what is called "5-rung logic". There are some messages on this site that describe it pretty good.

It may not eliminate the need to remove or manually relocate you parts when there is a fault but the programming style works well.

Just remember that it very difficult to overcome mechanical problems w/fancy programming.

 

[Paullys50]

My thoughts, at the very high level, you always have two functions:

1. Process Functions
2. Device Functions

For Process Functions I have recently been introduced to a SFC (Sequential Function Chart) program design philosophy and I have to say I am very "turned-on" by the idea.

To me it makes sense, completely breaks down the process. It does everything in steps, so if you hang on one you know exactly where to look for the problem. Of course a well written program shouldn't just "hang", but if there is a hardware failure in the system it is pretty easy to spot. If you have the SFC properly documented you should not need a "Controls Engineer" to solve the problem or tell you how process works. Anyone with the reference document should be able to understand what "should" be happening in the system during any given step. Ideally for each "process" you would have a separate SFC writting and each SFC would be a unique program within your PLC, each program then has similar/standard subroutines to execute the process. Read up on AB's "Phase Manager" and S88.

Everything is a sequence at some point. Even a continuous process is. Start - Running - Stop, it's a sequence. Granted, the "running" step could continue for 24/7/365 but it still can be considered a "step" in the overall process.

As for Device Functions, I classify this a logic needed to control a device regardless of the process. Pumps/Motors/Valves/Level/Temp are ubiquitous across many automated systems. The logic that controls/monitors these devices can be standardized, thus minimizing your overall programming time. Universal data-types can be created, universal sub-routines can be created to give you all the functionality you need while removing the tediousness of programming logic for device control.

 

[daba]

Agree with Paully's5.0

RA training teaches you to "separate the equipment from the procedure"

In other words, the "procedure" or "process sequence", will want to open a valve, or start a motor, for example. It will not need to know how to do it, but it will command equipment control logic to do it. The equipment control logic will tell the procedure when the valve is opened, or the motor is running.

In that way, if you need to change the type of valve, or motor, then the procedure doesn't have to change, only the equipment control logic.

 

[JesperMP]

This is the problem hein123 is talking about:

But the problem is if the sequence is broken, then the entire sequence has to be resetted, parts have to be taken out if they are in inappropriate places, etc.

All machines where there is the risk of parts getting stuck, having to be manually emptied, refilled, adjusted halfways etc. should have a way to continue the sequence if necessary.
There could even be a "go back" step where the machine moves back to the previous position so that the operator can get access to the area.

The point is simply, it must be programmed into the state machine. It is not an abnormal situation as far as the PLC program is concerned. The original programmer must take every single possible transition into account. Not just the typical sequence when everything goes OK.

edit: To put it in other words. A state machine / sequencer that only have one serial thread of steps is just too primitive.

 

[hein123]

Thanks for all the input, I really appreciate it. What I gathered is that my basic idea is right and their is no problem using a state machine.

edit: To put it in other words. A state machine / sequencer that only have one serial thread of steps is just too primitive.

To do this step would be a lot of extra programming + a lot of extra interlocks. What the current procedure is, is it state on the HMI is that you manually have to move a specific valve, etc into position for the machine to proceed.

 

[JesperMP]

To do this step would be a lot of extra programming + a lot of extra interlocks.

Thats the difference between a program that merely works, and a program that works well.

The programming itself is not so much effort, it is the design of the state diagram where all the ingenuity happens. Best done with pen and paper. As soon as you have the state diagram figured out, the programming takes basically the same time as the more primitive version.

 

[bara_hence]

How do you guys handle this example?

(Very primitive example)

For example a simple sequence for pumping liquid:

Step 0 When fill request transition to Step 1
Step 1 Open valve when open transition to Step 2
Step 2 Start Pump when full sensor transition to Step 3
Step 3 Stop pump when stopped transition to Step 4
Step 4 Close valve when closed transition to Step 0

What if the valve fails in step 2 or 3?

Two ways to solve it

1. Interlock the pump and stay in actual step
2. Transition to another step for example step 1. (Pump stopped in this step)

I think the method of transitioning is the correct method becausse then all the control is handled by the state machine and the task of designing the machine is easier the statediagram holds the complete design.

Some links on some papers on state machines:

http://www.stateworks.com/technology/TN12-StateWORKS-specifying-control/
http://www.stateworks.com/technology/TN11-Going-Beyond-Limitations-Of-IEC-61131/

What do you others think?

 

[AJZ]

To do this step would be a lot of extra programming + a lot of extra interlocks.

The way I program sequencers, it is one extra rung per sequence step. In manual mode (more a single step mode), I allow the sequence under a fault condition to step in the opposite direction then the last step. It does require two additonal bits to remember the direction of the last sequence step. Sometimes I step back a couple steps at once i.e. from step 5 to step 2.

 

[Jeff23spl]

I try to break the program down into smaller and smaller pieces until I have something that can be programmed in a few rungs. As a general rule of thumb, if I can't code a function in 20 rungs or less I haven't broken it down enough.....

Stop occasionally and ask yourself "will this be logical to me 7 or 8 years when I come back to this program and try to remember what I was doing, or will this be logical to another programmer?" The most important thing is to write for readability. And document everything.

Well this is the way it should be! When this rules aren't followed it's a nightmare.

I sometimes see programs where i believe the guy has done it to make sure it will be the oly one to understand it... but must of the times he forget ...

Make it simple, logical, and most documented as possible is the key

I use the grafcet logic (sequence box) for sequencing but i avoid using it when it's too simple and create problems

When a grafcets has too much box, i try to break it in individual generic task instead of making one with 50 steps doing 10 times the same thing with 10 different equipements...

For exemple if you have 8 redondant pump to handle a process, where more than one can run toghether dont make a grafcet with each pump # options, (64+steps) This give many chances to make copy errors and a hard time to test every options...
Make 1 to decide how manny and another one to select which one to start etc.... (You should be fine with less than 10 steps...)

 

[Jeff23spl]

The point is simply, it must be programmed into the state machine. It is not an abnormal situation as far as the PLC program is concerned. The original programmer must take every single possible transition into account. Not just the typical sequence when everything goes OK.
edit: To put it in other words. A state machine / sequencer that only have one serial thread of steps is just too primitive.

Right, when testing a program, you must try to mixt it up with any anormal condition and make sure it doesn't stuck or get 2 step on at the same time when it shouldn't...
I remember long time ago when a teacher was passing on the lab making impossible condition and tell us to solve the issue!!!
I was mad about him but i know today he was a good one because this make the difference from someone do program and a good programer...

 

[Paullys50]

Fault handling is always unique to the process you are controlling. In the sequence you defined, it may be "ok" to keep running in step 2 and just notify the operator that there is a problem. The process sits in step two until human intervention.

It may be not ok, and you need to put the system into an "safe-state", depending on the process once the problem is corrected it may be permissible to "restart" and jump back into the step previously in error and continue. Other processes you may have to jump back into the process a a few steps prior if there are setup parameters that have to be re-initialized.

Or you may have to completely abort and start the sequence from step 0. All depends on the process.

Ideally you'll want to assume ideal conditions when programming your sequence, validate that it works. Then build the fault logic. Determine what fault conditions could exist and and create proper actions to those fault conditions.