Program Structure

[TimothyMoulder]

These are all good answers, but I think the question is pretty high level.

I just put out a post on a Unitronics experiment I ran :

http://www.plctalk.net/qanda/showthread.php?t=24898

In the past, I've always divided up my processes into discrete steps and written not subroutines, per se, but functions. "Loader Forward, Indexer Rotate, Unloader Down", etc.

This file is part of an examination I'm doing into a different sort of structure. Instead of "Loader Forward" as a separate routine, I would make the loader motion a part of the larger cycle, and call a generic routine such as this to execute it.

Like Terry, I'm not quite sure what to call this sort of arrangement, and I'm better at visualizing it than explaining it, I imagine. But what I'm hoping to get out of it is a collection of canned routines I can reuse over and over, without the need to incorporate them into a defined "station" routine. Think "macro". I think it will really speed my programming up.

I recommend first to ignore one oft-trumpeted piece of advice given out here - "Be consistent." Hooey. First, decide on a path you think will be easy and comfortable for you to work with, and do it. As problems, inefficiencies and issues appear, adapt and grow.

Choose a path stick to it until you finish the job, then re-evaluate and evolve. The next job will offer new challenges that will make you adapt what you have done, or strike out in a new direction entirely. And don't be afraid to play - in our line of work, we call that "research".

TM

 

[DDV]

Thanks TM, I had a look at the software on your link, but it will take me a while to see what’s happening there, I’m more of a STL person.



What I was hoping for, but knew I won’t easily get, was sort off a guideline to structuring,, my code works, but the end result sometimes looks a bit messy (or c_r_a_p depending whom you ask)



I only recently started creating my own FB’s and using indirect addressing, but I still find it a bit problematic at times. I have been lucky so far in the sense that my projects have been very straight forward and I could do most of the code like you would wire a rely logic panel…only its in STL.



But as you say there doesn’t seem to be a basic structure, it all depends on the application.

 

[PeterW]

I recommend first to ignore one oft-trumpeted piece of advice given out here - "Be consistent." Hooey. First, decide on a path you think will be easy and comfortable for you to work with, and do it. As problems, inefficiencies and issues appear, adapt and grow.

Choose a path stick to it until you finish the job, then re-evaluate and evolve. The next job will offer new challenges that will make you adapt what you have done, or strike out in a new direction entirely. And don't be afraid to play - in our line of work, we call that "research".

TM

I believe your second paragraph above actually states what is meant about being consistant. No-one I'm sure would advocate be consistant over every project as the first, we'd still have panels full of relays, but be consistant in the current project.

 

[Gambrinus]

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.

I usually do similar. But I make devices alarm handling in FB or FC intended for particular device type. "Device drivers" FB/FC calls are placed in process sections FB/FCs where interlocking and sequences are realized. Global alarms and control signals are processed in special FC. Sometimes I use special FC for settings. It's useful because you can easy find and change it if required.

 

[TimothyMoulder]

I believe your second paragraph above actually states what is meant about being consistant. No-one I'm sure would advocate be consistant over every project as the first, we'd still have panels full of relays, but be consistant in the current project.

The sense in which I've always taken it - and I could be wrong - is that anyone who has to work on your machines should see a common methodology among them, so consistency is required not to throw off the guy who comes next.

Now, anyone analyzing my first project and my latest would see enough differences, they'd probably think there were two different people involved. But if they followed along from the first TO the latest, they'd see the gradual evolution that has led to the point I'm at today - and I'm still at it.

Down with convention! Up with evolution!


TM

 

[Ken M]

PeterW

I can sense another schism in the Celtic fringe about to appear!

Your comment about comments being a "waste of space" (hmmm... what else did you say that about recently, let me think.... ) and the list of 7 items that Gambrinus already quoted above. I'm sorry but I have to disagree with both of these. (Hey, you knew I would!)

I would seriously recommend considering writing the comments before the code. To my mind that's just a natural extension of AmazingAhmed's iterative design and flowcharting. Write really high-level comments first: describe what an FB will do before you've written it. Then do the same for the next one. And so on. Now read through your own comments. Look for the flaws - they will be there. Write the corrections to your comments. Keep going. Eventually you will reach the next level down, perhaps network by network. Do the same exercise. Stop only when you get to a trivial or obvious point. And remember the poor guy who's going to be fault-finding this at 3:00am in 15 years time. Will he know what's going on? Finally the code will emerge naturally and correctly from these comments. And now I have to agree that's a plausible theory but who has time to do that? Well it depends. How big's the job, what's the spec, and what are the consequences of getting it wrong?

Secondly, your List Of 7 is not structure as I understand the expression "structured code" to be. This seems more like a sequence of processing. I know that the scanning nature of traditional PLC CPUs tends to make people think along these lines, but you could still write badly structured or non-structured code while observing your list. Many CPUs permit interrupt driven processing. Imagine you had to write all your code as interrupts, and nothing in OB1 at all (since DDV asked about Siemens at the outset). How would you enforce your list under these circumstances? And yet it should still be possible to write structured code regardless of whether it is sequentially scanned or interrupt driven.

Back over the net to you ...

Ken

 

[PeterW]

right, here goes..

'comments being a "waste of space" ', not quite what I said, comments which are made up of just describing what the bit is, is a waste of space.

i.e.

A I2.2 // Input from motorA
AN M21.2 //MotorA overload
= Q0.0 //MotorA run

If properly done then each I/Q/M shpould have a symbol and then could then look like this:

A -motorA // Input from motorA
AN -motorA_O/L //MotorA overload
= -Run_Motor //MotorA run

These comments don't convey any additional information. where as:

A -motorA // If the overload is OK when required to Run
AN -motorA_O/L
= -Run_Motor //Then start the drive

The more complicated the code is the more useful a functional comment is, where it describes what it is doing rather than just stating what the individual bits within that piece of code are.

'Secondly, your List Of 7 is not structure as I understand', probably agree with you there, this is a starting point, each of the 7 would then be sub divided down further, for instance:

5. Sequence Control

5.1 Infeed Section
5.2 Cap Feeder
5.3 etc etc

each sub section would be an individual FB/FC and maybe within them sub divided again, making it easier for the tech's to find the area of code he's looking for.

The bit about writing the code in comments, yes I would normally write and work to a FDS and SDS.

The FDS (Functional Design Document) would be a nice wordy document which describes simply what the sequence of events on the machine/plant will do and this would be as non-technical as possible.

The SDS (Software Design Specification) is where the structure would come from, describing how the blocks are made up and how they would be distributed. Your UDT structures would be described here plus interfacing formats etc etc.

Of course for smaller projects the full FDS/SDS may be unecessary but some sort of pre-planned agreed structure should be thought out and designed (before coding, although playing with code before hand to get an idea of what you will need is not a bad thing to do before final design)

 

[DDV]

Thank you everyone, this is most helpful.



If I have a couple of valves, single acting (air on=valve open, air off=valve closed), also called spring return or failsafe. Let’s say it’s in a CIP system. And I wish to create a FB for it. I would write code that, checks if there is a open command, then times before checking the open limit, if I lose the open command I would time out again before checking the closed limit (to allow for valve travel). If I do not get a specific limit within the correct time, I would make a alarm bit.



Do you have any other conditions I should code in on the “template” that would be considered common to these valves? Thing you have found to be useful or even considered mandatory?



I know the technical procedure to create a FB and IDB, it is the actual content (code) that I am interested in.

 

[PeterW]

Once the valve has reached its limit (fully open or closed) then losing that limit signal would constitute an immediate alarm.

This would especially be of concern in something like CIP systems. In Heinz we had multi route valves that could be passing real product in one route whilst CIP'ing another (in the same valve). Any movement in the valve could contaminate the product and would thus cause an emergency shutdown.

 

[DDV]

Very good idea, I am in a fortunate position (for now) that I can effect almost any changes I wish, and have already started networking all my PLC’s (about 20) via Ethernet onto a central server. Very nice, but also comes with a lot of responsibility, so I have to do my best, very glad I found this site.



I have done several Siemens courses, but they only show you the technical program stuff, it’s the concepts (if you understand what I mean) that I struggle with sometimes.



But thanks for all your help.

 

[krk]

Do you have any other conditions I should code in on the “template” that would be considered common to these valves? Thing you have found to be useful or even considered mandatory?

For this type of valve, both positional limits on at the same time should be considered a fault condition.

 

[TimothyMoulder]

I would write code that, checks if there is a open command, then times before checking the open limit, if I lose the open command I would time out again before checking the closed limit (to allow for valve travel).

A slight variation on this might serve you better, if cycle time is a consideration.

The code you describe is completely time-dependent. You allow, say, 2 seconds for the valve to open or close, then check the limit switch to see if it has. This means, regardless of how quickly the valve in fact opens or closes, you will wait two seconds before proceeding to the next step.

Coonsider - you may have gotten what you wanted from the valve in 200 milliseconds, but with this arrangement, you will wait 10 times that long before continuing your sequence of operations, regardless of success.

A better approach is to monitor the input for the condition you want, while simultaneously running your two second timer. If the valve reaches the target position before the timer expires, set "done" and go the the next step immediately (reset your timer on the way out). If the timer expires, then the move failed, regardless of which input you were looking for.

TM

 

[DDV]

Yep, that is a much better way, Thanks TM I will code it that way. Is it ok for me to post my code (valve FB) when I’m done? Then I can get some feedback, luckily I have a thick skin and a sense of humor….. I think I’m going to need it.

 

[S7Guy]

The more complicated the code is the more useful a functional comment is, where it describes what it is doing rather than just stating what the individual bits within that piece of code are.

I like to add comments liberably as well, but not within the comment header of the network or on the same line of the logic. Most of the time I'll add them on their own line in the middle of the network, i.e.:

[size=3][color=#0000ff][font=Times New Roman][b]//***************************[/b][/font][/color][/size]
[size=3][color=#0000ff][font=Times New Roman][b]// If the overload is OK when required to Run.....[/b]
[b][size=3][color=#0000ff][font=Times New Roman][b]// Note: Overload is in electrical cabinet 7...[/b]
[b]// Blah, blah, blah.....[/b][/font][/color][/size]
[size=3][color=#0000ff][font=Times New Roman][b]//***************************[/b][/font][/color][/size]
[/b][/font][/color][/size][size=3][color=#0000ff][font=Times New Roman][b]A -motorA[/b][/font][/color][/size]
[size=3][color=#0000ff][font=Times New Roman][b]AN -motorA_O/L [/b]
[b]= -Run_Motor[/b][/font][/color][/size]

You can add as many comments as you want this way, and it has no effect on the ladder display. So people who are more comfortable in ladder can look at the graphical logic, but can still toggle to STL for a more detailed explanation.

And, if you generate a source file, you can do a search on your comments, which is kind of handy when doing a lot of indirect addressing in non-symbolic mode where the variables don't show up in the cross reference list.

 

[PeterW]

Yep, that is a much better way, Thanks TM I will code it that way. Is it ok for me to post my code (valve FB) when I’m done? Then I can get some feedback, luckily I have a thick skin and a sense of humor….. I think I’m going to need it.

Just to screw the code you've already started up a bit more, lets talk HMI's. If you have a HMI/graphic system, in addition to the code within the block to generate the alarm, you may want to put in the code the handle the status for the HMI (colours etc).