Control logix prescan

I have a controllogix PLC utilising devicenet I/O, and am having problems that I believe are due to the prescan.
Certain logic utilises examine offs of inputs to execute logic (turn off latches). I would normally utilise an examine on in series (eg. circuit breaker contact), but was unable to do this.
No problem thought I, I'll jump the logic upon power up until the I/O is up and running (takes about 40 seconds for the devicenet to burst into life!).
The problem is, some latches still turn themselves off after stopping/starting the PLC(grrrrrr). I assume this is the annoying prescan that is scanning my logic and turning the latches off (because the I/O is all off) even though I am trying to Jump over it. Any ideas as to what I can do to prevent this prescan turning off the latches?

TIA

Greetings davegr,



I know that your description of the problem makes perfect sense to you ... but personally, I’m having a hard time following it ... maybe (probably?) other members will have better luck ... if not, why don’t you post your program - or at least a small sample of what’s bothering you? ... maybe a few well-chosen rungs would do ...



once we get a handle on your exact problem, then we’ll probably be a lot closer to helping you find a solution ...



just as a starting point: to the best of my knowledge, prescan doesn't turn off "latches" ... UNLESS ... the bit also has an OTE assigned to it - and the OTE can be ANYWHERE in the program - even in an "unscanned" routine ... any chance that this is what's causing your problem? ... I've seen that happen before with other AB systems ... the ControlLogix prescan is probably the same in this regard ... you might find this post interesting ...

sorry I couldn’t be more helpful ...

Any clearer?

Hmm, yes Ron, having reread my question, I didn't make a very good job of making it clear did I? (It was my first post - let me off!).

Ok, while I try to find out how to post rungs, I'll try to explain a bit more;
I essentially have an XIO of an input going to an otu of an internal coil.
When I remove power from the PLC and reapply it, the latch turns off.
I assumed this was because the PLC was scanning the code before the I/O was up and running (as I said previously the devicenet I/O takes a while). So I jumped the logix (using JMP/LBL) until the I/O was up and running. But the problem still persists;
The latch is on, I remove power from the PLC, reapply it, and the latch if off. Is the prescan scanning the logic (because it ignores JMP/LBLs), and turning the latch off (because it is seeing the input off)?
Hope this helps, thanks for your time, and I hope I can be a valuable contributor to this site in the future.

Do a check to make sure your devicenet scanner is up and running in your logic along with your current logic. I did run into this before using a compact logix processor and this was the only way I found to get around that problem.

you mentioned an OTU for the bit ...

question: what turned the bit ON in the first place? ... do you also have an OTL for this bit? ... usually (but not always) we see OTLs and OTUs used in pairs ... if that's the way that you have it programmed, then I'm pretty sure that a bit which was ON when the processor shut down, should still be ON when the processor comes back up ... that's the way that Latches and Unlatches are supposed to work ...

but you're having problems aren't you? ...

so now for the big question ... for the "problem" bit - do you - or do you not - have an OTE addressed for that bit? ... if so, then THAT is the problem ... an OTE will ALWAYS turn the bit off during prescan ... regardless of whether you "jump" the ladder logic or not ...

my ControlLogix gear is at home ... if you can get some programming samples posted before I leave work (an hour or two) then I'll tinker around with these ideas tonight and let you know if I can come up with anything ... basically, you can ZIP the ControlLogix program file and click the "Attach Files" button at the bottom of the "post reply" window ... hint: don't use "quick reply" ...

Greetings Ron Brown,

welcome to the forum ... and thank you for your input ... I was hoping that someone with more ControlLogix/DeviceNet experience than I have would show up soon ...

Dave,



something just hit me ... are you using the word “latch” to refer to a “seal-in” rung construction? ... many people do that ...



take a quick look at the figure at the bottom of this old post ...

most of us call the rung construction at the top (rung 0000) a “seal-in” rung ...


the two rungs at the bottom are “latch” and “unlatch” rungs ...



if you’re referring to the rung construction at the top as a “latch”, then I strongly recommend that you stop that ... I’m too old to change my ways ...



maybe this “latch/seal-in” description is what is causing most of my confusion ... if so, then the OTE (little coil-type thing) at the end of the “seal-in” rung is what is causing your problem ... basic idea: prescan turns OFF all OTEs ... period ...



finally a real “latch” will have an “L” in the middle ...



as in ----(L)-- ... an OTE is always empty ...



as in ----( )--

OK guys, yes I am using a real latch OTL and OTU. Secondly, no OTE of the same address, or anything else that addresses the bit (just one OTL & one OTU).
The really odd thing is that I do not have a problem when going from prog to run. Only when the PLC restarts after losing power (eg switching the power supply to the rack off). Either weirder is that some latches remain on, whilst others turn off. I did notice however, that if a latch on rung 123 for example turns off, then all latches after this point are also off. It is almost as if the PLC is scanning from where it left off when power was removed until it reaches the end of the program.
Anyway getting late here, so this is not an urgent issue (relates to a problem I had a few weeks ago). I'll post some logic tomorrow.

Either weirder is that some latches remain on, whilst others turn off.

Click to expand...

are some of the inputs wired to AC while others are wired to DC? ... I’ve seen really weird “some-go-off-but-some-stay-on” problems caused by this before ... let me know if you’re interested in this line of thought ...



so what voltage are the inputs? ... and does turning the power to the “rack” off also turn off power to the inputs? ...

It is almost as if the PLC is scanning from where it left off when power was removed until it reaches the end of the program.

Click to expand...

here are some previous posts along these lines ... start here but be sure to read the next one too ... the topic was too big to fit into one post ...



and then this one might (or might not) be helpful - or at least interesting ...



I’ll probably be offline until Friday ... traveling for Thanksgiving ... and personally I have a LOT to be thankful for ...

davegr said:

OK guys, yes I am using a real latch OTL and OTU. Secondly, no OTE of the same address, or anything else that addresses the bit (just one OTL & one OTU).
The really odd thing is that I do not have a problem when going from prog to run. Only when the PLC restarts after losing power (eg switching the power supply to the rack off). Either weirder is that some latches remain on, whilst others turn off. I did notice however, that if a latch on rung 123 for example turns off, then all latches after this point are also off. It is almost as if the PLC is scanning from where it left off when power was removed until it reaches the end of the program.
Anyway getting late here, so this is not an urgent issue (relates to a problem I had a few weeks ago). I'll post some logic tomorrow.

Click to expand...

What you're desribing fits the action of a power-up handler. It will only execute on restoration of power after a power loss in run mode. It won't execute on changing from program to run or after power loss in program mode. I believe the processor does resume execution where it was interrupted by the power fail after executing the power up handler.

The prescan doesn't execute any logic - just initialises any non-retentive tags (OTE, TON, TOF, ONS).

OK guys, I believe I have found the problem, thanks to this and previous threads.

I tried to simulate the problem on the bench with a PLC and some Devicenet I/O, but couldn't do it....until I turned off the main panel isolator (which supplies everything), NOT just the rack power supply.

What I believe is happening is that as the power is turned off, the supply to the field devices is killed, just before the PLC stops scanning. The PLC then sees the Inputs as off, and thus turns off the latches. This would explain how sometimes some latches go off and some stay on, it all depends on how quickly the PLC dies in comparison to the I/O and what it finishes scanning. Unfortunately I don't have an input from the supply breakers that I could check, but I'm sure I can find a get around now I know what is happening.

Thanks all.

Control logix power supplies are designed to have a slow decay of power when switched off. It allows them to ride through a short power fail.
Also I think Rockwell are starting to use the time of the decaying power to backup the program to non volatile ram.
Regards Alan Case

What I believe is happening is that as the power is turned off, the supply to the field devices is killed, just before the PLC stops scanning. The PLC then sees the Inputs as off, and thus turns off the latches. This would explain how sometimes some latches go off and some stay on, it all depends on how quickly the PLC dies in comparison to the I/O and what it finishes scanning.

Click to expand...

and THAT'S the difference between AC and DC inputs that I was talking about ... they CAN react differently when the power to the system is interrupted ... if you haven’t already done so, then I suggest that you read those posts that I linked earlier ... one of them covers this exact scenario - although not for a ControlLogix platform ...

incidentally ... when I ask my students to list the differences between AC and DC inputs, they all mention “safety” ... “simplicity” ... “cost” ... and things like that ... but NOBODY has EVER mentioned this “look-what-happens-when-the-power-is-interrupted” issue ...

suggestion: if you can do it SAFELY, you might consider using normally-open wiring for your “unlatch” inputs ... sometimes that’s a simple solution to this particular problem ... BUT! ... be sure that you end up with a “FAIL-SAFE” situation ... post again if you need more detail on this aspect ...

tip: you can demonstrate this “look-what-happens-when-the-power-is-interrupted” issue by watching the LEDs on the front of the processor - and the LEDs on the front of the AC input module ... keep an eye on both sets of LEDs as you flip the power off ... the processor LEDs will stay on for several seconds (the “decay time” that Alan Case mentioned) but the AC inputs which were being held on by their external circuits will die out instantly ...

now ask yourself this question: what state did the PLC just “see” for that particular input - just before it quit scanning the program? ... answer that one, and everything starts to fall into place ...

Thanks for the reply Ron. I know you don't know my level of experience etc, so it is hard to tailor your posts to someone you don't know. I have over 20 years experience of writing/commisioning PLC systems, mainly Rockwell, Modicon, & GE (although this doesn't guarantee I'm any good does it).
Anyhow thanks for your post, the unlatches need to be N/C for fail safe reasons (they are photcells with reflectors). Not a problem, it just means that I will try to find a suitable N/O input (normally an auxiliary off the input supply) to go in series with the photocell. Back to work...