Baffled ....

[Colin Carpenter 10]

I'm often baffled, but this one has really got me stumped and I think I may be missing something that's staring me in the face because it's so obvious, but I just can't see it. Attached is a graphic of the code that's baffling me. PLC is a Q02 and software is IEC DEveloper v7.04. Effectively, there are three flags which are "pulse set" whenever certain conditions become true. Any of those three flags being set will cause the timer to run for half a second and the timer timing out will "pulse reset" all three flags. Works fine when I toggle on any of the three flags, so I know the addresses are correct etc, and there are no other instances of the flag addresses being written to anywhere in the programme. Last night I got the call that there was a problem and when we went online to have a look, all three flags were set ON. PLC was running fine, no errors, no other problems. Toggled off the three flags and toggled each one on in turn, and they correctly reset half a second later. Question is, how could that happen? I have no idea other than a quantum fluctuation, but that's a bit of a cop out. Have since re-written the code so that each flag has an individual timer which just resets that particular flag as I think that having three inputs related to the timer may have something to do with it, but I can't make it go wrong, and it obviously did.......

[kaare_t 155]

DO NOT use SET/RESET of the same variable inside the same network! In GX IEC Developer it's important to divide the logic into separate networks since you never know what code will run first/last!!! You may be surprised when you look at the IL code of the specified network. Looking at your code you should divide it into 3 separate networks. See attached picture.

[Colin Carpenter 10]

That was quick. Thanks for that and I see your point, but when the code is compiled, downloaded and tested and it works, then surely it must have compiled in the correct way. Once downloaded, the compiled code won't change in the PLC, so it should just carry on working? I have used hundreds of examples of similar code working with the same rungs and never had such a strange problem before and one which I can't simulate at the moment. I often wish that IEC would let you export the compiled code to a text file so that you could check it out without having to download it to a PLC and then pull it back up again into an instruction POU. Sometimes it would make life a bit easier at times like this. And won't the PLS instructions mean that the sets and resets are carried out at different times? Thanks. Edited 24 Feb 2011 by Colin Carpenter

[kaare_t 155]

If you first compile the code, then right-click on the desired network on the left hand side you can select "Show IL" (or something similar) to see the compiled code for that specific network.... Give it a try and let me know if you figured it out

[Colin Carpenter 10]

Thanks, you're right ... I never knew that ... learn something every day. Have attached the graphic of the IL code of that network and it all looks perfectly OK to me, apart from a couple of OUT instructions system M coils that have been added for some reason ( marked in red). I have no idea what these are used for in the programme, especially the second marked one which comes on when T58 is timing? Edited 24 Feb 2011 by Colin Carpenter

[kaare_t 155]

I would guess that they are "internal" variables used for instructions.... Some instructions create a variable to be able to perform the required action. To me it looks like the variables are in the system area (compiler generated variables) so that's my guess.....

[Colin Carpenter 10]

Absolutely ... they are definitely system generated variables, in fact that's one of big advantages of IEC in that you don't have to define the addresses of bits that you don't need to know. For example, I don't define the address of the PLS bits, but the compiler creates them for me when it produces the IL code, and it uses addresses taken from the defined system address area. I just can't work out why it produces an OUT M5787 instruction with the OUT instruction for T58. It has no use as far as I can see ...... Edited 24 Feb 2011 by Colin Carpenter

[kaare_t 155]

I rarely use the "TIMER_M" function, but could there be that the timer has an additional possible variable for use in the program?? E.g. the "ENO" output? If so I would guess that the compiler will generate a system variable for that even if you don't use it..... Btw this is just another reason to divide the networks into smaller segments; it's easier to debug in IL when the networks are smaller

[Colin Carpenter 10]

Well spotted, I think you're right that it would be ENO bit that would enable something else to be tacked onto the timer. Which timer do you tend to use most often?

[Veganic 8]

At first glance I'd say move the reset and timer to before the setting rung. There is a possiblilty with your code that the timer never gets reset. 1. Set M0 2. Set M0 -> Timer 3. Timer done -> reset M0 4. some part of the program sets M0 and Timer never goes off. Alternatives would be Timer must not be done or enabled to allow the setting of M0 Edit : What I'm trying to say is that it is about the order of scan. Edited 24 Feb 2011 by Veganic

[kaare_t 155]

I usually use the FB (Function Block) timers instead of the FUN (Function) timers since the FB timers have an output coil directly attached on the right hand side... No need for temporary variables, just do what you want directly on the output.....

[Colin Carpenter 10]

I take your point, but when I test it, it works .... but last night all three bits were set and not re-set. Spooky

[Veganic 8]

I can see how it would happen but it depends on the first line of code and how the preceding conditions go on and off.... The sequence would perhaps be something like this: Bit one goes on. The timer times out. The bits are reset. On the very next scan Bit two goes on. The timer stays on so doesn't time out and will never reset. And then it's just a matter of time to wait for the conditions to be right to set the other bits. Once set they cannot be reset without a power off. Whether those bits can actually be set depends on the rest of the program.