Forgot the JSR

I've got well over 2500 Rungs. And if you aren't working with some sort of hard-print guide of some kind... you are nuts.
 
If you use a single main-body without any subroutines, and then make comments for anything in your main-body... then don't the comments stay with the main-body code, at least in the local PC?

Other than that, your point doesn't make much sense.

Hmmm.. Well, a lot of the way I do things have been influenced by the programs I have here on site to compare them to.(And the fact that almost everything in the plant is AB)

In AB land, if you create "rung comments"(comments that documents a rung or area of program instead of a specific bit or command) you have a couple of options for how to create them. You can pin them to the specific rung number, or to the address of whatever bit is on the rung.

If you have them set up for rung number, then ANYTIME you add new rungs above the existing rung comment, all of the rung comments below that spot are now in the wrong spot.(by however many rungs you added/deleted) In order to keep things in order, you have to offset the rung descriptions by however many rungs you added/deleted using one of the database tools(nothing happens automatically).

If you have them set up for output address, you will still have the key comments tied into whatever bit address is at the end of that rung, so unless you change the purpose of that bit your comments still track.

Clear as mud?
 
I guess it all depends on how you look at it. The JSR instruction is an AB specific instruction, as far as I can tell, and calls itself Jump to Subroutine. I have never really considered it a subroutine, closer to what others would call stage programming.

All it does is allow you to separate different sections of the system for organization, not to say you cannot do it in one rung but for some of us it is easier if we know the machine and separate the different sections. To my knowledge it does not affect scan time, at least in my experience, not noticeably.

All I can do is offer an example, in pdf format, that uses JSR's for that purpose. I never forget them because if I do a system using them I have it planned out in advance so insert the JSR then goto that Ladder file and create the program.

In the example there are 5 paper converting machines with 5 conveyors that feed to another conveyor to combine the products for packaging.

BTW That plant is closed and I have no idea where the machinery is now.

The pdf was too large to upload: http://www.patchn.com/REWIND_CONVEYOR_SYSTEM.pdf
 
Hi Folks...I just thought I'd throw something in on this fray. Ron said
I guess it all depends on how you look at it. The JSR instruction is an AB specific instruction, as far as I can tell, and calls itself Jump to Subroutine. I have never really considered it a subroutine, closer to what others would call stage programming.
Could "stage pogramming" be the same as "structured programming"? In other words the JSR is just a tool to "structure" your code into smaller chunks for ease of troublshooting etc. etc. and therefore NOT really considered a SUBROUTINE.
Later...Todd
 
I use JSR’s and have forgotten to put the JSR logic in the main program once or twice…well maybe a few more times than that.





As far as weather or not it’s good programming practice, I remember working on a punch press with multiple replaceable dies about 8 years ago. I was very grateful to the engineer that programmed it for using JSR’s. Each die had it’s own subroutine, and if that die wasn’t in place in the machine, the logic for it wasn’t scanned. The dies were connected via an amphenol plug and shared the same inputs and outputs, but had totally different functions. The same output may control a clamp on one die, a shift cylinder on another, and a stripper on a third. If I remember correctly, the first 3 pins of the amphenol plug on the die determined which JSR was used depending on which inputs were on giving 7 possible dies in one machine. Finding which subroutine was active and looking only at that logic made it much easier for troubleshooting.



Since then, I’ve had many occasions where logic only needed to be scanned under certain conditions like fault routines, or when certain stations needed to be on only when a certain part was being made. I’ve also found it easier to organize a program by using unconditional JSR’s.

 
Logix said:
I use JSR’s and have forgotten to put the JSR logic in the main program once or twice…well maybe a few more times than that.





As far as weather or not it’s good programming practice, I remember working on a punch press with multiple replaceable dies about 8 years ago. I was very grateful to the engineer that programmed it for using JSR’s. Each die had it’s own subroutine, and if that die wasn’t in place in the machine, the logic for it wasn’t scanned. The dies were connected via an amphenol plug and shared the same inputs and outputs, but had totally different functions. The same output may control a clamp on one die, a shift cylinder on another, and a stripper on a third. If I remember correctly, the first 3 pins of the amphenol plug on the die determined which JSR was used depending on which inputs were on giving 7 possible dies in one machine. Finding which subroutine was active and looking only at that logic made it much easier for troubleshooting.



Since then, I’ve had many occasions where logic only needed to be scanned under certain conditions like fault routines, or when certain stations needed to be on only when a certain part was being made. I’ve also found it easier to organize a program by using unconditional JSR’s.

The perfect reson to use subroutines if i ever heard one..

Terry..I work in a plant that is Modicon..(Old modsoft programming) The program when printed is bigger than most phone books..(No kidding)..It would have been much easier to follow if the the program was split..I am not saying thats what a subroutine is for..however it is a handy tool to keep things logical...for example..if i have a problem with x machine i could open the program..drill dwn to x machine and look at the code..as it is now i could..

A..break out the phone book and try to find the machine page i want..(Hopefully not to many rungs were inserted since the last print out..)
B..do a search on a specific "address"..(May not work with control logix becouse you could have the same "Tag/addess" used in many different areas)..

I think drilling down to the machine and looking from there is far quicker than going over the phone book..
 
Terry Woods said:
I've got well over 2500 Rungs. And if you aren't working with some sort of hard-print guide of some kind... you are nuts.

2500 rungs in a single ladder?! I pray that I never have to troubleshoot any of your code.

A logically segmented and well commented program eliminates the need to have a hard-copy guide. Plus it makes it easier to monitor a process when 'online' because you can have several ladders open at the same time and follow the logical process that happens too quickly to scroll down through.

I like my JSRs boiled in a spoon and spiked into my vein... And I'm having trouble shaking the feeling that you're not just trolling for responses.
 

Similar Topics

It was one of those days. Happy to get a new laptop. Got all my PLC and HMI code moved over, new Rockwell installs, licences moved, the whole bit...
Replies
6
Views
2,434
I had to get a new thumb drive for all of my Rockwell Software, (PV+ and RsLogix.) Do I have to create a Rockwell Software folder or will it do...
Replies
8
Views
2,231
Good Morning , I upgraded a Machine to a CompactLogix ( from a SLC 500), but I never knew that the SLC that I replaced communicated with a...
Replies
5
Views
2,487
hello I have a project that contains a program with a RX3I controller (IC695CPE305), And I protect this project with a password but I have to...
Replies
5
Views
3,550
Hi! It was at least 15 years since I done a project with a Siemens S5. Now I have to make some minor changes (timers etc) on someone else's old...
Replies
6
Views
2,800
Back
Top Bottom