The first scan bit, S2:1/15 in RsLogix 500

daba said:

drbitboy, I have highlighted in red above some statements that are inaccurate, and could be misleading.

The output bits in the output data-table do NOT get turned off while you are in program mode, they stay at their last value.

Data transfer to the output module(s) is halted, and it is the output modules themselves that turn the physical outputs off when the controller is not in a [RUN] mode. This is true for all PLC and SLC/Micrologix controllers.

However, Logix5000 series output modules are capable of being configured so that the outputs go off, hold last state, or come on when the controller is not in a [RUN] mode. Similarly if the output module loses communication with the controller. All of that configuration is per bit, not the whole module.

EDIT : You appear to be confused between Pre-Scan, and First-Scan.

Pre-Scan is NOT a routine you can program code for. It is an entirely automatic scan of the user code, prior to going into [RUN] mode, during which all Non-Retentive data is reset to default states. Bits referenced by OTE's are rest to zero, Timers (TON and TOF) are reset, File handling Instructions are reset, One-Shot storage bits are turned ON. Pre-Scan is triggered by the controller attempting to go into [RUN] mode, whether that is by a mode-change [PROG] to [RUN], or the controller re-starting after a power-down. During the Pre-Scan, no code is actually executed, it is just "scanned", and the resetting of non-retentive data takes place.

First-Scan is simply a status bit you can look at, and do anything you want with it. You could call a subroutine to "initialise" things. You could set an alarm bit so you know the controller has been re-started. Or you could use that bit to place all running sequences into a "Hold" state, nothing should re-start automatically, unless it is imperative to do so, an example may be forced ventilation fans for instance.

Click to expand...

Yes, Thanks.

but - there's (always) more to the story ...

(1) DISCLAIMER: this is being written entirely from memory – and since I no longer have the hardware to test it with, the reader should confirm these statements before trusting them ... this is just to further the current discussion – and ONLY Allen-Bradley brand products are being considered ... also – newer versions of the RSLogix software might have changed from the way that I remember ...

(2) suppose that you decide to put in a "Pre-Scan" sub-routine which contains an OTE for a particular bit address ... the intent is that whenever the PLC has a "Go-To-Run" event, the bit/box will be written to a status of ZERO ...

(3) suppose that to make SURE that your new "Pre-Scan" routine ONLY gets scanned at start-up, you intentionally do NOT include a JSR (Jump to Subroutine) instruction ANYWHERE within the rest of your code ...

(4) NOTE: I do NOT recommend this technique as a "good" programming practice ... this post (as I've already said) is written only for the purposes of furthering the discussion at hand ...

(5) suppose that you don't even program ANY other logic to control your "target" bit/box ... yes, you could write in a momentary Latch operation in your "regular" code – but to make sure that we're comparing "apples to apples" let's just manually enter a status of ONE into the bit/box for testing purposes ...

(6) since the OTE located in your "un-scanned" subroutine is NOT being scanned at all, you should be able to manually toggle the bit/box from ONE to ZERO repeatedly – and whichever status you enter should remain – even with the processor in the Run mode ...

(7) now to test the operation of your nifty little "Pre-Scan Reset" gimmick ... leave a status of ONE in the bit/box - and then switch the processor into the Run mode ... (if you're already in the Run mode – switch to Program mode and then BACK to Run) ...

(8) each time the processor has a "Go-To-Run" event, the status of the "hidden" OTE's bit/box should automatically be written to a status of ZERO ... that's the Allen-Bradley "Pre-Scan" operation at work ... you could also cycle power to the processor and get the same results ...

(9) so the nifty scheme works – right? ...

(10) well, maybe it does – maybe it doesn't ... here's the trick ...

(11) if your platform uses RSLogix-5 or RSLogix-500, then the Pre-Scan operation WILL find the "uncalled" subroutine and the OTE will indeed go write a status of ZERO into the bit/box ...

(12) but ...

(13) if your PLC platform happens to use RSLogix/Studio-5000 then you must include a JSR instruction SOMEWHERE in your "executed" code – even if the JSR rung is never allowed to be scanned as TRUE ...

(14) to sum up ...

(15) if your platform happens to use RSLogix-5 or RSLogix-500, then the Pre-Scan operation will scan an "uncalled" subroutine whenever the processor has a "Go-To-Run" event ...

(16) but – on the other hand ...

(17) with RSLogix/Studio-5000 software, then the Pre-Scan operation will NOT scan an "uncalled" subroutine - UNLESS there is some type of "hint" to tell the processor that there is a subroutine lurking around somewhere in the background ...

(18) the "big ticket" takeaway here is that not all PLC processors work the same – even though they might indeed have the same "Allen-Bradley" name stamped on them ...

(19) going further ...

(20) if I still had access to the equipment, I'd try similar experiments along these lines using a "guaranteed to be FALSE" rung with a FOR instruction to provide the "hint" ... and maybe even try putting the FALSE rung with a JSR instruction INSIDE the "uncalled" routine ... question: would Pre-Scan find it there? ...

(21) AGAIN – I do NOT recommend that these types of programming techniques ever be used in a real-world situation ... but ... my personal experience is that the more you know about the quirks and foibles of these little devices, then the better you become at understanding where unsuspected problems might creep into the systems that you (or other people) have developed ...

(22) be safe ... be well ...

There is no need to do any tricks, or hints, or have a subroutine lurking with perhaps hundreds of rungs in them, wasting processor memory.

Just write your code as you want it to behave.

It it's an internal memory bit for, say a recipe parameter enable or disable flag, or if it is a bit that says a particular event has occurred, then by all means use Output Latch (OTL) and Output Unlatch (OTU) instructions to remember these things, the Pre-Scan will leave those bits as they are....

If, however, you DON'T want to remember something, then use Output Energise (OTE) instructions, and let the Pre-Scan do its work on them.....

Dust, sackcloth and ashes

Thanks daba, yes: that was MY BAD.


The bit O:0/0 was retentive and did not get assigned to 0 during the switch to program mode, even though the external output relay did go off (I heard it click and saw it change on the LCD).


And yes, I should have stated that am experimenting in a very limited environment: RSLogix Micro Starter Lite (freebie); MicroLogix 1100; so the described behavior during pre-scan and of un-called program files is specific to my environment at least.



So YMMV.


I fully realized that my demo program was a canard, and not a recommended technique; it was my mistake to not specifically state that. My point was only that there are a lot of things that can affect what happens both to external discrete outputs (physical relay, in my case) and to the internal bits (O:n/m) assigned in the PLC program that drive those discrete outputs, but you and Ron have now expressed that much more clearly (at least as clearly as summat as muddled as this topic can be).


Btw, I do understand the difference between Pre-scan and the [First Pass] bit, and that [First Pass] is a bit indicating a particular scan's ordinal wrt a mode change; specifically, [First Pass] is not a scan itself. That said, I agree that I was lazy in the semantics - nothing is "processed" during pre-scan - which can only lead to confusion.


Thanks again, daba and Ron, for sorting this out so quickly.

Siemens Has things called organisation Blocks (OB), There are a number of them, from memory (that's not so good now) There are start up OB's these run before the main scan, some are interrupts, and of course OB1 which is the sort of task where programs are run from. As on the older S5 system, flags (M area) were non-retentive, often programmers would copy areas of flag memory at the end of scan (end of OB1) to a Data Block so in the event of a power down at least there would be a sort of retentive flags that would be restored upon re-start in OB21 (I think this was the pre-program scan block). I used this technique myself many times and although in theory, it may not get the status of all bits (assume power failed half way through scan) I never had any issues, It was probably intelligent enough & enough voltage level that it would finish scan before shutting down. Like Ron said there are many flavours in the different PLC's and to be honest, having used many types there is not enough time to sit & study all the possible functions or quirks they have. when your back is against the wall and you have to get a system designed & up & running you only spend time on the bits that are important.

drbitboy said:

Btw, I do understand the difference between Pre-scan and the [First Pass] bit, and that [First Pass] is a bit indicating a particular scan's ordinal wrt a mode change; specifically, [First Pass] is not a scan itself. That said, I agree that I was lazy in the semantics - nothing is "processed" during pre-scan - which can only lead to confusion.

Click to expand...

Not quite correct again - The [First Pass] bit is turned on for the first proper scan of the user code.

This immediately follows the Pre-Scan, which does NOT evaluate the code, it's just the hunter/killer of stuff to make the First Scan work properly ....

freeali said:

Dear drbitboy,

If I have a 100 Latch OTE, then I need to treated all of them in the PRESCN_ONLY Program file LAD3 , this is unreasonable !

Click to expand...

Oh dear. I am not suggesting this, no, not in the least!!!


I only put the un-called program file (LAD 3) in there to make the point that some versions of A-B PLCs will look at (not scan) them during pre-scan to decide how some bits will be set.

daba said:

Not quite correct again - The [First Pass] bit is turned on for the first proper scan of the user code.

This immediately follows the Pre-Scan, which does NOT evaluate the code, it's just the hunter/killer of stuff to make the First Scan work properly ....

Click to expand...

This is semantics, but I think considering "pre-scan" to be a scan in any form is misleading. My semantics in saying it is not a scan is, I hope, analogous to daba inferring it is not a proper scan.


The "pre-scan" is an activity (event? task? step?) that occurs before ("pre-") the first real (proper) scan.


That way, there is only one type of scan (not two e.g. proper scans and non-proper pre-scans), with a possible distinction to be made between any scans being whether the [First Pass] bit is 1 or 0, but even that is only state and does not change how the scan works.