Rslogix5

[Ron Beaufort]

Greetings Ben,



again, I apologize that I don’t really have time to dig into your question - so maybe I’m missing something ... but you said:

... so aside from the first scan that unsets CleanA if it's set ...

unless there’s more to the program than you posted above, then you shouldn’t really count on CleanA to be “unset” every time the processor starts up ... specifically, an ONS which is programmed “unconditionally” (the way you’ve shown it) will NOT “fire” and give you the expected pulse of “TRUE” logic at start up ... that means that if CleanA happens to be left “on” when the processor is shut down, then it will still be “on” when the processor starts back up ... oops! ... again, since you didn’t post ALL of your program,, then I might be missing something - but I just tried out your program in the lab to confirm my suspicions ... I’d bet more than pocket change that you’re in for a bit of a surprise the first time you try to restart the machine after leaving CleanA turned “on” ...



you might want to consider the approach shown below instead ... the circled addresses are the ones that I’ve changed from your original program ...

notice the use of the ControlLogix “Status:FirstScan” bit instead of the ONS ... I think that this will give the effect that you’re looking for at “startup” time ... let us know how things turn out ...

 

[Ron Beaufort]

I had a few extra minutes ... here are some specific answers to your specific questions ...

If I read the documentation right, an ONS instruction with nothing in front of it will always be true.

that is incorrect ... actually an ONS with nothing in front of it will always be FALSE ... if you get a chance, please tell us where you read that bit of misinformation ... marking down errors in the “books” is sort of a hobby of mine ...



possible cause for confusion: an ONS programmed the (unconditional) way that you’ve shown it will always be highlighted in green ... however, “green” does NOT mean “true” in the case of an ONS instruction ...

CleanA stays on for 150 seconds, and turns off the next time Timer.DN goes true. That makes me think the ONS path on the first rung is basically non-functional. Am I right?

yes, basically you are ... unless something else “off-screen” in your program is manipulating the ONS memory bit, then the logic in that particular “branch” will always be false ...

 

[bdjohns1]

that is incorrect ... actually an ONS with nothing in front of it will always be FALSE ... if you get a chance, please tell us where you read that bit of misinformation ... marking down errors in the “books” is sort of a hobby of mine ...

possible cause for confusion: an ONS programmed the (unconditional) way that you’ve shown it will always be highlighted in green ... however, “green” does NOT mean “true” in the case of an ONS instruction ...

I think that was part of my confusion, plus I think I mis-interpreted the docs in the A/B help files.

I actually don't need to worry at all if CleanA is set or not, because I discovered after some digging elsewhere that there's logic elsewhere that only allows CleanA being true to actually do anything in a specific portion of this subroutine. The programmer wrote our system to follow a sequence of steps - Clean_Step.1, Clean_Step.2, etc, defined as word/bit array, so you have something like this in the rungs which actually energizes the needed valves while in steps 3-11:

XIC Clean_step.3 XIO Clean_step.12 XIC CleanA OTE ValveA
XIC Clean_step.3 XIO Clean_step.12 XIO CleanA OTE ValveB

All of the Clean_step bits are unset in the first scan of MainProgram, and given the output logic, you will have either ValveA or ValveB open, so at worst, you start cleaning the wrong bank of equipment first (which makes absolutely zero difference), and you won't be deadheading. Even if it did deadhead, that wouldn't be harmful either, since the supply pump is a high flow/low pressure pump - it can supply 500 GPM, but even deadheaded, it won't do more than 35 psi, so it's not going to force open any valves. While the system fills, the pump actually does run already and deadheads into a stop valve, by design.

So, the whole ONS bit was really a bit of unneeded cruft. Sorry I can't post the whole subroutine - it'd be about 100 rungs, and the overall program is about 1500. At least the programmer assigned meaningful labels to everything instead of just saying O:1/10, but there are no comments.

Here's a separate newbie question since I haven't seen too much production code yet - is it common practice to include a separate subroutine that handles all of your actual outputs? (ie, the little bit of logic I've got in this post is from that subroutine) It seems kind of annyoing when you're looking at a sequence, see that you're in Production_step.15, and then have to do a cross-reference to see what step 15 actually does.

 

[burnerman]

Why would anyone want to program a one-shot as the first element of a rung anyway?

 

[Ken Moore]

is it common practice to include a separate subroutine that handles all of your actual outputs?

I don't know if it's common, but it is used alot.
There are advantages, by mapping your physical I/O to bits or bits of words, if you get a bad point, you only have to modify the code in one place.

When interfacing with a HMI or SCADA, it's more effecient to transfer contiguous blocks of memory, by using one word for a device, with specific bits assigned to specific functions, it can be easier to assign colors in the HMI, based upon the decimal value of the word, instead of bit mapping the entire word.

 

[Ron Beaufort]

to answer the question from burnerman ...

Why would anyone want to program a one-shot as the first element of a rung anyway?

the thought process usually goes something like this:

I need a certain operation to happen just ONCE whenever the processor first goes into the “Run” mode ... (example: an MOV to initialize a default value) ...

I’ll put an ONS as the first and only condition on the MOV rung ...

now whenever the processor first starts up, the rung will be true leading up to the ONS ... the processor will “fire” the ONS - and do the MOV just once ...

unfortunately that approach won’t work - for the “prescan” reasons I detailed above ...

with an Allen-Bradley PLC-5 or ControlLogix processor, the "unconditional" ONS simply won't fire ...

with a processor from the Allen-Bradley SLC-500 family, an "unconditional" OSR will fire ONCE - but ONLY once ... worst case scenario: Pete-the-SLC-Programmer uses the "unconditional" OSR approach and tests it out - but he only tests it once ... oops! ... from then on the OSR won't fire - and the intended "initialize" operation doesn't take place ...

final thought: using the processor's built-in "First Scan" bit is usually the way to go ...

 

[burnerman]

final thought: using the processor's built-in "First Scan" bit is usually the way to go ...

Yep, and if your plc doesn't have a first scan bit (are there any plcs without this nowadays?) it's easy enough to roll your own.

is it common practice to include a separate subroutine that handles all of your actual outputs? ...

I always prefer to do it this way and map real inputs to bits - I can then re-use the same chunks of logic from one project to another even if the I-O configuration is different.