The bagger came back with 0.0 in every recipe setpoint at 06:10, with nobody at the HMI and no download on the log. The only change on that shift was a program that had been inhibited while somebody edited it and then put back in, and the initialisation rung inside it — one XIC on S:FS driving a block of MOV instructions — did exactly what it was written to do. S:FS is one scan of one program. It is not one scan of the controller, and it comes back at moments that have nothing to do with a power cycle.
Short version: the controller sets the first scan flag on the first normal scan after prescan, on the first scan of a program after that program is uninhibited, and on each first scan of an SFC step. Anything you hang on it will run again on every one of those, so it belongs on data that must be reset and nowhere near data an operator owns.
Examples below are a 1756-L83E on v33 in Studio 5000 Logix Designer, and the behaviour is the same on a 5380.
What the controller does before S:FS is ever true
Prescan happens first, and most of what people credit to the first scan bit is actually prescan doing its job.
On the transition to Run mode the controller prescans the logic to initialise instructions: it resets all state-based instructions, so OTE outputs clear and timers reset, and instructions with their own prescan behaviour do it here — the ONS storage bit, for instance, is turned off so the first real scan cannot produce a false edge. Input values are not current during prescan and outputs are not written. What happens to your data depends on the language, and the table in the Design Considerations manual is worth pinning up: ladder and function block reset non-retentive I/O and internal values, function block additionally clears the EnableIn parameter of every block, sequential function chart resets bit tags and forces numeric tags to zero, and structured text follows the assignment operator you chose — a bracketed [:=] forces the value to be reset during prescan while a plain := leaves the tag in its last state. Embedded structured text follows the same rule.
The difference that matters: the controller does not execute logic during prescan. It executes logic during first scan.
Prescan touches instruction state. The first scan is where your own initialisation logic finally runs, one scan later.
The three ways the flag gets set
The reference manual lists them, and only the first one matches what most people picture.
S:FS is set for one scan during the first scan that follows prescan, which is the run-mode transition everybody has in mind. It is also set during the first scan of a program when that program has been uninhibited — a per-program event that can happen in the middle of a running machine while every other program carries on scanning. And it is set each time a step is first scanned in a sequential function chart, when step.FS is set; the general instructions reference adds the detail that you can only observe S:FS in logic contained in actions that execute during the first scan of their parent step, with the N, L, P and P1 qualifiers. The wording in the status flag table is equally precise about scope: the flag tells you this is the first normal scan of the routines in the current program.
Per program, not per controller. That single word is the whole of the 06:10 problem above.
Three rows set the bit. The rows underneath are the ones people believe set it, and the machine behaviour that follows from believing it.
It is not a tag, and the manual that documents it moved
You will not find S:FS in the tag browser, and that is intentional.
The general instructions reference groups the first scan flag with the math status flags — S:N, S:Z, S:V, S:C and S:MINOR — and states that those flags are not tags and that flag aliases are not applicable, so there is nothing to alias, nothing to map into a UDT and nothing to produce to another controller. You reference it directly, as an XIC on S:FS in ladder or as IF S:FS THEN in structured text, which is how the manual’s own COP example seeds the first element of an array and copies it across the rest. Finding the chapter is its own small nuisance: the flag table lives in the General Instructions reference, the literature link built on 1756-rm003 now redirects to publication 1756-RM018A-EN-P, and the section is Common Attributes for General Instructions rather than anything with “first scan” in the title. On an SLC 500 the same idea is a real addressable bit, S:1/15, the first pass bit, which is part of why people expect S:FS to behave like a tag.
What the bit is properly for
Initialisation of things that must not survive a stop, and very little else.
The honest list is short: presets and lengths that are not constants, a block of MOV instructions that puts a state machine into a defined rest state, clearing accumulated counts that would be meaningless after a restart, arming a MSG instruction once, seeding an array from an initialised first element with a COP, and putting a control loop into manual with a defined output before it ever executes. The GuardLogix safety reference gives the sharpest example of the category, because on a safety controller it is a requirement rather than a convenience: only safety tags configured as constant value tags are captured as part of the safety signature, so any non-constant safety tag used in a safety-critical operation has to be initialised before Run mode. Pseudo-operands are the trap it names — the .PRE of a TON, TOF, RTO, CTD or CTU and the .LEN of a FAL or FSC are initialised only once, when the application is downloaded, unless the application itself changes them. The two sanctioned methods are a first scan subroutine or an Add-On Instruction prescan routine, and the manual’s own pattern copies the live values into a backup structure once, then restores them from that structure on each subsequent transition to Run.
Initialise what the machine must not remember. Leave alone what it must.
What it must never do
Four jobs, and every one of them is in somebody’s program right now.
It must never reset, unlatch or enable anything safety-related. A latched safe state exists so that a person has to act to clear it, and a program uninhibit or a mode transition is not a person; use a rising edge from a real reset device instead. It must never write defaults over values an operator or a recipe system owns, which is the failure this article opened with, and the fix is not a cleverer rung — it is to write those defaults once, at commissioning, into retentive tags, and to let a deliberate “load defaults” command do the job afterwards. It must never home a state machine that is holding real product: a sequencer forced to step 0 on the first scan starts the sequence with parts still in the machine, which is the same shape as the position 0 trap that catches people with SQO. And it must never be used as a power-up detector. A power cycle sets the flag only because the controller transitions to Run afterwards, the same transition you get from a keyswitch or a download with no power interruption at all, and a single program can see S:FS twice in an afternoon while the rest of the machine has been running for a week.
There is one more that is specific to GuardLogix and worth stating plainly: safety-critical Add-On Instruction tag values must be initialised in the Add-On Instruction’s prescan logic, not in a first scan rung outside it.
A rung on S:FS runs at the worst possible moment about once a year. Write it as though that is certain.
Same instruction, same bit, two completely different risk profiles. The right-hand rung passes every test on a bench and fails on the day a program is uninhibited.
The dead end: hunting for a controller-wide first scan
The usual next move is to go looking for a GSV that reports the controller’s own first scan, and there is not one to find.
What people build instead is a “system ready” latch: one program owns a retentive BOOL, sets it on its own S:FS, and every other program reads that instead of its own flag. That works, as long as everyone remembers the latch itself is retentive and that inhibiting the owning program re-arms it. The other common workaround is to gate the initialisation with a timer so nothing writes for the first few seconds, which hides the symptom on a bench and changes nothing about the cause. If the goal is to know that the controller has restarted rather than that a program has, the honest source is the controller’s own status — a fault routine and the wall clock — rather than a scan flag. The controller fault routine write-up covers the structure that does hold controller-scope information, and the one-shot instructions article covers the edge detection people reach for when they find S:FS will not do what they wanted.
Nothing about first scan is a substitute for storing what the machine needs to resume.
Next step
Put S:FS on a watch and find out how often it is really true on your machine.
Add a retentive DINT, increment it on every S:FS in each program, and leave it for a fortnight; the watch window will show you counts that do not match the number of times the line was powered down, and each extra count is a program that was inhibited and restored while the machine ran. Then read every rung conditioned on that bit and ask what it would do at 14:30 on a Tuesday with product in the machine. If the answer is anything other than “nothing a person would notice”, that rung belongs somewhere else — and if scan behaviour generally is what you are chasing, scan time and cycle time is the next thing to measure, along with the sequencer position trap if a SQO is what the first scan rung is resetting.