Program Structure

[DDV]

Good day everyone, I would like some assistance with structuring a program. Generic views will be welcome, but if you have Siemens related advice to give it would be much appreciated.



What I would like to know for instance is:

Do I group all the valves for instance together in one FUNCTION, or do I create a FUNCTION/SUBROUTINE for each valve?



If the valve only works some time, do I place it in a Function/subroutine and only call the Function when needed or do I scan the valve code all the time?



Do I place my PID blocks in one Function/Subroutine and call it PID CONTROL or do I place the PID block in the valve FUNCTION that it’s controlling?



Basically what I want is your views on placement, structure and sub-structure (if any)



Please don’t feel bound by my examples, any helpful hints will do. And if you wish to use the word C_R_A_P in your response so be it……

[PeterW]

Originally Posted by DDV

Basically what I want is your views on placement, structure and sub-structure (if any)



Please don’t feel bound by my examples, any helpful hints will do. And if you wish to use the word C_R_A_P in your response so be it……

'Do I group all the valves for instance together in one FUNCTION, or do I create a FUNCTION/SUBROUTINE for each valve?'

I would normally look at how many different types of valve I have (N/O, N/C, single sensor, etc) then write a generic block for each type (the first being a template for the others).

I know some people like to put all such block calls together at the end, I prefer to segregate them into sections of the machine, preferably in order that logically matches the system.

'If the valve only works some time, do I place it in a Function/subroutine and only call the Function when needed or do I scan the valve code all the time?'

I'd scan it all the time, to ensure it doesn't move, also ensure full control at all times.

'Do I place my PID blocks in one Function/Subroutine and call it PID CONTROL or do I place the PID block in the valve FUNCTION that it’s controlling?'

The PID control would normally be called from timed interupts. If I had more than one, I would probably put them on different networks to make clear each is individual.


For structure I would generally follow the same pattern something like below:

1. Condition Inputs (digital/analog/)
2, HMI Inputs
3. Communications (in/out)
4. Alarm handling (some alarms would be generated in the device FB/FC's)
5. Sequence Control
6. HMI Outputs (some status would be generated in the device FB/FC's)
7. Output Conditioning (some outputs would be conditioned in the device FB/FC's)

Each of the above would be a call from OB1 and then each may subdivide into multiple FB/FC's. I would try to make it easy for a tech to track his way to a sub section of the plant/machine.

[DDV]

I would normally look at how many different types of valve I have (N/O, N/C, single sensor, etc) then write a generic block for each type (the first being a template for the others).



Do you create FC’s for these?



The PID control would normally be called from timed interupts. If I had more than one, I would probably put them on different networks to make clear each is individual.



I normally call them in my normal program structure, not via (I think OB35) a time interrupt, is this completely wrong or just not advisable? What are the benefits of calling them via a interrupt block?

• Condition Inputs (digital/analog/)
  2, HMI Inputs
  3. Communications (in/out)

What would you call communications? Fetch and put?

[Ken M]

Hi DDV

Without knowing your process or application (wow, there's a big exclusion clause straightaway!) my recommendation would be to do some serious structural analysis of the process and then fit the code around that. See this post I did in another thread on a similar topic http://www.plctalk.net/qanda/showpos...0&postcount=17

Very roughly speaking, I would suggest each unique valve type has its own FB with all the appropriate code for controlling that type of valve. All the valves of a type are then just multiple instances of that basic operating template. If you've got only one valve type in the process then lucky you!

I'm not clear about the issue of a valve only "working" some of the time. To my view a valve is working when it's closed and working when its open, and if it's not doing what I need (staying open, staying closed etc) I want to know about it. So I would always address the valve control code and alarm code to assert what I want and to check whether it's been achieved and maintained.

PID control generally involves several sub-elements: the analogue inputs; the actual control block and alarming; the output control and valve management etc. My feeling is to analyse this again like the physical parts of the process and what you want to happen. For example I would want the valve control to be maintained regardless of what happens to the PID. In that case I'd have the valve FB amd the loop FB separated and an FC acting as the interface between them to define the higher level logical interaction at a process unit level. That FC may contain references to two PID FBs, 5 valve FBs, a pump FB and a level alarm FC. Now if that cluster of devices is repeated several times in your process (say, 5 identical storage tanks) then make it an FB too, and have one instance per tank. And so on ...

The other thing to consider is defining the process in terms of the data flow through it. Then modelling in terms of data might reveal typical and repeating packets which can be defined as UDTs, specific to your process. The supporting code is then written to manipulate these UDTs rather than the physical devices which produce or consume that data.

You'll hear lots of opinions here - I think the problem will be selecting the wheat from the chaff. And I'm not promising what category this lot belongs to!

Regards

Ken

[PeterW]

Do you create FC’s for these?

I used to try to do most things in FC's (because I didn't like creating a DB for every call), I've changed my opinion a bit on this and either FC or FB will do. If I used FB's I would try to call them as instances from another FB and then only have to create a single IDB for a number of devices. (Then again there's loads of DB's if your using 400's.)

I normally call them in my normal program structure, not via (I think OB35) a time interrupt, is this completely wrong or just not advisable? What are the benefits of calling them via a interrupt block?

Calling from a timed interupt guarantees a regular interval for the PID control. I have used PID loops but not extensively, I feel others could explain better the pluses of calling from a timed interupt.

What would you call communications? Fetch and put?

I would call it interfaces to other devices, via ethernet, profibus, serial and whatever blocks are used.

[DDV]

Thank you Ken, this is not for a specific project, just “in general”.



Just for interest, how do you plan a project? Do you draw it out (pen and paper) or do you program on the fly?

[PeterW]

Originally Posted by DDV

Just for interest, how do you plan a project? Do you draw it out (pen and paper) or do you program on the fly?

program on the fly

[AMAZINGAHMED]

That's the way i work
1- First write down everything in plain english.
2- flowcharts... flowcharts... flowcharts...
3- write your code
4- return to number2 if necesssary

program on the fly

nice expression.
Note that the way above takes more time to get the final result. But it minimizes error in the program and results into a neat program (and debuggable).
NOTE: don't forget to write comments.

[PeterW]

Originally Posted by AMAZINGAHMED

But it minimizes error in the program and results into a neat program (and debuggable).

Not from my experience its not, anything but.

Programming on the fly would more often than not end up with a program totally devoid of structure, replace the word debuggable with nightmare and neat with sprawling.

[DDV]

NOTE: don't forget to write comments.



Do you use REM statement like these:



A I2.2 // Input from motorA

AN M21.2 //MotorA overload

= Q0.0 //MotorA run

[PeterW]

Originally Posted by DDV

NOTE: don't forget to write comments.



Do you use REM statement like these:



A I2.2 // Input from motorA

AN M21.2 //MotorA overload

= Q0.0 //MotorA run

Never, their a waste of space, the symbol should already tell you that, rather than a comment per instruction, I would comment a group of instructions and say what they are for.

example

 
Inc: L	 #s_COUNT					// Increment number of data stored in this DB memory
	 L	 1
	 +I	
	 T	 #s_COUNT
	 L	 DBW	0					// If reached MAX set-up (8000 words)
	 >I								// Then offset DB pointer to next DB
	 JC	Next
	 L	 #s_DW_ADD				 // Offset DW pointer to next DW
	 L	 P#2.0
	 +D	
	 T	 #s_DW_ADD				 // and END here
	 BEU

EDIT:

I should add that its good to make use of the TEMP and STAT areas in each block where ever possible and create UDT's for all devices, makes following code much better.

[AMAZINGAHMED]

Do you use REM statement like these:



A I2.2 // Input from motorA

AN M21.2 //MotorA overload

= Q0.0 //MotorA run

Sure not.
I just write above each network what it does

replace the word debuggable with nightmare and neat with sprawling.

If you have the flowcharts of your program i think it will be easier to debug (provided that you write your program resembling your flowchart)
I think progarmming on the fly is OK for tiny programs, but for a complicated bug one, you'll be lost. especially when you write your program and wait for sometime untill the factory will be ready to install your system, then you'll forget what you have written.

[DDV]

Originally Posted by PeterW

EDIT:

I should add that its good to make use of the TEMP and STAT areas in each block where ever possible and create UDT's for all devices, makes following code much better.

Good idea Peter, I try to where possible, but what is possible is very relative it seems, depending on experience.

[DDV]

Just a last question please: Do you believe it to be good practice to include pre created VAT tables with comments to assist in trouble shooting in the software you supply? If so what information do you provide in them?

[PeterW]

VAT tables with data split into related groups with a comment before the group is quite a good way to assist setting up, commissioning and then a diagnosis tool for tech's later.

A VAT table for each specific section of plant/machine/interface helps as well.