Sequential Programming Methods

[TL140]

James Mcquade,

I started out as a maintenance tech (still partially am one. Trying to advance my career into the controls department since PLCs are a passion for me), so I completely understand that. The question was more of personal preference such as the old example of timers and cascading motors vs the motors, a timer, and indirect addressing.

 

[jamesau]

I too like integer step indeces for a variety of reasons. They’re generally more readable and align better with design documentation whose audience extends beyond the bitheads and hexheads among us. Additionally, they’re great for trending on the HMI so people can readily profile a process and identify/quantify problems and process streamlining opportunities. A generic step timer which resets whenever the step changes always comes in handy too.

For more complex sequences, a substep index with its own timer is great for a couple of reasons. A substep works just like a step index but is reset to zero when the step index changes (think step/substep as chapter/verse). It allows on-stepentry assignments and generally results in fewer post-commissioning design document changes associated from renumbering steps. Invariably, sequences change from initial design during commissioning which can result in many small step additions (for example, the need to wait 2 seconds after opening that valve before starting a pump).

While we’re creating sequence steps, it’s worthwhile to create a message index (integer) that the HMI will associate a unique string to to let the operator know what’s happening. (For example, the operator can know what process condition the sequence is waiting on rather than call on somebody to dig into the live code to figure out what the holdup is).

So, paraphrased sequence pseudocode might look like (Below, <- is an assignment statement):
IF (Step = 5) THEN
IF (SubStep = 0) THEN
Perform Step5 Onentry Assignments
NextSubStep <- 1
ENDIF
Perform Step5 actions
IF (Step5 to Step6 Transition Condition is True) THEN NextStep <- 6 ENDIF
ENDIF

A separate sequencer section of code updates at the end:
IF (Step <> NextStep) THEN
CLEAR StepTimer
CLEAR SubStepTimer
NextSubStep <- 0
ENDIF
IF (SubStep <> NextSubStep) THEN CLEAR SubStepTimer ENDIF
Step <- NextStep
SubStep <- NextSubStep

 

[Paullys50]

TL140,
The MOST important factor is to get to know your customer's maintenance department and learn their capabilities. What they are used to seeing, their ability to learn new things.

I have changed my tune over a few years now, and have decided that it's not my responsibility to program for maintenance. Over the past five years the projects I have worked on were either greenfield (no maintenance team hired until near operational), maintenance had an electrician that could force IO on a PLC5, or maintenance didn't have someone who could understand the 'big picture' beyond just the PLC(Servers, RDP, SQL, SCADA...etc). Its the facilities responsibility to staff for their needs, not for me to dumb-it-down for their needs.

That being said, I do feel they are important, and will make sure to train them as well as I can during system turn-over. However, if they can't understand the philosophy of our standard (follows S-88 philosophy), that's not my problem. If they choose not to participate, that's not my problem. If they need 'ControlLogix 101', that's not my problem.

I also don't see the maintenance team the ones to 'debug' the software either. 85-90% of it should be sorted out before you commission, 95-98% should be sorted out by the end of commissioning, the remaining might be odd-ball issues that come up over the warranty period where I get a call about it.

If problems do come up, the HMI/SCADA displays should provide useful information to the problem, if maintenance always has to get online with the PLC to figure out the issue, then something is missing in the overall design of the control system.

I'm mostly talking about large systems here, 500-1000+ hours of PLC programming and efficiency is the key to making $$. Program for maintenance and you'll be over-budget and full of 'change-orders' to try and make up for it. Causes you more stress in the long-run. I've found that most people buy into our standard fairly quickly, those that don't are stuck in the I:0/5 days.

 

[shooter]

if you want it easy and simple, suggest using codesys, and if that is impossible use ladder.
i use three ladder programs 1 for the state, 1 for the program, and one for the transitions.
the state is an integer and goes up by 100. so i can put something in between.
the program has the same numbering as the state, meaning case state
100: program for step 100
etc
in transition i put in the next state number.

 

[chud]

+1 for SFC/Grafcet
It is in essence a flow chart. If maintenance cannot read a flow chart they shouldnt be in maintenance

 

[mk42]

If problems do come up, the HMI/SCADA displays should provide useful information to the problem, if maintenance always has to get online with the PLC to figure out the issue, then something is missing in the overall design of the control system.

I'm 100% with you on this. The HMI CAN be the best diagnostic tool for maintenance, if management is willing to pay for it. Unfortunately, in my experience, "diagnostics" gets considered to be an extra, even when everything is going wrong.

 

[Paullys50]

I'm 100% with you on this. The HMI CAN be the best diagnostic tool for maintenance, if management is willing to pay for it. Unfortunately, in my experience, "diagnostics" gets considered to be an extra, even when everything is going wrong.

Lets not confuse 'diagnostics' with good design practices.

1. If you are programming a sequence, display the sequence number/description so maintenance has a starting point. Heck, operators can even say "Hey it's always getting suck on step 12 'waiting for operator acknowledgement', what's wrong??"

I can't believe how many systems I run into that have a sequence but no display reference. So when it's 'stuck' somewhere in the sequence you have NO starting point.

2. Don't HIDE stuff on the display with visibility, if it's invisible who even knows it's there? Disable it instead which keeps it visible. Then at least you know something is there and figure out why.

3. Create alarms for conditions that could stop sequence logic from transitioning.

4. Create alarms with useful text. "Filling stopped due to M-104 fault", "Route 1 transfer stopped due to PT-201 high pressure", "CIP Stopped due to TT-105 low temperature"

Just last week I was trying to troubleshoot a system, buttons didn't work on the display, no alarms existed and there was sequence logic that was getting stuck on a step. But you had no idea what the system was doing from the display. Just some start/stop buttons and analog display points for pressure and position. Useless.

 

[DwSoFt]

I am not big on step programming, as I've only worked oil & Gas and water & wastewater thus far and they are not step oriented.

1 thing I did learn is with Goto/Label (Fisher ROC FST programming is label based, reminds me of my earlier basic programming days) is it does not speed up the code execution as each time you say goto it has to scan the entire code to find the label to go to. no big deal on little sites but a big manufacturing plant could cause issues. Also you need to be careful to not create a never ending loop. so for me a goto always goes to a label downwards from the command and never upwards.

Also I agree more thought needs to be put into the screen and that I love being on maintenance as opposed to projects. I'm Constantly Maki g little changes here and there to.improve the use ability for operations.

 

[mk42]

Lets not confuse 'diagnostics' with good design practices.

Maybe I'm not using the correct terminology, but most of what you listed above, I would consider diagnostics.

If someone walks up to a machine, and it isn't doing what he expects it to, he should be able to look at the HMI to diagnose what is wrong. Sometimes it is a hardware fault like a motor overcurrent, sometimes it is a process fault like a missing interlock. To me, both are equally important to have on the HMI.

In the world I come from, the expectation from customer management is that it is extraneous to have anything more complicated on the HMI then a red light indicating that there is a fault in the system, somewhere. What you call "good design practices" is considered an upsell, and a deviation from the RFQ. For the record, I think this is stupid, but that hardly ever stops either my customers or my management.

 

[ndzied1]

I have done step numbers for for simple stuff I prefer a ladder method.

This is a super simplification of my ladder sequences. Each one has something that starts it. The first step is usually started by the start button (real or HMI) and then each subsequent step is started by the previous step completing (STEP_XX_COMP). I hold them all up until the end when I use a Cycle Complete bit to clear them all.

Then all my output rungs have two main branches; an Auto branch and a Manual branch.

In the Auto branch there is a NO contact of the step the output comes on at and a NC contact when it goes off. If an output comes on multiple times in a sequence then there is another sub-branch around the first with a NO contact and NC contact as well.