Turning Subroutines On and Off

The following is the way I call a bunch of routines from the top level routine.
It works fine, however I discovered that I can not restart the subroutine, since
the done bit turned off the JSR call so the done bit in the subroutine is still on
(It is not being scanned anymore). I want to avoid using latches and unlatches, i.e.,
I could latch the done bit in the subroutine and unlatch it at the top level. I
also tried shifting a 1 into an array with BSL, then if it is set start goes off.
I could also move a 1 to a tag (for done), then clear it at the top level routine.

Does anyone know of a method that will cause (start) to be false when done is true,
without having to latch and unlatch the done bit?


---[hmi on]----|--------[not done]-----------(start)
|
---[start ]----|




---[Start]-------------------------[JSR routine Home]





Sub: Routine Home

close valve
turn off motor

-----[all OK]-----------------------------(done) ->not latched

RET

Ideas that may assist

1) cause the JSR to be called one extra scan after done
eg

---[start] -------------------------------(lastScan)

---[hmi on]----|--------[not done]-----------(start)

               |

---[start ]----|





---[Start]------|-------------------[JSR routine Home]

                |

---[lastScan]---|

The JSR must condition the (done) with [start] -- note start is really home running

2) use the HMI to Set the Bit that calls the JSR
Use the JSR to RST the bit when [all ok]

3) Change the code so hmi Start has precedence

---[hmi on]-----------------|-------------------(start)

                            |

---[start ]----[not done]---|

This relies on the JSR also resetting its done bit internally by knowing that the HMI has performed a request

It works fine

Click to expand...

well, whatever arrangement you finally come up with – please make SURE that it works safely/correctly AFTER A POWER CYCLE ... programming code like this is notorious for giving rude/dangerous/damaging surprises whenever the processor gets shut down – and then is later restarted ...

TIP: you don't always have to actually turn the power off to test – but at least test the program by going from Run Mode - to Program Mode – and then back to Run Mode again ...

basic idea:

many programs will work fine during normal day-to-day operation (often for years) – but when the processor is shut down somewhere in the middle of a production cycle – bad things can unexpectedly occur when the system is fired back up again ... the type of "turning subroutines on and off" arrangement that you seem to be using is particularly prone to giving these types of unwelcome surprises ...

going further:

IF (big IF) you're using 120VAC power for your input circuits (as opposed to DC power) it might indeed be necessary to turn the main power supply off – and then back on again – in order to give a fully conclusive test – especially if any of your inputs are wired Normally Closed ...

the reason is that many (most?) types of PLC processors keep merrily running along (and still SCANNING) for a second or two even after their line power supply is turned off ... (research the PLC's power supply "hold up time" if you're interested in this topic) ...

the point is that the PLC may incorrectly "think" that a Normally Closed input has been "opened/actuated" – due to the sudden loss of the AC power supply ... there's no current flow when the AC voltage to the input nosedives – but the processor keeps right on scanning for an extra hundred cycles or so ... a simple example: the processor might think that the operator has pressed a "stop" button – when in fact the button actually stayed "closed" ...

this effect can cause all sorts of troubles (we're talking potential lawyer-level stuff here) with ANY type of program – but programming techniques which rely on turning subroutines off-and-on seem to be especially prone to this type of problem ...

suggestions:

just in case you have more questions – please tell us what type of PLC system you're using ... it can make a big difference ...

if you're using an Allen-Bradley PLC-5, or a ControlLogix, or a CompactLogix system – you might want to look into the Sequential Function Chart approach ... (the SLC and MicroLogix platforms don't support this feature) ... based on what you've posted so far, it sounds like an SFC is the effect that you're trying to achieve ...

on the other hand ...

if you're using an Automation Direct system – then you should take a look at the Stage Programming approach ... that's actually the easiest (and most reliable) way to accomplish what it SEEMS like you're trying to do ...

final thoughts ...

the idea of turning subroutines on-and-off is not necessarily a "bad" idea – but when that approach is used for the purpose of "sequencing" the steps of a machine's operation, then serious problems can unexpectedly result ... particularly whenever the machine is called upon to "start up" from an unknown point in its production cycle ...

just be careful – and FULLY TEST your program's operation through every potential "start up" scenario ... ESPECIALLY if there is any sort of danger involved in your process ...

and it would be a good idea to post your program file – if you'd like for the forum to take a look at it for you ...

good luck with your project ...

ron beaufort said:

just be careful – and fully test your program's operation through every potential "start up" scenario ... Especially if there is any sort of danger involved in your process ...

Click to expand...

+1

+1 also on Ron's comments. IMHO, conditioning JSR calls is bad form and whenever I see it it, its usually along with lots of one-shots and latch-unlatch instructions. And was written by a non-PLC programmer.

please forgive me, I Am sorry, please tell me I Am a PLC programmer.

Is that just the way you've programmed the systems you've worked on or do you need extremely low scan times in your process?

Maybe you have multiphase operations where some routines are completely replaced with other routines that need to have control over the same I/O as others?

I have many routines that are JSR'd to from the main routine (as I'm sure that others on the forum have) and NONE are conditional. You just control the logic and be done with it. Of course I have also been around long enough to have had the pleasure of working with PLC's that had only one routine and all logic was written there and controlled by the logic.

I am not sure what you mean by conditional...There are several subroutines, some are dependent on the completion of a previous one. In addition, There are many interlocks that could prevent most subroutines from being called. For example, if one of the temperatures is > than the max, I can not call a particular routine. There are also some
subroutines that run until certain conditions are met, then they do not run again. There are others that run all the time, most of these are montitors. I appreciate you input, it makes re examine what I am doing.
Tom Kazakoff

Conditional is what you showed in your original post:

---------[Start]-----------[JSR Routine home]--


This is unconditional:

---------------------------[JSR Cell-1 Program]--

---------------------------[JSR Cell-2 Program]--

That could work ok. I would have to move certain conditions to the subroutines...
For example,
The first sub call moves several valves to predetermined postions (some open, some closed, etc). When the dissoved oxygen and temperatures are correct, those same valves need to move to different postions, and there are pumps that are turned on. This is done is a second sub. To prevent the valves from going back to the original state, I would need to prevent the first unconditional sub call from executing again.

When the dissoved oxygen and temperatures are correct, those same valves need to move to different postions, and there are pumps that are turned on. This is done is a second sub.

Click to expand...

Usually if you need to change the valves (or any other digital output) in two different places, it is smart to combine those 2 places into one subroutine, so that you only need one set of digital Outputs that are not controlled by Set/Reset or Latch/Unlatch. Having only one control point for each digital output is a winner.

you look like that you are trying to create a sequence

Step 1 - Open Valve1 & Close Valve2 & Stop Motor 1
Step 2 - wait for O2 and temperature
Step 3 - Keep Valve 1 Open and Run Motor 1


This allows you to program using

[Step 1] ---- |-----(Valve1 Open)

[Step 2] ---- |

[Step 3] ---- | 



[Step 3] ---------(Motor 1 Run)

and you can see which step you are in and what outputs are supposed to be on