S:FS bit won't turn on after up

S:FS bit won't turn on after power up:

I have an existing program that I had to modify to do something on start up.

One of the conditions for the action is the S:FS bit because it becomes true when the PLC powers up and executes its First Scan.

I have been testing this new piece of code by cycling the power to the machine. Normally, the S:FS bit would be on as soon as I reconnected to the PLC. However, halfway through testing, the S:FS is somehow just not turning on after cycling power.

I've even powered down and left the PLC off for several minutes before powering up, and still it won't turn on.

I also moved it to the main routine, rung 0 to make sure it's the first rung executed.

Anyone experience this before or have any insight as to why it's happening?

How are you verifying that it does not turn on?

Toggling from Program to Run mode is enough to raise S:FS once, no need to wait for power up.

first question:

how do you KNOW that it's not "coming on" ? ...

it's only on for ONE SCAN - so if you're watching the screen hoping to see it turn green - that won't work ...

if that's what you're doing, try putting a simple ADD instruction after the S:FS (something like A + 1 = A) and see if the value of A will increment ...

next question:

do you realize that every separate PROGRAM has its own separate S:FS bit ? ...

so ...

the S:FS bit in question doesn't "come on" whenever the processor first powers up (as you mentioned) ... instead it comes on whenever the associated PROGRAM first gets executed ...

since ControlLogix allows you to have numerous PROGRAMS - and numerous TASKS to schedule the PROGRAMS into operation - then it's possible to have numerous S:FS bits - which can come on at widely separated times ...

(this last little misconception has gotten a LOT of programmers in trouble) ...

suggestion:

if it still doesn't work out for you, consider posting your ENTIRE project file (.ACD extension) and we'll help you nail this down ...

good luck with your project ...

I have the rung so that when the S:FS bit turns on, it energizes an OTE and latches (the OTE has a latch bit OR'd with the S:FS). I have been testing the code for a while and it was working before where the S:FS bit would turn on long enough to latch the OTE, and then it doesn't matter if it's on or off.

I had the rung in a routine which was called by the Main Routine and it worked before so I'm not sure what's changed.
Also, there's only one program.

I tried your suggestion of adding 1, and it did, which means that it is turning on, but apparently not long enough to latch an OTE...

again ...

consider posting your ENTIRE project file (.ACD extension) and we'll help you nail this down ...

Click to expand...

OK ... try doing a Cross Reference on the OTE's tagname - and see if anything "Destructive" shows up ...

thought:

maybe something else in your project is turning the OTE back off again as soon as it gets turned on ...

TIP: instead of using the terminology "latched" - you probably should be using the term "sealed-in" ... an OTE rung doesn't "latch" - it just "seals-in" the bit status to a value of ONE ...

OTL is the "latch" instruction ... this one is "retentive" which means that it is capable of retaining its ON status even after a "go-to-run" situation ... the OTE instruction, on the other hand, always writes a status of ZERO to its bit during the processor's PRE-SCAN operation ...

yes, I know ... many (most?) people refer to a "seal-in" rung as a "latch" ... but in some cases, using the wrong terminology can be part of your problem ...

BST XIC S:FS NXB XIC TestBool BND OTE TestBool

... is working every time for my test.

I also used a second rung:

XIC S:FS ADD TestVal 1 TestVal

... and it worked, too.

Like Ron alluded to, an OTE is something you want in precisely one location.

JeremyM: I had identical lines of code in my program to the ones you just suggested.

The branch latch is what I had originally, and it worked before but it won't work now. The only difference is I had one additional condition inside the branch latch. I took out the other condition so that it was purely (BST XIC S:FS NXB XIC TestBool BND OTE TestBool), however it still won't latch.

I tried the ADD one and it add 1, so I know it is turning on briefly...

Cross-reference shows me that there is only one instance of the OTE, so it's not a destructive bit.

again ...

consider posting your ENTIRE project file (.ACD extension) and we'll help you nail this down ...

Click to expand...

Sorry, I can't provide a copy of the program as it's confidential info that does not belong to me.

I used an OTL instead of an OTE and that. seems to work

Cross-reference shows me that there is only one instance of the OTE, so it's not a destructive bit.

Click to expand...

technically speaking - you're not looking for an instance of the OTE ... what you should be doing is a Cross Reference on the tagname assigned to the OTE ... then look in the column marked "Destructive" and see if anything else appears as a "Y" condition ...

idea:

other things besides OTE instructions can change the status of your bits ...

nvm.

Woah, the OTE does have a Y in the destructive bit column.