Split MCP into subroutines

[Eagle 0]

Hi all, I'm new at this board and I was scrolling trough the threads. I saw that maybe somebody can respond and help to solve my little prob. We are running on our package line an PLC 5/40 interfaced on DH+ with 5 panel views and to a DCS system. Actually the main Prog. consists of about 2000 Rungs stuffed in the MCP (lad2) and has no subroutines at all. The actual average Cycle time is about 12-14ms. The code consists of some math functions but mainly of common ladder logic. Considering that the production line has various stations I was asked to split the main program into various parts, referring to each machine part of the line. The only way to do this I think is to split it into several subroutines. I'm not so familiar with subroutines on AB so please excuse if a question maybe sounds a little bit A) Is it possible to jump into a subroutine (JSR) from the MCP without passing any type of parameter, using the same logical element addresses ( N7:10, etc) as in the MCP, execute some math, BTW/BTR, set outputs, preset timers etc. and return (RET) to the MCP without any return parameters ? Every subroutine will called only once in the MCP. B) I'm going right if the MCP (Lad2) will simply be split into subroutines without nesting, the cycle time will not increase in significant manner ? C) Due to the fact that nothing will be added, only be split, I think it will be not necessary to update I/O within every subroutine ? The update of the I/O by the processor is done on reaching the end of the main program. The main progr. basically only contains the JSR to the subroutines. Long words for a maybe little problem. Many thanks in advance for your help. Best regards Eagle

[Ken Moore 23]

I believe each JSR/RET without parameter passing will add a little over 12 microseconds to your scan time. See attached clip for the PLC-5 programming reference.

[Spedley 0]

It's a long time since I've done anything with PLC-5 but from what I remember there is no problem in just breaking the code into subroutines. i.e. putting the first 100 rungs into File 3 and using a JSR 3 in its place. Just remember when using subroutines like this it's usualy best to make them non-conditional and also remember that often the order of rungs is crucial so be very carefull about changing the order of exectution (e.g if station 1 is halfways down your file then put the JSR ... in the same place, don't move it to the top )

[OkiePC 14]

YES you can JSR without parameters. You should end each SBR with a RET. You should (but aren't required to) start each SuBRoutine with a SBR label on the first rung. Another way to organize your code with no cost in scan time... Use page titles to separate the stations. (Right click on the rung and select Edit Title.) Hit CTRL+D to use the "Advanced Diagnostics" (I don't know why it's called that) to get a pop up window that starts off by displaying a list of ladder files. Each time you click on a ladder file, the page titles within that file are listed. Each time you click on a page title, your ladder window will jump to that line in the program. You can drill into each section in more detail and view rung comments and more. This is a really handy way to get around in an unfamiliar, complex, or disorganized PLC program. It's all done with page titles and rung comments which are stored offline so there's no scan time cost associated with this method. Paul C. Edited 3 May 2005 by OkiePC

[Gerry 13]

This would not happen as a matter of course with subroutines - you would need to program immmediate I/O instructions to get an update within the subroutine. Note that with the 5/40, you can have multiple MCP's (max. 16). File 2 is the default. You can segment your program into separate files the same as you would for using subroutines, but rather than call them with JSR's, designate them as MCP's. With this arrangement, you can opt for I/O scans for all or some of the MCP's. Each MCP is executed in sequence in the order that you have configured them (without any special programming).

[Guest Guest]

Hi all, I would like to say thanks to everybody that helped me with suggestions and facts. This Forum really rocks . Fine and kind people. Thanks again, Eagle

[wildswing 0]

Hi Eagle...(my first post here)... What you're describing sounds exactly how all of our 5's are set up. MCPs consist of nothing but JSRs with no passing. Individual program files do not use SBR or RET instructions. In fact, I was told by a Rockwell trainer that when not passing parameters it's best not to use the RET. It's not needed and it adds to scan time. The program will naturally return to the MCP when it reaches the end of the file. Just keep the order of the rungs the same and it should work fine.

[TConnolly 13]

I would recommend the option that Gerry pointed out. Split the program into various program files according to function or zone. Then in the MCP tab of the processor status file, starting at word 80, enter a 2, a 3 in word 83, a 4 in word 86, etc.... until the MCP table is filled with the subroutines. See the online help for this tab in the processor status file dialog in RSL5. You can designate up to 16 program files as MCPs. Each of these will run in order without any extra programming on your part. If however you need more than 16 you will have to use JSR instructions.

[Firetubes 1]

Becareful when using MCP's as replacement for JSR's. The scantime for MCP's are extremely high so make sure your process can take the hit.

[Gerry 13]

By default, each MCP has I/O update enabled - i.e. there is an I/O scan between the execution of each MCP. This can greatly increase overall scan time. Generally, one I/O scan for the lot is all that's needed and it's easy to disable the individual scans by checking the "skip I/O update" tick box on the status display. From memory, you can tick all the boxes and the PLC5 will do one I/O scan anyway. I would think that MCP vs JSR should be faster since the CPU doesn't need to stack a return address when progressing from the end of one MCP to the start of the next.

[Firetubes 1]

Good point on the IO scan/update enable, Gerry. I ran a test on a old project and found: 11ms using JRS for 10 files 14ms using MCP for 10 files with IO Scan disabled 33ms using MCP for 10 files with IO Scan enabled

[TConnolly 13]

Interesting reslults Firetubes. I would have thought that the MCPs with IO updates disabled would have been slightly faster than JSRs because of the stack overhead. Well, 22 years later and I still learn something new everyday in this industry. That's what makes it such a great career IMO. Since the scan penalty isn't very much then I would recommend whatever approach the programmer and the maintenance people feel most comfortable with as the the objective is to break the program into manageable chunks, not make it more difficult to manage.