RSLogix Bit Toggling At Startup

Aabeck

Member
Join Date
Feb 2013
Location
Detroit
Posts
1,860
I have used this Flip-Flop routine for years (see 1st picture) without incident, but noticed today while programming a flashing light sequence for my son's new Ghostbusters model car I put lights in, that the enabled bit shuts off every time the PLC is powered up or switched from Program to Run when it was on, and I think the bit should be retained & don't see how the One-Shot is getting activated. I even tried a XIO First-Scan so it wouldn't turn on the One-Shot at power-up, but it still shuts off.

I ended up adding a latched bit as shown in the 2nd picture to retain the proper state.

I noticed this on the Micrologix 1000 I was programming for my son, but I put the same ladder in a SLC5/04 & tested it & it shut off the bit on power-up also.

Am I missing something or is this normal?

Toggle1.jpg Toggle2.jpg
 
I'm not 100% sure that I'm following everything that you're reporting -

but -

whenever an Allen-Bradley processor has a "go to run" experience - each OTE instruction will go write a ZERO into its bit box ... this is a part of the PRE-SCAN operation ...

if you'll look at it that way it will probably start to make sense ...

NOTE: it's a little more complicated than that for a ControlLogix or CompactLogix system - but we'll skip that part since you're not working with either of those platforms ...
 
Last edited:
I'm not 100% sure that I'm following everything that you're reporting -

but -

whenever an Allen-Bradley processor has a "go to run" experience - each OTE instruction will go write a ZERO into its bit box ... this is a part of the PRE-SCAN operation ...

NOTE: it's a little more complicated than that for a ControlLogix or CompactLogix system - but we'll skip that part since you're not working with either of those platforms ...

So glad you corrected your original reply, Ron - I was halfway though correcting it for you when I noticed the edit.....
 
whenever an Allen-Bradley processor has a "go to run" experience - each OTE instruction will go write a ZERO into its bit box ... this is a part of the PRE-SCAN operation ...

Thanks, that explains it. I was thinking the bit status should be retained like bits set but not controlled by OTE's. But then shouldn't the 2nd ladder write a zero even if the latched bit is on - which it doesn't, it retains the state.

As for the ControlLogix, I do work on those too so could you explain the more complicated?
 
Thanks, that explains it. I was thinking the bit status should be retained like bits set but not controlled by OTE's. But then shouldn't the 2nd ladder write a zero even if the latched bit is on - which it doesn't, it retains the state.

As for the ControlLogix, I do work on those too so could you explain the more complicated?

The pre-scan does not change the state of any bits referenced by OTL/OTU instructions, only OTE.

I don't believe it is any different in Control/CompactLogix - the pre-scan simply resets any data-bits that are referenced by OTE instructions, and sets the storage bits for ONS instructions. I'm sure Ron will enlighten us if there are differences.

And just to make it clear, there is no such thing as a "latched bit". All processor memory is retentive by design, and bit locations are just written to 1 or 0 depending on the rung logic continuity as each instruction is scanned. The only thing that can turn a bit off is the pre-scan - or rung that evaluates as "false".
 
Last edited:
So glad you corrected your original reply, Ron - I was halfway though correcting it for you when I noticed the edit.....

thanks ... good to know that someone has my back ... I'm working on putting together a little "dog and pony" show for Safety I/O in my "home" lab – and I don't multitask too well when I'm this tired ...

As for the ControlLogix, I do work on those too so could you explain the more complicated?

I may have to correct this in the morning – but here's the general idea ...

first let's start with an SLC or MicroLogix system ...

suppose that you're using a LATCH (OTL) instruction – and an UNLATCH (OTU) instruction – and that both rungs are FALSE ...

suppose that the bit/box has a status of ONE when you shut down the system ...

when the system powers back up again (go to run) the bit/box should still have a ONE status ... it "retains" its status is how this operation is usually described ...

but suppose that you add another rung – even an UNconditional rung – with an OTE instruction for the same bit address – and that you place this rung in an UNUSED subroutine ... specifically, the subroutine has NO way to be executed ... no JSR – no STI – no DII – no "NUTHIN" to tell the processor to scan/execute the OTE rung ...

(some programmers create a "scrap pile" subroutine – and "park" unused rungs in it – just in case they might need them later) ...

now when you power down – and back up – or go to program mode and then back to run mode (go to run) – the LATCH bit will NOT retain its ON status ... specifically, PRE-SCAN will find that "UNUSED" (orphan) OTE instruction – and go write a ZERO into the bit/box ... in other words, the LATCHED bit "won't hold" its ONE status ...

now for a ControlLogix or CompactLogix system ...

suppose that we set up the same test as before ...

now when you power down – and back up – or go to program mode and then back to run mode (go to run) – the LATCH bit WILL retain its ON status ... specifically, PRE-SCAN operation will NOT find and execute that "UNUSED" subroutine ... in this case, the LATCHED bit "will hold" its ONE status (at go to run) ...

that's the basic difference that I was referring to earlier ...

now add a JSR rung to "call" the unused subroutines in each of the systems – and make both of the JSR rungs FALSE ... for example: use an AFI instruction for the Control/CompactLogix JSR rung – and maybe use just an XIC left in a ZERO status for the SLC/MicroLogix JSR rung ...

if my memory serves correctly – the LATCHED bit/box in the Control/CompactLogix system will now be reset to OFF – just like the SLC/MicroLogix ...

basic idea (again from memory) the Control/CompactLogix platform must have some "WAY" – some "PATH" – in order to find and scan the unused subroutine on PRE-SCAN – EVEN IF THAT PATH IS GUARANTEED TO BE FALSE ... the SLC/MicroLogix platform doesn't need any sort of path ... PRE-SCAN will go find that orphaned OTE instruction regardless ...

DISCLAIMER: I'm doing this by memory – and don't have time to double-check it – but I'd bet more than pocket change that I've got it right ...

closing out – this type of thing is one reason why I personally don't refer to "seal-in" rung constructions as "latched" rungs ... many people do that – but there is a BIG difference between how actual LATCHED/UNLATCHED rungs operate – and how "SEALED-IN" rungs operate ...
 
Last edited:
thanks ... good to know that someone has my back ... I'm working on putting together a little "dog and pony" show for Safety I/O in my "home" lab – and I don't multitask too well when I'm this tired ...



I may have to correct this in the morning – but here's the general idea ...

first let's start with an SLC or MicroLogix system ...

suppose that you're using a LATCH (OTL) instruction – and an UNLATCH (OTU) instruction – and that both rungs are FALSE ...

suppose that the bit/box has a status of ONE when you shut down the system ...

when the system powers back up again (go to run) the bit/box should still have a ONE status ... it "retains" its status is how this operation is usually described ...

but suppose that you add another rung – even an UNconditional rung – with an OTE instruction for the same bit address – and that you place this rung in an UNUSED subroutine ... specifically, the subroutine has NO way to be executed ... no JSR – no STI – no DII – no "NUTHIN" to tell the processor to scan/execute the OTE rung ...

(some programmers create a "scrap pile" subroutine – and "park" unused rungs in it – just in case they might need them later) ...

now when you power down – and back up – or go to program mode and then back to run mode (go to run) – the LATCH bit will NOT retain its ON status ... specifically, PRE-SCAN will find that "UNUSED" OTE instruction – and go write a ZERO into the bit/box ...

now for a ControlLogix or CompactLogix system ...

suppose that we set up the same test as before ...

now when you power down – and back up – or go to program mode and then back to run mode (go to run) – the LATCH bit WILL retain its ON status ... specifically, PRE-SCAN operation will NOT find and execute that "UNUSED" subroutine ...

now add a JSR rung to "call" the unused subroutines in each of the systems – and make both of the JSR rungs FALSE ... for example: use an AFI instruction for the Control/CompactLogix JSR rung – and maybe use just an XIC left in a ZERO status for the SLC/MicroLogix JSR rung ...

if my memory serves correctly – the LATCHED bit/box in the Control/CompactLogix system will now be reset to OFF – just like the SLC/MicroLogix ...

basic idea (again from memory) the Control/CompactLogix platform must have "someway" – some "PATH" - to find and scan the subroutine on PRE-SCAN – EVEN IF THAT PATH IS GUARANTEED TO BE FALSE ...

DISCLAIMER: I'm dong this by memory – and don't have time to double-check it – but I'd bet more than pocket change that I've got it right ...

closing out – this type of thing is why I personally don't refer to "seal-in" rung constructions as "latched" rungs ... many people do that – but there is a BIG difference between how actual LATCHED/UNLATCHED rungs operate – and how "SEALED-IN" rungs operate ...


Wow ! that's a gotcha for sure - I must test this asap - great heads-up, Ron..
 
I don't believe it is any different in Control/CompactLogix - the pre-scan simply resets any data-bits that are referenced by OTE instructions, and sets the storage bits for ONS instructions.

I think that you'll find that the Control/CompactLogix platforms (and the PLC-5) will indeed write a status of ONE into the bit/boxes for ONS instructions during the PRE-SCAN operation (go to run) ...

but ...

I also think that you'll find that the SLC/MicroLogix platforms will NOT affect the status of any OSR or ONS status bits during the PRE-SCAN operation ... specifically – those OSR and ONS instructions are simply ignored during PRE-SCAN ...
 
That was an interesting read Ron, thanks for that. Two things, first of all, in your signature, the output will simply always be on right, based on the way the PLC reads rungs. Second: My instructor is always complaining that our local school won't send him to your bootcamp. You are his hero :D.
 

Similar Topics

Hello, Haven't been on in a while. I need to generate a bit level pdf of the I/O for RSLogix 500. I can generate a report but it just shows the...
Replies
1
Views
113
Hi, I'm just looking for a simple way to make a button in excel (via VBA I presume) to toggle a bit in RSLogix 5000. I just got FactoyTalkLinx...
Replies
9
Views
488
If any of you wizards can help in this I would be ever more grateful. We have this device that generates 9 second pulses coming into a DI module...
Replies
31
Views
3,457
Hi, I am using the DN bit to stop the timer. However the DN bit doesnt change state. Please see the attached image. Any help is appreciated.
Replies
14
Views
2,766
How can I achieve the same functionality in Studio 5000? Image 001.png for the old RSLogix500 program Image 002.png for conversion to Studio...
Replies
6
Views
2,480
Back
Top Bottom