Multiple subroutine calls

Jim Yeary

Member
Join Date
Dec 2002
Location
West Palm Beach, Fla.
Posts
9
I have a practice program I'm writing. In it I have a error recovery subroutine. This subroutine is called from four different lines of code. Each line has different inputs to make the line true and call the subroutine. Problem is it seems like only the first line that calls it when true works. The other lines come true at different times but do not call the subroutine. I know this because I put a cylinder movement inside it to know when the subroutine has been called. Am I missing something or is it a no-no to call the same subroutine from different lines?

Jim
 
How is the order of your call to subroutines and the actual subroutine arranged? Most PLCs require that the subroutine be placed at the bottom of the program. Any ladder after that which is not bounded by subroutine elements is ignored.
 
Generally, it is permissible to call a subroutine
more than once.

As a troubleshooting tool you can use right away,
consider this:

If the s/r is called by I/1, I/2, I/3 and I/4,
put four additional rungs in the s/r, such as:
I/1 B/0
] [----(L)-

I/1 B/1
] [----(L)-

etc.

then, you'll be able to see, inside the subroutine,
which call was/is active.
Of course, by using Latches, you'll have to manage
the unlatching manually.
 
The subroutine is out side the body of the program, after the end statement. I have two cylinders that I make sure ext and ret. Using a timer and the status of the ext/ret sensors I call the subroutine if the cylinder fails to fully ext or ret.
 
Isn't that the original point of subroutines? To call them more than once? I think that you need to post more info- Brand PLC, programming software, etc. If you can post the program, even better.
 
It depends upon the PLC, I have programs that use sub-routines over and over again, simple functions like scaling analog values, checking the status of valves, comparitors etc...

Its better to create standard function calls and use them over and over again, rather than creating a long program with the same logic repeated multiple times.
 
Jim, your description is self-contradicting.

Your first post:
I have a practice program I'm writing. In it I have a error recovery subroutine. This subroutine is called from four different lines of code. Each line has different inputs to make the line true and call the subroutine. Problem is it seems like only the first line that calls it when true works. The other lines come true at different times but do not call the subroutine. I know this because I put a cylinder movement inside it to know when the subroutine has been called. Am I missing something or is it a no-no to call the same subroutine from different lines?

Your second post:
The subroutine is out side the body of the program, after the end statement. I have two cylinders that I make sure ext and ret. Using a timer and the status of the ext/ret sensors I call the subroutine if the cylinder fails to fully ext or ret.

In the first post, the cylinder movement is produced by the sub-routine when the sub-routine is called.

In the second post, a failed cylinder movement causes the sub-routine to be called!


Clarification would help.

Now, regardless of the clarification issue, I suggest that you go through a methodical verification process.

I suggest that you disable the "calls" and then re-enable them one at a time, just to verify that each "call" works.

You can disable the "call" by inserting an "Always OFF bit" in the rung.

Disable the first three calls.
Set the Input(s) to cause the call in the fourth line to execute.
See if the fourth call works.

Enable the third call and disable the fourth call.
Set the Input(s) to cause the call in the third line to execute.
See if the third call works.

Enable the second call and disable the third call.
Set the Input(s) to cause the call in the second line to execute.
See if the second call works.

Enable the first call and disable the second call.
Set the Input(s) to cause the call in the first line to execute.
See if the first call works.

If any call does not work, then you have a problem with your Inputs.
If all calls do work, then re-enable all of the calls.

Do as jdbrandt suggested and put a "trap" in your Sub-Routine code to indicate which rung actually called for the sub-routine.


Rung-1:
. S/R
In-1 In-2 In-3 Done
--| |----|/|----|/|----|/|----( Call Sub )
.
.
Rung-2:
.
. S/R
In-1 In-2 In-3 Done
--| |----|/|----| |----|/|----( Call Sub )
.
.
SUB-ROUTINE:
.
In-1 In-2 Out-1*
--| |----|/|-------( L )
.
In-1 In-2 Out-2*
--| |----| |-------( L )


.
*latching an Output will give you a visual indication on the PLC as to which rung made the call.

...then the rest of the Sub-Routine...

The last line in the Sub-Routine should disable further calls to the Sub-Routine.
.
-------------------( L ) S/R Done
.
.
In the main ladder, before all of the "call" rungs, use Input-1 to Unlatch the Outputs and S/R Done.


In-1
--|/|-----------+---( U ) Out-1
+---( U ) Out-2
+---( U ) Out-3
+---( U ) Out-4
+---( U ) S/R Done


.
.
Input-1 ON is used to initiate the examinations of Input-2, Input-3 and S/R Done.
Input-1 OFF is used to UNLATCH your Output indicators and S/R Done.

Run your program.

Ensure that Input-1 is OFF.

Set Input-2 and Input-3 to specify the rung you wish to test (00=1, 01=2, 11=3, 10=4).

Then, turn ON Input-1.

You should get an Output indicator that matches the "calling" rung.

Turn OFF Input-1 to disable all of the rungs, and Unlatch the Outputs and S/R Done.

Specify another rung and turn Input-1 ON.

Repeat to your heart's delight!

If this does not produce the expected results, then I suspect that you have a conflict in your "input-specifiers". That is, if your inputs do not specify UNIQUE conditions, then you are bound to have the problem you indicated.
 

Similar Topics

Hi fellas, I've just learned of an upcoming project that I'm going to be asked to do the programming on. Details are very sketchy at this point...
Replies
19
Views
6,092
Compactlogix controller, program has 28 conveyors that use TON's to start the conveyors. The TT sounds a warning horn during start and the DN...
Replies
6
Views
95
I have 9 field devices, three METSEPM5110 power meters and six ACE949-2 rs285 interface modules. I want to read this Modbus rtu data through rs485...
Replies
8
Views
269
I'm trying to use DTM browser to make make modbus poll from RTAC. I'm able to get the points in first poll object. But not able to get anything in...
Replies
1
Views
100
Hello, I encountered a problem with the kinetix 6500 drive, error code s22, loss of 3 phase voltage. After disassembling and replacing the thermal...
Replies
2
Views
130
Back
Top Bottom