Duplicate Destructive bits used EVERYWHERE!

That logic is from a company called ESE. The whole program is SUPER neat but its nearly impossible for me read. Everything is a UDT sometimes nested 5 levels deep, I can hardly make changes to it and feel confident about what I'm doing.
 
More likely: the Roaster has two separate states Enabled and Disabled; they are (theoretically!)'related' to each other but not logically interlocked (there is no reference to the other state in each's command logic) hence the need of a 'Push-ON/Push-OFF' same operator sequence for each state's control.

Or at least that's what I am reading...:D

I can look quick if you really curious :)
 
It's fine...It's a bit 'unusual' to say the least, however, it seems that it was the developer's choice to implement it as such...:D

I took a look, this is super odd to me.

on one page there is the roaster05.enablePB that has 2 states
0 - Enable Roaster 5
1 - Roaster 5 Enabled
value = Roaster05.Enabled

Another Page has Roaster05.DisablePB that has 2 states
0 = Disable Roaster Hopper 05
1 = Roaster Hopper 05 Disabled
Value = Roaster05.Disabled

These as far as I can tell Roaster.Disable and Roaster.Enable are not interlocked in any way and the only thing that synchronizes them is a first scan bit will unlatch the enable and latch the disable..


In the logic, if the enable bit = 1, it starts the roaster drum

if the disable bit = 0, then everything else for the roaster can run, but they are not interlocked. Maybe I should hook up to this system and see what the buttons actually do in the logic...
 
Actually, what they did is they used "roaster.enable"to control the roaster itself, and then "roaster.disable" is controlling the filling of the hopper above the roaster. but that's a pretty dumb way to do it if you ask me
 
Actually, what they did is they used "roaster.enable"to control the roaster itself, and then "roaster.disable" is controlling the filling of the hopper above the roaster. but that's a pretty dumb way to do it if you ask me

A programmer who doesn't know or understand the machine/process he's programming??!!...:eek:...What new!...:D
 
Totally absurd piece of code - way overkill !

It's just a flip-flop....

That logic is from a company called ESE.

You are bringing back memories. They have very good engineers and if you have a question of how something is working why not call and ask?

It's a bit confusing because of the second rung of logic, you would think that the single ".enabled" bit on the first rung would be enough to determine the state of "enabled" (.enabled = true) or "disabled" (.enabled = false). The second rung controlling the ".disabled" bit makes you wonder as it seams to be redundant.

At the same time, given the descriptions this was a system that has been upgraded, and who's to say some design tweaks had to be made to maintain some functionality for compatibility reasons.

EDIT: Missed this post
Actually, what they did is they used "roaster.enable"to control the roaster itself, and then "roaster.disable" is controlling the filling of the hopper above the roaster. but that's a pretty dumb way to do it if you ask me

So flip-flop to enable/disable two separate pieces of equipment, but not really because they are related. Probably should have used a better tag name, but my previous comment of "tweaks to maintain compatibly" still stand. Possibly a green engineer was modifying code did copy/paste to get the functionality to disable the hopper without creating a new tag specific to the hopper.
 
Last edited:
To add, "Duplicate Destructive Bit" errors are really only an issue if it's an OTE. Generally speaking, you'd avoid them for one-shots too, but in this case it's required to achieve the flip-flop operation.
 
Sparkyman1 - If the code is working - leave it alone....

Spend your time understanding what the code is controlling, and updating the tag comments as you find.

You mentioned two specific things from different "pages" (i assume you mean HMI screens) - Roaster05 and Roaster05 Hopper, perhaps the documentation should reflect these pieces of equipment better, then the code might just make more sense.

If, and its a big IF, Roaster05.Enabled and Roaster05.Disabled refer to two different pieces of equipment or functions, then update the documentation to suit what you find - updating documentation is not going to stop the process working.

When, and only when, you are fully understanding the functionality of the system, is the time to start changing code if it has "issues".

At first glance, it appeared to many (including me) that "Enabled" and "Disabled" referred to the same thing, which made the code look wrong, but it appears now that they may be referring to different functions...
 
The line between genius and bat-***** insane is a thin one, and I'm not sure which side of the line this technique sits on. One half of me goes "oh my god, that's not how you do things! Why would you abuse ladder logic like that!", and the other half of me goes "actually, that's quite a clever way of doing it, even if it IS unconventional".

To take just the first rung, and ignore all questions about why your enable/disable states are not directly related to each other:
haha.png

If the operator presses the HMI "enable" button, the first thing that will happen is that the button will be unlatched, or "turned off", but the HMI. This is good practice for a number of reasons, which you can find me raving about in plenty of other threads if you actually care.
If the roaster at this stage is NOT enabled, then three things will happen upon execution of the first branch:
1. The BOOL tag Roaster05.Enabled is false, so the XIO sets it's rung-out condition to true
2. The rung-in condition to the ONS is true, and it's memory bit (BOOL tag Roaster05.ONS.0) is 0. The ONS instruction examines its rung-in condition, and its memory tag. If the rung-in condition is TRUE, and the memory tag is FALSE, it will set it's rung-out condition to TRUE and it's memory bit to 1. In all other cases, the rung-out condition is FALSE. So in this instance, the ONS instruction will set its rung-out condition to TRUE, and it's memory bit to 1
3. The OTL instruction will set the BOOL tag Roaster05.Enabled to 1, since the rung-out condition from the ONS was TRUE

Now, the PLC will execute the second branch...
1. The BOOL tag Roaster05.Enabled now has a value of 1 (set by the OTL on the previous branch, so the XIC instruction will set its rung-out condition to TRUE
2. Roaster05.ONS.0 was set to 1 by the ONS on the previous branch. This means that, although the rung-in condition to the ONS is true, the memory bit is already a 1. So in this case, the ONS instruction will set it's rung out condition to FALSE.
3. The rung-in condition to the OTU is false, so the OTU will do nothing

Hey presto, you have toggled your bit from OFF to ON!

Now, let's imagine the scenario if the roaster IS enabled when the button is pressed.

First Branch:
1. Roaster is enabled, so the XIO instruction sets its rung-out condition to FALSE
2. Rung-In condition to the ONS is false, so it sets it's memory bit (Roaster05.ONS.0) to zero (even though it probably was already) and it's rung-out condition to false
3. Rung-in condition to the OTL is false, so it does nothing

Second branch
1. Roaster is enabled, so the XIC instruction sets its rung-out condition to true
2. Rung-in condition to the ONS is true, and the previous branch set its memory bit to 0, so the ONS sets its memory bit to 1 and it's rung-out condition to true
3. Rung-in condition to the OTU is true, so the OTU sets the Roaster05.Enabled BOOL to zero

Hey presto, you have toggled your bit from ON to OFF!

This is one of the reasons I prefer AB over Siemens. A Siemens PLC would take one look at this logic and tell you four different ways to f*** off (at least three of them in German). But in AB world, you can do things like this - it's absolutely not how the instruction was intended to be used, but as we can see above, it works perfectly, and in reality, it's actually quite simple and efficient.

The only question that remains is "given the target audience of this code, is doing a trick like this a good idea?"

But that is a whole 'nother discussion that I don't think we need to have again ;)
 
The line between genius and bat-***** insane is a thin one, and I'm not sure which side of the line this technique sits on. One half of me goes "oh my god, that's not how you do things! Why would you abuse ladder logic like that!", and the other half of me goes "actually, that's quite a clever way of doing it, even if it IS unconventional".

Great explanation of how the rung will toggle a bit, and that is what I have observed it doing, but it doesn't answer the question of why an HMI "Enable" button should be toggling an "Enabled" state, and why an HMI "Disable" button should be toggling a "Disabled" state.

I'm now convinced that "Enabled" and "Disabled" refer to two different but related functions, especially since Sparkyman's post where a "roaster hopper" was introduced into the discussion.

I'm surmising (some might call it guessing), that Roaster05.Enabled is the control bit for the overall Roaster operation, and Roaster05.Disabled is the control bit for the Roaster's feed hopper. To me, that's the only way this logic makes sense....

Sparkyman1 needs to do some digging to see what is controlled by these two bits, and report back.
 
I prefer separate ON and OFF buttons on HMIs.


ON OFF STATUS
-][ ----------]/[--------------( )
| STATUS |
|--][-----|



Advantages:
Easier to follow the code.
AB will automatically turn the bit off on power up.
Each button only performs one function.
Doesn't rely on feedback to operator. "I was trying to turn off the equipment, but it was already off, so I turned it on."

Disadvantages:
Takes up twice the space on the HMI.

In this case, there would be 4 buttons, Enable ON, Enable OFF, Disabled ON, Disabled OFF. I would also change the tag to be "Roaster5.infeedDisable".

Also, I would put some rung comments in.
 
I prefer separate ON and OFF buttons on HMIs.


ON OFF STATUS
-][ ----------]/[--------------( )
| STATUS |
|--][-----|



Advantages:
Easier to follow the code.
AB will automatically turn the bit off on power up.

I was not aware that AB PLC's would do that, what is needed for the processer to "decide" that a bit should be turned off on the first scan?
 

Similar Topics

Hello, I have a project to upgrade a compactlogix CPU. The CPU that is currently in use is v15, and the new CPU is going to be v33. I have...
Replies
3
Views
1,880
Hello all, Stupid newbie question... Just making sure, a bit constantly flipping, and it is reference by 2 OTE in different ladders, that is...
Replies
9
Views
1,674
I've spent three days trying to figure out why my assembly cell is blowing past a step in the logic. While adding blocking bits I noticed the...
Replies
7
Views
3,412
Hi all, Is anything wrong with the hypothetical logic attached? We make a machines that can have 1 of 2 air valve stacks. I would like the...
Replies
11
Views
3,506
Hi all, Got a question regarding the duplicate destructive bit warnings generated when I use InOut tags on my add-on instructions. Most of my...
Replies
0
Views
2,734
Back
Top Bottom