Unlatching tags for state transitions in Studio 5000.

Hello again, everyone.

Could anyone help me understand the best way to handle state transitions in ladder logic programs with Studio 5000? I currently have a system where I manage a NextState -> CurrentState mov instruction at the top of some of my routines. When a state is finished I move the value of the next state to the NextState tags and then on the next go around the machine moves along well.

The thing I have difficulty with is that I get to a routine by using a "StartRoutineX" tag. At the end of the last part of the routine I unlatch the "StartRoutineX" tag. At this point the routine I am in is no longer connected because the "NextState" variable for that routine has wrapped around to zero. However, it is as if the unlatching instruction continues to execute even when the subroutine it is inside is disconnected from the rest of the system control flow.

I guess this is the real issue of my confusion - I don't understand why latching instructions in a subroutine continue to hold even after I have returned from the subroutine.

Sorry if that is a little too confusing. Hopefully there is a simple answer to this that someone already has typed up somewhere else!

based on what you've told us so far - it sounds like you are confusing the INSTRUCTIONS (located in the ladder logic code) - with the BIT/BOXES (located in the processor's memory) ...

this is an EXTREMELY common misconception ...

in a nutshell:

when a LATCH instruction (OTL) is executed with TRUE logic, it causes the processor to "go write a ONE" into the associated BIT/BOX ...

then once that BIT/BOX has a status of ONE, it requires something (usually an UNLATCH instruction) to "go write a ZERO" in order for the status of the BIT/BOX to change ... (but note that ANY instruction capable of writing a ZERO will suffice - specifically, it does NOT require an UNLATCH) ...

you can see this covered in detail in the series of eleven videos that I've posted to YouTube ... (the LATCH/UNLATCH instructions are covered near the end - but you really need to watch the whole series in number order for the best results) ...

and if none of this helps, then I apologize - I've simply misunderstood your question ...

Hi Ron, thanks for the reply. I've seen some of your instructional videos - they've been very helpful.

I think I understand that fact fairly well. Specifically, my problem is that the last thing I do on my way "out" of a set of subroutines is unset the bit that pulled me into the subroutines in the first place. That way at the top level routine the PLC doesn't instantly jump back into the routine I just left.

The problem is that I unlatch the bit on the way out but its as if that instruction continues to hold the bit down even after I have returned from the subroutine. I try to toggle the bit manually from Studio 5000 back at the entrance but it stays low no matter what I do.

I'll keep looking at my logic and see if I have a destructive logic flow or something somewhere. I'm sure ultimately my problem is related to the distinction you made, I'm just not sure how deeply embedded it is at this time...

I try to toggle the bit manually from Studio 5000 back at the entrance but it stays low no matter what I do.

Click to expand...

just guessing here - but I'd bet (pocket change only) that you ARE indeed manually toggling the BIT/BOX back to a ONE status ... BUT ... before you can see the "green on the screen" results, the ladder logic is using the UNLATCH instruction to quickly write a ZERO back into the BIT/BOX ...

again - that's just a GUESS ...

if this doesn't help, you might consider attaching your ENTIRE project file (ACD extension) to the forum ... we'll be happy to take a look at it for you ...

Consider putting a simple counter rung inside your subroutine to see if it is being repeatedly called when you think it is idle (eg. ADD subctr, 1, subctr).

I think you're right Ron. That's the only thing that makes sense in the context, as these are the only two locations in the program that reference this specific bit.

Here's a bigger question you might have the answer to that could help me refactor this project:

If everything to the left of a Jump to Subroutine instruction is False/Disconnected/Whatever can the subroutine referenced in the Jump instruction still have any impact on the state of the device such as these Latch/Unlatch instructions?

My confusion comes from that fact that to my untrained eye the JSR instruction leading to my latch should be "disconnected" because the logic to the left of it on the rung is false.

I may post the project or a similar reduced example soon. I just have to be careful about what I show and talk about... You know how it is.

Thanks for your tips, time, and patience.

If everything to the left of a Jump to Subroutine instruction is False/Disconnected/Whatever can the subroutine referenced in the Jump instruction still have any impact on the state of the device such as these Latch/Unlatch instructions?

Click to expand...

first of all – you're saying "JUMP" (JMP) instruction sometimes – but "JUMP TO SUBROUTINE" (JSR) in another ...

JMP and JSR would get you different answers – but anyway – I'll ASSUME that you only meant JSR and move on ...

you've asked a pretty deep question ...

at the first level – the answer is simply "no" ... since the code/logic located inside the subroutine will not be executed by the processor ... so ... that code might as well be lying out in the parking lot for all we care ...

BUT - you said: "ANY impact" ... so now for the next level answer ...

yes - the logic inside the subroutine can be executed during PRE-SCAN – which (normally) occurs only once – whenever the processor has a "GO TO RUN" situation ... during the PRE-SCAN operation the instructions within the subroutine will be executed with "special" PRE-SCAN rules ... (note that you can usually find these PRE-SCAN rules in the Instruction Help file by clicking F1 while your cursor is on an instruction) ...

going further ...

suppose that you have an OTE instruction located in an "unused" subroutine – whose JSR instruction has FALSE conditions in its ladder rung ...

whenever the processor has a "GO TO RUN" situation, that OTE instruction WILL INDEED "go write a ZERO" into its associated BIT/BOX ... even if the logic leading up to the OTE instruction happens to be TRUE ...

now - going even further ...

suppose that you have an "unused" subroutine – which has NO instruction such as a JSR or a FOR which MIGHT possibly tell the processor to ever scan the subroutine ... specifically, we don't have ANY logic (even FALSE logic) to tell the processor that it could ever scan the subroutine at all ...

in this case, the PRE-SCAN operation would NOT execute an OTE at all ... note that this is a subtle difference between the ControlLogix/CompactLogix platform – and other Allen-Bradley platforms such as the PLC-5 and SLC-500 systems ... it's extremely rare for this difference to affect anything – but once in awhile, a program which has run successfully for years in a PLC-5 or SLC-500 system will have a slight (but sometimes "exciting") difference in operation when the project is converted over to a new ControlLogix/CompactLogix platform ...

Ron Beaufort said:

...in a nutshell:

when a LATCH instruction (OTL) is executed with TRUE logic, it causes the processor to "go write a ONE" into the associated BIT/BOX ...

Click to expand...

Ron,

I'm confused?...

Is it a "nutshell" or a "BIT/BOX"?

(Sorry - heading home - couldn't help myself!)

I am reading with interest though...

G.

Greetings George ... I was actually thinking of how you (personally) would enjoy experimenting with this PRE-SCAN idea - particularly the subtle differences between the various platforms ...

Ron, thanks again for that brilliant explanation. I think I understand now how I can change some of my rungs to better facilitate the way JSR is intended to work. That's a great help.

I found the source of my problem. It was rather mundane, all things considered. A counter was referenced in my initialization section, causing the whole subroutine to wrap around on itself in a single pass when reentered. Therefore it was like you said - the output unlatch came around faster than it went to green.

I appreciate your help and guidance. I'll be sure to keep this in mind and watch the last few of your tutorials when I get a chance to make sure I'm up to speed as I wrap up this project I'm on.

I would say that I'd love to come to one of your boot camps but truth be told I don't think ladder logic is for me. I'm much more of a "traditional" programming kind of guy. I keep a copy of the C Programming book by K&R by my bedside at night.