AlwaysFalseInput

Forgive me but sometimes I like to peek at other peoples work to try to understand how they get things done.
I think I understand the purpose of an Always False Input, and why you may want to use it.
Why the two XIC and XIO in the front of this rung?
Why not just a straight rung and Unlatch the bit?

It is a legacy practice.
Back in the early days, many PLC's would not let you have an output instruction without and input on the rung also.

The rung does not do anything. It never solves true so the unlatch action never happens on the coil. The boolean algebra people know that X AND NOT X always evaluates to zero but that result is not written to the coil. In this case the rung does not shut off the bit.

AFI instructions can be used to mark a place in a program that is not complete and will require more work later. I've used a string of alternating NO and NC contacts for that same purpose.

Corsair said:

The rung does not do anything....

Click to expand...

Good point, that particular implementation is written incorrectly, Xeither

• the XIC and XIO on the left should be ORed, not ANDed,
• XOR
• the OTU should be changed to an OTE

If this were an SLC 500 controller then there is no AFI built-in. This COULD be an attempt at creating their own AFI to get the following functionality.

AFI---------- OTU

By putting these the XIC and XIO instructions before the OTU it can never energize. Maybe that is what they wanted. For testing/troubleshooting purposes maybe they want to verify operation without the OTU doing anything. This would solve that.

This is assuming that those instructions are only there temporarily.

OG

I have seen similar things many times & you wonder why, I think in many cases there is a valid reason, perhaps originally, it was meant to unlatch a bit but a temporary not (or an and) is put in to disable it, seen this both originally for a true or false, or latch/unlatch, found it was not required but either forgot about it or just did not bother to remove it, or as suggested, bad programming.

This is pretty old method for allways off.

Allways_off     allways_off             Allways_off



 -| |------------|/|----------------------( )

 

PLC can be programmed different ways, and still code is controlling same way bits and outputs.

Of course you can use

            Allways_off

-------------------(R)

The rung as it's programmed is dangerous IMO because you can simply toggle it on, and it will stay on.

If you really needed to make an "always off" bit, you do either:
...or, if you can't have an output instruction with no input instruction: But then again, I also have a pet hate for "Always_On" and "Always_Off" bits existing at all. In my mind, there's no good reason for them to exist in that specific form. So, you know, my opinion is somewhat jaded when it comes to always anything bits

ASF said:

But then again, I also have a pet hate for "Always_On" and "Always_Off" bits existing at all. In my mind, there's no good reason for them to exist in that specific form.

Click to expand...

Why? What should replace them?

Depends on the application. What are you using the AFI for in the first place? The question I would pose in every case is: if code is intended to be always disabled, why is the code still there?

Three immediate possibilities off the top of my head:

Maybe you have "generic" code and need to disable sections of code related to options that a specific machine doesn't have. Great, use a meaningful tag to describe that. "OptionFitted_Skyhook" or "OptionFitted_RetroEncabulator" or something. You can use logic like the above to make sure that the tag stays off if you must, but I rarely see the point. It's not going to turn on by itself. Sure, someone can toggle it on, but if they have that level of access already, they can just as easily delete the AFI bit altogether, or mess with the logic that causes it to be always off.

Maybe you're temporarily disabling code for testing purposes. Great! Use a tag with your initials on it, like ASF_Disabled, so that someone coming along later knows who disabled it and can ask me why. And so that when I'm done testing, I can find all of my ASF_Disabled bits with a simple cross reference and delete them, make sure I've cleaned up after myself, without having to search through 50 unrelated "always off" instructions that I've had nothing to do with.

Maybe the code really is redundant. In that case, just delete it. You can always save a before-and-after copy of the code in case you ever want to refer back to it. It makes much more sense to have the code archived in a file than sitting on a live PLC taking up space on the off chance someone wants to look at it some day.

Throw some other possibilities for why you might be using an always-false bit at me and I'll tell you why I don't like it. If you come up with a reason I can't argue against, I'll buy you a beer next time you're in Melbourne

ASF said:

It's not going to turn on by itself. Sure, someone can toggle it on, but if they have that level of access already, they can just as easily delete the AFI bit altogether, or mess with the logic that causes it to be always off.

Click to expand...

I worked with a machine builder where their machines were built and delivered like this. All software functions were present in the PLC code even if you bought the basic machine. The protection was Password protecting reads and writes to avoid the machine malfunction (some functions would interfere with the basic operation), but the added function HMI pages and tags weren't installed by default. So changing the PLC wouldn't do much for you as the HMI wouldn't allow you to configure, turn the functions on.

ASF said:

You can use logic like the above to make sure that the tag stays off if you must, but I rarely see the point. It's not going to turn on by itself. Sure, someone can toggle it on, but if they have that level of access already, they can just as easily delete the AFI bit altogether, or mess with the logic that causes it to be always off.

Click to expand...

The only reason I'd disagree with this point would be if the PLC formed part of a network and somebody added a write command from another PLC in which their data was misplaced or accidentally spilled into your register range and toggled your unconditioned "Always_Off" bit.

Hopefully this qualifies for a beer token, though cider is my beverage of choice.

along the lines of the idea behind the post from our new member MattUK ...

the basic idea is that regardless of how the "roll-your-own" bit/box is written to status of ZERO - there is no guarantee that the status will STAY at ZERO throughout the entire scan ...

usually this isn't a problem - but then again, usually you don't expect a train wreck to occur each time a train leaves the station ... it's those "once in awhile" situations that can cause lawyer-level problems ...

and welcome to the forum, Matt ...

.

MattUK said:

The only reason I'd disagree with this point would be if the PLC formed part of a network and somebody added a write command from another PLC in which their data was misplaced or accidentally spilled into your register range and toggled your unconditioned "Always_Off" bit.

Hopefully this qualifies for a beer token, though cider is my beverage of choice.

Click to expand...

I don't think that's even possible with an AB PLC, except in very specific circumstances.*

The only two ways (that I'm aware of) to write from one AB PLC to another are explicit messages, or produced consumed tags.

Produced/consumed tags would require me to set my tag up as a consumed tag, which is beyond the realm of common sanity. An explicit message can't write to a BOOL tag, so the only way this could happen is if you were using one bit of a DINT tag for your disabling bit. And if you need a whole DINT's worth of disabling bits, I have more questions for you.

Of course, there may be another type of PLC that can do some sort of socket-level messaging to my AB PLC, and theoretically, yes, someone could set up a HMI to write to my BOOL tag. But again, if someone has deep enough access to my PLC code that they can identify specific "always off" bits, and update the HMI to manipulate them, they can do far worse.

Spilling into my register range is also only a problem in the older SLC-style PLC's. All the new tag-based controllers don't have registers for you to accidentally overrun.

TL;DR, I feel like I've got a pretty compelling argument against that one, but there have been no other attempts. So if you make it to Melbourne before someone gets in with a better one, I'll buy you that cider. You've probably got a while to wait
*edit: on reflection, it is somewhat less unlikely in the older SLC-type PLC's, which in fairness the OP was originally referencing with their screenshot. All the more reason to migrate to the Logix platform

Ron Beaufort said:

along the lines of the idea behind the post from our new member MattUK ...

the basic idea is that regardless of how the "roll-your-own" bit/box is written to status of ZERO - there is no guarantee that the status will STAY at ZERO throughout the entire scan ...

usually this isn't a problem - but then again, usually you don't expect a train wreck to occur each time a train leaves the station ... it's those "once in awhile" situations that can cause lawyer-level problems ...

and welcome to the forum, Matt ...

.

Click to expand...

Another excellent point. Unless you're using a controller that supports the AFI instruction, you really can't generate a true always false instruction. The best you get is a "this bit is false as of the end of this rung and will remain so unless somebody messes it up later" bit.