Micrologix 1200 Interrupts problems

[gertsc 0]

Hello, I am having trouble using the interrupts routine on a Micrologix 1200. I made a small test program as following: In LAD2 I have a JSR U:4 LAD3, first lineI have the INT (I/O Interupt) as first command connected to counter C5:1 LAD3, second line I have EII:0/UXI connected to counter C5:2 LAD3, third line I have tryed with or without a RET command LAD 4 is my program In the EII:0 function file Values are set as following: PFN=3 UIE=1 EIE=1 ES=1 IS=0 The others are 0 The Input filter for Input 0 & 1 is set to 1ms (I am just toggling input 0 on and off for now) Nothing happen to the two counters, Any idea what I am doing wrong? thanks, gerry

[KidPLC 2]

Hi Gertsc, Have you tried using a OTL in LAD 3 rather than counters just incase they are the issue? at least if you toggle the switch and the OTL is latched you will know that LAD 3 has been scanned and the interupt works. Better still an ADD instruction to increment a register every time LAD 3 is called. I don't have an RSLogix500 user manual handy however does the AS bit need to be set to 1??

[KidPLC 2]

Hello again gertsc, I have an update on my last post, I have done a quick test on a EII interupt on a micro 1500 (which should operate the same as your 1200) and she is no go if the AS bit is not set to 1. The UIE and EIE do not need to be set to 1 as the AS (Auto Start) manages this when the plc goes into run mode. Now further to all this the counter alone on a rung does not work either however an ADD instruction just incrementing an N7:0 by 1 works fine. I also tried your EII:0/UIX and it did not work either not even in ladder 2 which is scanned continuously so I am not sure what is going on here?? You can use the UID and UIE instruction in normal code to disable (UID) and enable (UIE) the Interupt as you wish but the AS bit must be set to one in the offline program then downloaded. Hope this helps

[Guest]

Greetings KidPLC ... good work with the "use an ADD" idea to confirm the scan ... the problem with using a CTU counter to do this is that the counter must see a TRANSITION (change) from FALSE to TRUE before it will increment ... if I understand what you guys are up to, the condition leading into the CTU is always TRUE - therefore it doesn't see a CHANGE - and it won't count up ... note: if you're using an ADD for something like this, it's best to use F8:0 or some other "floating point" location for testing ... reason: if you use an integer (for example N7:0) then you run the risk of an eventual math overflow condition which will fault the processor - unless you take steps to prevent the fault ... look up S:5/0 if you're interested in going further with this line of reasoning ... side trip: if you want to play and learn more, put a rung right above the CTU and use it to UNLATCH the counter's CU bit ... for example try OTU C5:0/CU ... party on ... Edited 22 Aug 2008 by Ron Beaufort

[KidPLC 2]

Thanks Ron, I see what you mean about the counter and you have made a good point regarding the maths overflow with the integer. Cheers

[gertsc 0]

Hello all, Thanks for all the replyes. I used the ADD function as suggested instead of the counter, and everything works fine. The maual mention to use the RETURN command in the end of the Interrupt routine, but it works with and without. Are there any special reason to use the RETURN command? gertsc

[KidPLC 2]

Great question!!! I will be interested in the reply to this one. I have always wondered about the SBR command as well, personally I have never included an SBR or RET in any of my code and have never experienced problems. Keen to hear what the Gurus have to say

[Guest]

well, while we're waiting for the gurus to show up, I’ll give it my best shot ... the SBR (Subroutine) instruction serves NO purpose - unless you’re “passing parameters” to-and-from your subroutines ... RSLogix5 and RSLogix5000 allow for procedures such as that - but RSLogix500 does not ... so ... when using RSLogix500 the SBR serves NO purpose ... you can put it at the top of your “subroutine” ladder file if you want to (and some programmers do) - but it doesn’t do you any good ... the RET (Return) instruction serves NO purpose - UNLESS you’re “passing parameters” to-and-from a subroutine ... OR ... if you want to “bail out” of a subroutine part way through the file ... example: suppose that you always want to execute the “top” part of a subroutine file - but that the “bottom” part only needs to be executed under certain conditions ... in that case, you can put an RET rung part way down through the file - and make that rung “conditional” based on something like a switch ... when the condition is TRUE, the processor will “bail out” of the subroutine as soon as it hits that RET instruction ... going a little bit further ... many of the guys who habitually stick an SBR at the top, and an RET at the bottom, of each and every subroutine file do that because of the way they learned to write “structured” programs (examples: BASIC, etc.) ... in many of those languages, you MUST put a “return” statement at the end of each subroutine - or the processor won’t “come back” to the main routine ... so - the habit gets formed and carries over to PLC programming ... now let’s see what the gurus have to say ...

[KidPLC 2]

Hi Ron, Fantastic explaination of SBR and RET instructions...much appreciated. Cheers

[pabeader 0]

no guru here but I have a question/comment... isn't the return address for subroutines pushed on a stack? if you don't return from a sub then the address stays on the stack. won't the stack eventually overflow? or is it different for PLCs?

[Guest]

yep ... in most “higher” languages you MUST tell the processor to RETURN - or it won’t ... Edited 27 Aug 2008 by Ron Beaufort

[pabeader 0]

you the man Ron!!