subroutines in PLCs

I have a basic doubt in using subroutines in ladder logic. say i call a subroutine from the main logic. Assume that in the subroutine, i am starting a timer for 2 secs using an input that stays CLOSED always, and when the timer is timing I keep an LED on.

my question is: do i assume that the subroutine will be executed continuously till the timer starts and gets done,
or
the subroutine will bet executed for one program cycleand so the timer will not get fully executed.

i do not have a clear idea about the subroutine handling and the book i read explained it, and i got more confused. my opinion is the subroutine should get scanned only once and control must be transferred to the main program.
but when i implemented this using practically (AB micrologix 1200), the timer was ON for 2 seconds which meant that the subroutine was continuously executed until the timer timed OFF.

taknevs

It all depends on whether you are using a conditional call to your subroutine.

If your subroutine executes every scan, then it will act as if it is part of the main program, however, if it is only executed as a condition of something else, then your timer will NOT continue to time whilst the subroutine rung is false.

As said above, unless you use a conditional instruction in the logic prior to the JSR (subroutine) call, the Subroutine is scanned every time the ladder that calls it is scanned.

If you are using non-conditional subroutines, in an AB PLC, you can just envision them as in-line code to the main ladder, and mostly as organizational units.

There are times you might conditionally process them, such as calling an initialization subroutine that only runs on the first scan after powerup/restart.

Other AB subroutines that don't depend on you or your main ladder scan's at all are timed interrupt routines (STI) and peripheral input interrupts (PII). They don't have to be called from anywhere to execute.

Please DO use subroutines! Jst consider the problems a service technician has to handle if a program of 2000 instructions is written in one large block. If he/she has to search the problem, he/she has to struggle through the whole programm to find it. Just cut this program up into functional subroutines and the problems vanish! They only have to look at the routine involved with the faulty part of the machine.

A good programmer always thinks of the people who follow. Don't make it harder to read the programm than necessary. They will thank you for it. This is also the main reason why everyone should write their programs as much as possible in ladder. Not every servicetechnician is capable of reading instruction lists.

Be kind and be happy!

Kind regards,

Jean Pierre Vandecandelaere
Trainer PLC - SCADA

/Agree jvdcande !!!

I absolutely despise jobs that come in house with a Simatic 545 type processor just because the subroutines are essentially all inlined.

For processors that support them (Most thankfully, these days), my standard program structure is laid out like this:

Main_file (dispatcher)
Conditional-First scan... JSR Initialization
Unconditional ........... JSR Interlocks
Unconditional ........... JSR Safety
Unconditional ........... JSR Line_Logic
Unconditional ........... JSR Machine_Section_1
.
.
.
Unconditional ........... JSR Machine_Section_n
Unconditional ........... JSR Communications
Unconditional ........... JSR HMI_Handler
End

Then I go and flesh out each section, one at a time. I find it helps not only with troubleshooting, but it helps amazingly when programming, just to be able to break a process down into smaller, managable chunks, and deal with them one at a time.

Most processors allow for Empty subroutines, as long as they are declared.

My advice to everyone also is try to get in the habit of designing well structured code, it is easier to program, easier to debug, and easier to reuse pieces in other projects.

The only thing more important in actually programming a PLC is to DOCUMENT EVERYTHING AS YOU ENTER IT. Every word, Every bit, Every bit of used or spare space you allocate should be described.