AlwaysFalseInput

*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 (y)

Sorry, I should've specified that this is the particular culprit I had in mind. I've been doing a lot of work on SLC systems over the past 2 years and misplaced data from write commands (which I strongly oppose in almost all circumstances, reads are so much safer and more traceable) is something that I've experienced a couple of times.

Thank you for the welcome Ron, and thank you for the many useful contributions you've made to this forum. You've helped me more than once.
 
Last edited:
When I was senior systems engineer at an integrators I totally banned the use of the AFI instruction.

Instead we had "engineer bits" assigned at the start of the project.

In Logix5000 therefore, we had a set of BOOL tags named with the engineer's initials.

In Logix500 we assigned the engineers initials as Symbols to Binary addresses.

In either case we always OTU'd the bits or tags at the start of the logic scan, so unless anyone toggled them manually they would always be false.

Company standards dictated that a software engineer use their own tags to "mark" areas of code that needed more work. XIC for "false", XIO for "true", whichever was appropriate.

As lead engineer I could easily cross-reference these bits to see what was incomplete, or needed verification, and the engineers themselves could use them as "reminders" where they had further work to do.

A project would not go to Customer Acceptance Testing with anything other than the initial OTU's present in the code - easily checked with a few cross-references.
 
When I was senior systems engineer at an integrators I totally banned the use of the AFI instruction.

Instead we had "engineer bits" assigned at the start of the project.
.....

Previous place I worked built a UDT for RSLogix5K/Studio5K containing..
Bools
DINTS
Reals
Timers
Counters

it was then done as your engineer bits bit also with a common prepend ATest. You could do a Crossref on ATest and pull up everyones logic that was in progress. This way you can create and test code without create numerous tags to handle all the jobs of the test code.. just use parts from your own named UDT.
 
Previous place I worked built a UDT for RSLogix5K/Studio5K containing..
Bools
DINTS
Reals
Timers
Counters

it was then done as your engineer bits bit also with a common prepend ATest. You could do a Crossref on ATest and pull up everyones logic that was in progress. This way you can create and test code without create numerous tags to handle all the jobs of the test code.. just use parts from your own named UDT.

Nice idea ! But can't see why a programmer would need his own Timers/Counters etc.


Guess they could have obscure uses ...
 
I've used timers and counters before for diagnostics. Quickly check if adding a 500ms delay to a sensor action will solve the problem; if so, hopefully have them move the sensor position so I don't need the timer permanently. And oftentimes I want to use a temporary DINT for a parameter that will eventually be hardcoded, so I can tweak it quickly without doing rung edits, to work out what that hardcoded value should be, and then hard code it when I'm done.

I like the idea of a diagnostic UDT. I might even implement that! Like daba says, the main thing is that whether you're using a UDT or a single bit, that it's named for the engineer responsible, so you can track them down if they leave diagnostic code in place.
 
Nice idea ! But can't see why a programmer would need his own Timers/Counters etc.


Guess they could have obscure uses ...

Trying to track occurences of faults over a day would be a good use for counters. Testing delays or if your writing new code to eventually add into the system just keeping it all under one overall UDT tag until proofed and ready. Then lay it into the normal programming tags for the client system.

you don't need 30 timers, just a few. same with counters. Enough to do some testing/diagnostics/etc.
 
If you place a rung like this at the bottom or end of the scan. B3:1 can be used as a pls bit maybe. It will act as a PLS only on for one cycle if forced then off at the end.
 
If you place a rung like this at the bottom or end of the scan. B3:1 can be used as a pls bit maybe. It will act as a PLS only on for one cycle if forced then off at the end.

?

As shown in the original post the rung does absolutely nothing. The OTU instruction will only be executed and turn the bit off if the rung as a whole is true, which can only happen if B3:1 is 1 when the XIC checks it and 0 when the XIO checks it (ie impossible).
 
Back
Top Bottom