First Scan Bit

Do we have to enable the first scan bit somewhere in compact logix?


For some reason my S:FS is not working?

Also, if you want to have the CPU "re-initialize" aka start from first scan
How do you do that?

I tried putting into program then back into run. Doesn't seem to work.

Thanks guys

http://www.plctalk.net/qanda/showthread.php?t=19233

http://www.plctalk.net/qanda/showthread.php?t=113641

http://www.plctalk.net/qanda/showthread.php?t=93842

The above links may help you out.
Regards,

Do we have to enable the first scan bit somewhere in compact logix?

Click to expand...

no ...

For some reason my S:FS is not working?

Click to expand...

how do you know it's not working? ... if you're counting on the instruction to turn "green on the screen" then that's not a good way to tell ...

try putting in a new "troubleshooting" rung with an XIC for S:FS and finish the rung with a simple ADD instruction ... do NOT use a CTU counter instead ... make the Source A entry of the ADD a brand new DINT location ... Source B should be the number 1 ... make the Destination entry the same location as Source A ...

now run the test ... if the value stored in the Destination increments up by one, then the S:FS bit DID INDEED go TRUE for one scan – regardless of whether you saw the instruction go "green" or not ...

note that if the ADD does NOT increment - then you probably don't have that section of the code set up to be scanned/executed by the processor ...

Also, if you want to have the CPU "re-initialize" aka start from first scan
How do you do that? I tried putting into program then back into run. Doesn't seem to work.

Click to expand...

actually - that should work ... try it again once you've got the "test" installed as detailed above ...

Thanks for the reply
I have already added the counter to test it.
Why do you say not a counter and use an ADD for debugging

How do you get the PLC to start from first scan again.

define not working please. Try latching it to see if it turns on.

isiah_s said:

define not working please. Try latching it to see if it turns on.

Click to expand...

Sorry, yes good pint

without boring you, the S:FS is a simple trigger to start an initialization routine on a conveyor.

What im really seeking here i think is how to get the PLC to start its first scan over.
I think from there i can figure out the debugging.

When you do a re-download does it start from first scan?

How can i force it to start from first scan again?

your S:FS bit will be on during the first scan after a program to run transition


rather than trying to restart the processor, why not use a bit or a routine to jump to whenever you need it?

I have already added the counter to test it.

Click to expand...

a CTU counter is the wrong tool for this test ...

Why do you say not a counter and use an ADD for debugging

Click to expand...

because a CTU counter has a CU (Count Up) bit – which is always SET to a value of ONE by the processor's PRE-SCAN operation ... that prevents it from incrementing on the "first pass" ...

Thanks team, i think i have found the issue

Please share what the problem and solution was so we can all benefit from your experience

I'm in no position to judge your process, but is it safe to let the PLC automatically turn on the conveyor using S:FS? For example, if you had a power outage, and power automatically comes back on, what if someone has there hand on the conveyor or someone was taking something off it?

Again, I don't know your process or what kind of conveyor you have or what parts you are working with, I just ask to satisfy my own curiosity.

alive15 said:

I'm in no position to judge your process, but is it safe to let the PLC automatically turn on the conveyor using S:FS? For example, if you had a power outage, and power automatically comes back on, what if someone has there hand on the conveyor or someone was taking something off it?

Again, I don't know your process or what kind of conveyor you have or what parts you are working with, I just ask to satisfy my own curiosity.

Click to expand...

No problem, curiosity is what makes great engineers right?

Have no fear
Its just a test bench for a conveyor that has to preform a centering calibration because its actually a type of shuttling conveyor.

Its only a miniature being tested in my office. The real one has about 40 safety interlocks that are not even part of the program but tied to Pilz's relays for pull cords, laser edge detection and safety curtains.

The S:FS just called a calibration routine if about 40 other things are good to go

This was just a test

V0N_hydro said:

Please share what the problem and solution was so we can all benefit from your experience

Click to expand...

Sorry, normally i try and reply when its relevant because you sir are 100% correct. This forum is great because we can all learn from each other.

In this case i did not reply because the issue was my own fault caused by a latch that was not working properly from an HMI button that was set to toggle instead instead of momentary.

The S:FS was working correctly after i found my other bug.

Really appreciate everyones input

You will never see S:FS go "green on the screen".


RSLogix5000/Studio5000 software doesn't animate it, nor does it animate any of the other 5 S:xx bits :- S:MINOR, S:Z, S:N, S:V, or S:C


If you want to physically "see" any of these bits, you can map them to internal BOOL tags using XIC & OTE. The software will animate those for you.