Do you use Sub-Routines?

[504bloke]

On the most part All the time........

 

[Sheldn]

Perhaps another question to ask is how are you using subroutines.

1.) As a way of organizing the logic for example Analog Signals, Process Areas (as many as needed), HMI data handling/Interface.

2.) Using subroutine calls to handle typical logic such as defining logic blocks that handle all logic associated with a motor for example and then shove the data into registers or a data structure. Or do you simply cut and paste the typical logic as many times as you need it such as the Library tool in Logix 500?

 

[Gerry]

377 views
68 votes

...what does that signify?

indifference, ignorance, indolence ??
another poll required?

 

[CaseyK]

377 views
68 votes

...what does that signify?

People checking back to find out how the vote is going, no doubt.

Not allowed to do another poll for three more days.

regards.....kc

 

[Doug_Adam]

In Siemens, FB and FC blocks do the same thing as subroutines.
We commonly use them. If you have one function used repeatedly, it makes sense to create a subroutine.
On the other hand, it is possible, and sometimes desirable, to program without subroutines.

 

[S7Guy]

I just took a look at the last large project I did. The actual number of executed instructions per scan is 155,000 (plus or minus a few thousand due to some routines only being executed as needed). I took liberal advantage of subroutines and indirect addressing to make my code clear and manageable, and I ended up with about 20,000 lines of actual code. I haven't worked with a processor that doesn't handle subroutines, but I can't even imagine it would be much fun to maintain large programs without them. Even on the small programs I've done, I always end up with at least an OB1, some FCs, and a couple of DBs. And the fact that I can drag and drop these routines from project to project really speeds things up when making code updates.

 

[darrenj]

I just took a look at the last large project I did. The actual number of executed instructions per scan is 155,000 (plus or minus a few thousand due to some routines only being executed as needed). I took liberal advantage of subroutines and indirect addressing to make my code clear and manageable, and I ended up with about 20,000 lines of actual code. I haven't worked with a processor that doesn't handle subroutines, but I can't even imagine it would be much fun to maintain large programs without them. Even on the small programs I've done, I always end up with at least an OB1, some FCs, and a couple of DBs. And the fact that I can drag and drop these routines from project to project really speeds things up when making code updates.

A perfet example of why to use subroutines..(Or in the case of CLX "Sceduled task's"..can you imagine the poor sparke trying to troubleshoot and having to wade thru 20,000 lines of programing??The mind boggles..

D

 

[tom_stalcup]

I tend to use subroutines more often than I might, just because of the way rung comments worked in the logix500 and logix5 packages...
The programs on our filling machines here have one main routine, and everything was divided neatly by rung comments for the different sections of the machine, but......
Any time someone added a rung to the program, all of the default rung comments were offset by however many rungs they added to the program. When I took over here, after 5 years of previous people making changes/additions, all of the neatly organized rung comments that divided the program into sections had been mangled, and I had to go thru each program and rebuild them. And then try to make sure that whenever someone besides me made some changes that I had a chance to fix the comments later.
It's not so much of a problem these days, because I finally have everyone trained to not "program" their way thru a sticky solenoid, etc..... So in general I'm the only one making code changes.
So any programs that I normally would document by rung comments gets divided up into subroutines whenever possible, just to cut down on possible confusion.

 

[BobB]

A perfet example of why to use subroutines..(Or in the case of CLX "Sceduled task's"..can you imagine the poor sparke trying to troubleshoot and having to wade thru 20,000 lines of programing??The mind boggles..

I do not agree. Did you read my previous post? There is absolutely nothing wrong with breaking the program into "sections" that are called what the section handles. I have some programs with 25-30 sections and have yet to find anyone who has problems following what I have done.

I guess "scheduled tasks" could be loosely described as a lot of things. I am not familiar with CLX but seriously suspect that they are akin to "tasks" in Omron as described in my previous post. The Omron tasks are not scanned at all unless active (turned on).

At the end of the day, the main thing about any complex program is documentation and descriptions of what each section and rung are all about.

Any time someone added a rung to the program, all of the default rung comments were offset by however many rungs they added to the program.

I thought that went out with old DOS programs. Rung comments should travel with the rung - end of line!!! It should not matter how many rungs are added - and the new rungs should have their rung comments travel with the new rung also. It appears that the program gets terribly confused. Glad I don't have to use it!!!

 

[PhilipW]

Bob,

RSLogix 5/500 allows you the option of attaching the comment to the File/Rung number, or to the Output Address whichever you prefer.

As for Tom's comment, the exact answer may depend on the Version you are using, but I can assure you the Ver 6.3 I have been hammering away at for the last week does NOT exhibit the behaviour Tom mentions.

It is of course always possible that in Tom's case that people were performing online edits without saving the file offline...so next time they went online and did an upload, the online logic would merge with the offline comments, and quite naturally get screwed up. The Database tool has a simple mechanism to allow you to re-allocate the comments to the correct rung if required.

But I have to re-emphasise...this is not an issue in normal use.

Tasks in the CLX are a different thing to what you have in mind. You can define up to 16 of them, one of them on a Continuous basis (like a normal PLC scant), and the other 15 are defined on a Periodic or Event basis. Periodic tasks are given a Time Interval and Priority. Each one can have up to 100 Programs called within it, and each Program can have unlimited routines. Each Program can have it's own locally scoped tag datatable.

A Task may or may not configured to scan IO. For many projects I actually have NO continuous task, and run everything on a Periodic basis of about 200msec.. This works very well for Process Control type applications like Pumping Stations, or large slow dairy processes.

 

[BobB]

Fair enough Philip. It did seem rather strange. I guess I am used to having rung comments and output comments available as well.

It is of course always possible that in Tom's case that people were performing online edits without saving the file offline...so next time they went online and did an upload, the online logic would merge with the offline comments, and quite naturally get screwed up.

Have seen that before with just about all brands of software.

 

[tom_stalcup]

It is of course always possible that in Tom's case that people were performing online edits without saving the file offline...so next time they went online and did an upload, the online logic would merge with the offline comments, and quite naturally get screwed up.

RSLogix 5/500 allows you the option of attaching the comment to the File/Rung number, or to the Output Address whichever you prefer.

Probably some combination of the two.... Our original programs had all of the rung comments defaulted to the file/rung number instead of the output address, so I imagine that's why the rung numbers would get offset.....

As Phillip said, there is a simple tool in the database that will let you offset the rung comments.... The trick is knowing you need to in the first place.