Need help on RS Logix SUBROUTINE command

[Guest Ian Spiteri]

I am new to RS Logix and currently experimenting with the Allen Bradley Micrologix1500. After this experimentation period, I am going to use the Micrologix1500 for a school project since I am currently studying electronics engineering. I would be more than pleased if i receive any examples regarding the SUBROUTINE and any associated commands. Feel free to send any examples by e-mail to ianspiteri@onvol.net Fell free to send any attachments including RS Logix software files. 10x a lot Ian

[Chris Elston 78]

tons of programs here. download away... http://forums.mrplc.com/index.php?act=Downl...s&CODE=01&cat=2

[Guest]

Greetings Ian, the basic idea: the subroutines (extra ladder files) are usually set up for organizational purposes ... for example: the grinder code might be kept in Ladder File #5 ... the conveyor code might be kept in Ladder File #6 ... the pump code might be kept in Ladder File #7 ... etc. ... then Ladder File #2 (which is always scanned) contains JSR (Jump to Subroutine) rungs to send the processor off to scan the appropriate file – and then return to Ladder File #2 ... yes, the subroutines CAN be set up to sequence a machine’s operation ... for example: the code to “move the grinder head down” might be kept in Ladder file #3 ... the code to “grind the part for ten seconds” might be kept in Ladder file #4 ... the code to “move the grinder head back up” might be kept in Ladder file #5 ... then Ladder File #2 (which is always scanned) could contain JSR (Jump to Subroutine) rungs which are “sequenced” to send the processor off to scan the appropriate file ... at the appropriate time ... to go step-by-step through the machine’s cycle of operation ... as I said, you COULD do it this way ... but it is NOT recommended ... one major thing to remember is that if an output (for example: a motor to move the grinder head) is turned ON in one ladder file, then that output will STAY ON when you quit scanning that file ... that is, unless you program “something” to prevent that situation ... and by the time you program all of that “don’t-forget-to-turn-this-one-off” logic, you’ll have totally lost any advantage that you were trying to gain by using the “subroutine” idea in the first place ... to sum up ... my advice to beginners is to: (a) use the subroutines to help “organize” the program ... like chapters in a book ... (b) do not try to use the subroutines to “sequence” the step-by-step operation of a machine ... best regards, Ron

[autocontrolit 0]

I agree w/ Ron ladders are best used for organizational purposes. While you can reduce code and scan times by using the ladders to sequence machine operation, later issues can occur not from code, but from others ignorance of how the JSR, JMP, and LBL instructions work. I ran into this myself when buiding a box forming machine. It was encoder controlled with 18 JMP instructions not including the JSR's as well as 4 SQO (sequencer) instructions. Well long story short we had several issues w/ maintenance technicians complaining about how the code did not work. Somehow any mechanical problem was a result of the code since the outputs in the middle of the JMP's was not enabled with everything before it true and an alarm staring them in the face on the PanelView. After several weeks of retraining and adding even more alarm conditions (went from 31 alarms to over 60 on a machine with only 38 I/O points) to the panelview to troubleshoot the machine for them this slowly went away. I guess what I am saying is think of the end user. This project was done w/ a MicroLogix 1500 1764-LRP w/ 1761-NET-ENI for data collection and downtime tracking. I am not dogging anyone for their lack of understanding, but just remember not everyone is a programmer or has a desire to be. Just because you can understand it do not expect anyone else to.

[Ken Moore 23]

I also agree with Ron, unconditional subroutines are great when it comes to trouble shooting. I usually but all my analog scaling in one routine, motor control in one, valve control in another, Block transfers in one, messages in yet another etc... However, I do think there is a place for conditional subroutines, especially in batch process control. I admit its not for beginners, because of the need to ensure outputs are not left on, timers reset etc... But in a batch operation such as making a cake. You could have a sub for adding milk, a sub for adding eggs, a sub for adding flour and so on, that run independantly not sequencially, by only running them as required you don't slow down your scan times as much. You then only run the milk sub when your recipe needs milk. So even though line 1 is baking, line 2 is at the milk add stage, and the milk sub is called to deliver milk to line 2. I hope I clarified instead of muddling, but sometimes what I think is clear, others see as mud. My point is that conditional subroutines are not for beginners, but they can quite useful to more advanced programmers. My example is more likely to be used in a PLC-5 or larger SLC that is controlling multiple processes. Ken