Set and Reset bits - Rant

Rob...

Lifetime Supporting Member
Join Date
Jul 2016
Location
Manchester
Posts
476
I was always taught to make my software easy to understand and fault find on by anyone reading it. Good practice right?

Now I know set and reset bits are useful and I use them often in code for a specific purpose.

However I've just spent 9 hours today trying to work my way through someones code on a machine. I kid you not there are 13 bits in this software set and reset in over 50 places each. Everything is done with toggling.

(A lot more of what I would consider bad practice, but that was an easy example, another, using timers to avoid scan time issues)

To makes matters more interesting a lot of it runs through indirect addressing and pointers. So cross referencing is a pig!

It seems like whoever has written the code has made it, even for the most basic of functionality, as difficult as possible for anyone to ever work on.

Doing it sat in a control room with no AC at 42 degC (107deg F) didn't help my patience.

Whoever wrote this software, your name has been mud today. Rant over, time for a cold beer!
 
I was always taught to make my software easy to understand and fault find on by anyone reading it. Good practice right?

Now I know set and reset bits are useful and I use them often in code for a specific purpose.

However I've just spent 9 hours today trying to work my way through someones code on a machine. I kid you not there are 13 bits in this software set and reset in over 50 places each. Everything is done with toggling.

(A lot more of what I would consider bad practice, but that was an easy example, another, using timers to avoid scan time issues)

To makes matters more interesting a lot of it runs through indirect addressing and pointers. So cross referencing is a pig!

It seems like whoever has written the code has made it, even for the most basic of functionality, as difficult as possible for anyone to ever work on.

Doing it sat in a control room with no AC at 42 degC (107deg F) didn't help my patience.

Whoever wrote this software, your name has been mud today. Rant over, time for a cold beer!

Maybe its a conspiracy to try and improve the troubleshooting skills for anyone who comes across their program. J/k, enjoy the beer!
 
I have to be on guard constantly for overthinking and over complicating.
In that regard I am my own worse enemy.

I always have to think " the straightest possible line"

It very well might not have been intentional, but I have know people who will make three left turns to go right.
 
I knew it wasn't an issue with the code, nothing had changed an had been working for a couple of years. Was just an intermittent fault with a discreet input.

Working around the world i've noticed this style of coding more from Germany than anywhere else. (It's where I'm working this week). Maybe it's how they're taught. Never thaught to ask.
 
Working around the world i've noticed this style of coding more from Germany than anywhere else. (It's where I'm working this week). Maybe it's how they're taught. Never thaught to ask.

I think there are two styles to laying out a program:

  1. What do I want to happen when the input is on? (lots of set/reset logic)
  2. Under what conditions do I want this output on? (mostly coils)
I think most programmers naturally start at the first style, but experience and working with other programmers eventually leads them to the 2nd. I also think that text based programming tends to lend itself to the first method better, so when someone learns to program VB/C/whatever on a PC before coming to PLCs, I see a lot of the same thing.
 
I feel your pain.
1 program had 14 latch bits and 13 unlatch bits all the same bit, 3 days to figure out what he was doing. we rewrote the program. downtime reduced by half.
another program, I firmly believe the guy wrote the program, printed it out 1 rung per page, threw it in the air, and coded it as he picked the pages up. he had to debug it some. what a mess.

Always remember, keep things in order, keep it simple, use 9 rungs it it keeps things simple for others, not 3.

james
 
for most PLCs (including Allen-Bradley) you should also consider the question:

how do I want the machine to react when it is turned back on again after a power failure or shutdown situation? ...

in other words - are there some "states" or "conditions" that you want the PLC to remember after a "go to run" situation? ... if the answer is "yes" then an OTL (Latch) instruction is probably the way to go ... specifically, a "seal-in" rung using an OTE (Output Energize) instruction will not work correctly - since the Allen-Bradley is designed to write a ZERO status to OTEs during its PRESCAN operation ...

if you're interested, you can read much more about this subject here:

http://www.plctalk.net/qanda/showthread.php?p=71786&postcount=1
 
Last edited:
I've had this. Told the customer that I'd have to junk the program and start again as you could see it going mad trying to work out what it was trying to do.

Luckily it wasn't complicated, just controlling a security barrier and gate.

There were multiple uses of the same set and reset coils. That's why I prefer creating my own latching circuits.
 
I think mk42 is correct in that assessment. Text-based programming, as well as logic circuit design, tends to get you thinking in terms of edge-based transitions and persistent states.

For example, you will see a significantly greater number of IF-THEN constructs in most programs than you see IF-THEN-ELSE constructs. The first, while not specifically edge triggered, does produce persistent states.
Naturally, people who come from that mindset and training will gravitate to the same general format in a plc. The problem is the first thing they are told about that accomplishes something similar to the IF-THEN action is the SET-RESET combination. And then its on.

Logic circuit guys tend to shiver when you expose them to combinatorial logic. I think they feel they open themselves up to spurious changes of state using combinatorial logic. So they tend to think very much in terms of states and transitions and use the first tool they can find to accomplish that. One of the tougher programs I had to work through early in my career was for a plc that was used to replace the functionality of a logic board. The program was written by the same guy who designed the logic board. I'm not sure there was a single OTE in the program. But the thing did act exactly like the original logic board...for better or for worse.

Keith
 
Last edited:
for most PLCs (including Allen-Bradley) you should also consider the question:



in other words - are there some "states" or "conditions" that you want the PLC to remember after a "go to run" situation? ... if the answer is "yes" then an OTL (Latch) instruction is probably the way to go ... specifically, a "seal-in" rung using an OTE (Output Energize) instruction will not work correctly - since the Allen-Bradley is designed to write a ZERO status to OTEs during its PRESCAN operation ...

if you're interested, you can read much more about this subject here:

http://www.plctalk.net/qanda/showthread.php?p=71786&postcount=1

My first project was one that needed a few edits, made offline. The program was given to me, and apparently it was saved in a run state. It had a ton of latches and the original code didn't reset on first scan. When I downloaded and went to run things started up. Scared the **** out of me. I know to look now, but latches should be avoided, there are better ways.
 
I feel your pain. I had to work on a program once that had almost no coils, but thousands of latch bits. There were, however, no unlatch bits at all. Zero. Instead, they used a masked move instruction to write a zero to one or two bits, with a hexadecimal mask. So when you cross reference a bit to work out what makes it turn on and off, you got 5-10 latch bits and 100-200 masked move instructions. To work out what was turning the bit off meant going through each of those 100-200 MVM instructions and mentally converting the hex to binary to see if your bit was one of the ones that got turned off.



To this day I've never seen worse code.
 
latches should be avoided, there are better ways.

I'm an old dog - ready to learn a new trick ...

assuming that we're still discussing Allen-Bradley systems - could you please give an example or two of a better way? ...

for one example - suppose that a lumber machine needs to remember a condition such as "log in position A" after a plant-wide power failure ... I've always believed that once the power is restored, the PLC will forget that particular condition if a seal-in rung construction (with an OTE) has been used - instead of a Latch (using an OTL) ...

this subject of "retentive" and "non-retentive" constructions has been debated on the forum quite awhile ago ... I'm interested in finding out if something "new" could be added to the discussion ...

previously the consensus of opinion was determined to be:

1) sometimes you NEED a Latch/Unlatch construction ... but ...
2) sometimes you NEED a "seal-in" construction using an OTE ...

they are NOT the same thing - and they can behave completely differently when the Allen-Bradley system has a "Go To Run" condition ...

I will completely agree that sometimes (even OFTEN) the Latch and Unlatch instructions are misused - and that they certainly can lead to confusing code ... BUT ... sometimes they are needed - and by ALWAYS avoiding them a hazardous condition can result ...
 
I feel your pain.
1 program had 14 latch bits and 13 unlatch bits all the same bit, 3 days to figure out what he was doing. we rewrote the program. downtime reduced by half.
another program, I firmly believe the guy wrote the program, printed it out 1 rung per page, threw it in the air, and coded it as he picked the pages up. he had to debug it some. what a mess.

Always remember, keep things in order, keep it simple, use 9 rungs it it keeps things simple for others, not 3.

james
...
 
I feel your pain.

I have a customer with an unloader on a conveyor line that is programmed with set/reset for everything. Except the programmer never took the power cycle or E-stop, or even a fault shutdown. into consideration. If it shuts down with product entering there better be product there when you try to restart it or it won't start.

Another project I had was a simple parts accumulator that pulled one panel at a time from a line. It was programmed so complicated it was impossible to troubleshoot. I just wiped the program and wrote my own. The old program was over 250 rungs and my working-fine version is 35 rungs - and that includes counters to log how many panels went through, just for my knowledge.
 
I will completely agree that sometimes (even OFTEN) the Latch and Unlatch instructions are misused - and that they certainly can lead to confusing code ... BUT ... sometimes they are needed - and by ALWAYS avoiding them a hazardous condition can result ...

I guess I wasn't specific enough in my response. The program I edited used latches/unlatches to start motors, open/close valves, etc. Which, is why I went to run mode things just started back up at it's last state. There is no reason for this. I will not debate it. If you like it, I won't talk you out of it. Sure, you need retentive memory for things like a log in a machine, but this shouldn't start anything up automatically.
 

Similar Topics

I have a graphic that has 2 buttons for Automatic and Manual, each with pushbutton animations associated with them to toggle a bit in the PLC, one...
Replies
8
Views
2,452
I just recently installed a1771 HSCM in a plc 530 and for the life of me I cannot get the reset fuction to work. all the Numbers in the encoder...
Replies
3
Views
1,666
I am looking at a S7-200 program offline that has code that uses set & reset commands but the length is set to 0. The online helps states...
Replies
5
Views
6,686
Having trouble trying to reset some data bits at power up of the PLC. Want to reset them before I execute OB1 anybody give me any pointers.
Replies
5
Views
1,846
We are using RED LION HMI Since las 15 years. To day we have found that My log file has data up to 22 Mar 2024 1:16. Then After new Log File is...
Replies
22
Views
837
Back
Top Bottom