question on subroutines

hello all
is there a rule of thumb as to using or not using subroutines when writing a program ?
i am using an Allen Bradley slc 500
thank you much for do's and dont's

Technically, there is no rule. Practically, you want your program to be as organized as possible for ease of future edits. You use the subroutines as a way to break your program up into different bite-sized pieces. So if you're programming a conveyor system that just has a motor and a few sensors, you can do it all on one subroutine. But if you're programming an automation line that has an infeed, three separate steps of production, and then a packaging area, you would split each step up into it's own subroutine.

Personally, for each area of a machine I'm programming, I like to have an INPUTS routine that scans the actual hardware addresses for incoming information (sensors, proxes, button states, etc) and then mirrors those state changes into arrays. Then a CONTROL routine that runs those state changes through the logic using my arrays (not my actual hardware addresses) to decide what needs to change, and finally an OUTPUTS routine that changes the state of all my outgoing channels (motor starters, speed settings, light states, etc). You usually also have FAULTS and ALARMS on their own subroutines, and if you have an HMI that needs logic, that usually has it's own as well.

I break up the program into subroutines (sections)

if a machine has 10 sections of different operations, break it up that way.
assign different b,t,c,r,n,f files.

if a machine has 10 stations that all do the sane thing, write the code for station 1 and then copy the program to a library file.
import the file into station 2 using index file structure.
repeat for stations 3-10.
that way, if you know station 1, you know all the others.
b3 - general purpose
b13 - station 1
b23 - station 2
b103 - station 10

makes life easier when you find an error in one station and then change the others.
if a machine has multiple test fixtures, have a subroutine for each test fixture.
I had a machine with 32 possibilities. they were easy to debug based on the fixture number.

regards,
james

thanks to LoganB and James
for info, the program seems to be jumping allover with rungs added to make the machine continue when those parts and pieces aren't even there.
thanks again

What type of machine is this?

from your description, the machine was built for part a and then parts b,c,d... were added or some variation.

that was my issue with a machine that they added different fixtures to it.
each fixture ran different parts and the program was getting complicated.
that's why I added subroutines for each fixture. it was so much easier when you had a problem, look at that subroutine. downtime went down a lot.

james

As Logan stated: technically there is no rule.

My personal rule of thumb is recurrence. A good programmer is inherently lazy: you don't want to write the same code twice. If I run into a second instance where I need code that I have already written: that is a flag to put this into a subroutine. Reasons for using subroutines are plenty. Among these are: code once, debug once, modify once.

Future modifications are a sure source for hard to find bugs if you have copied/pasted code instead of using a subroutine. You are going to fix one instance, forget about the other(s). Now there are three things in life that you can be sure of as a programmer: death, tax and future modifications. Write your code with future modifications in mind. The other two don't belong on this forum.