dead code

S

Thread Starter

Simone Stefani

Has anyone heard of DEAD CODE, in PLC programs ?
If yes: What do you think about it ?

Simone Stefani
Automation Dep.
Romaco Zanchetta
Tel. +39-(0)583-2171
Fax +39-(0)583-217317
e-mail: [email protected]
 
K
I can imagine having useful "dead code" in a development environment, for instance to be able to select/deselect debugging or monitoring code.
However, as "dead code" (to me at least) refers to code that cannot be reached to run, it would probably not of much use in a finished embedded
system, for instance.

--
Ken Irving
Trident Software
[email protected]
 
R
"Dead code" is code that serves no purpose. For example, it could be code that has been abandoned. Dead Code is frowned upon in the pharmaceutical industry, where we are under the watchful eye of the FDA. It's one of the hot issues inspectors look for.
 
B
If this means what I think it does (non-functional code in a PLC program) then yes.

For instance, some PLC programs don't (or didn't) have very good documenting for sections of similar code that operate like the RSL500 'Titles'. If this was the case, I'd create a rung like this (boolean): "LD015 OUT 15" where 015 was an internal relay that was unused. It would never do anything, but I could hang a comment onto the rung - for instance, "This section does alarm
control" - and provide a 'title' for that section.

Another thing I could do was, during testing, or just to leave certain code in place, but render it non-functional, use a normally open contact from '015' in a branch I didn't want to execute (or a NC '015' contact in parallel with a contact I wanted to shunt out). This would be roughly
equivalent to 'forcing' them off or on, and can be necessary in PLC packages that only allow true I/O (those connecting to the outside world - not
internal relays, etc.) to be forced.

I suppose one might call this 'dead code' if it is left in place in the final revision.

How do I feel about it? Neutral, unless the PLC program needs every microsecond to do what it needs to - this dead code is still evaluated, and
solved, so there is a certain amount of extra overhead in the scan time.
 
A

Anthony Kerstens

Yes. Dead code is logic that has not affect
on physical devices, or other parts of the program. There may be any number of reasons for logic to become dead, but they all would come down to the logic no longer being needed or useful.

As general practice, I remove dead code. However,
if there is a chance that you may need to
reactivate it, for example if the devices still exist because they might be needed again, then I would leave it in.

Anthony Kerstens P.Eng.
 
R

R A Peterson

I am in favor of removing dead code as well. I find a lot of it in equipment that has been modified over the years. Several times I have seen dozens, maybe hundreds of rungs deactivated by putting "always false" instructions, or a "dummy off" contact in a rung to disable it. I always figured the contract engineer that did the mods was just to lazy to clean up when he got
done.

Bob Peterson
 
D
List,

I have seen both, very clean code and code with a lot of dead lines. When I asked why this person always left his dead code in, his response was that it allows him to better track revision changes. When someone would ask why something was removed he could look at the dead code and respond more accurately. His feeling was that comments and revision history was not enough to
always figure out why code was removed or to try to remember what was originally there and to put it back. This makes sense to me, but I still prefer to remove my dead code. I think it depends on how well you control your revisions and
document your changes that matters. Dead code really doesn't steal any processor time, so I think it is more the environment we work in and your personal preference.

Dale
 
A

Anthony Kerstens

Dead code would steal processor time in a Modicon PLC, because everything gets scanned. The processor would have to know whether or not to turn coils off, and reset timers/counters.

Anthony Kerstens P.Eng.
 
H

Hurd, David L (GEA, 053698)

Dead code "DOES" effect a PLC processing time. I've reduced scan times by as much as 40% by simply cleaning up the original code. This included removing all dead code as well as redundant and unnecessary code.
Dave Hurd
GE Appliances
 
Often, the cost of time to remove and clean up dead code after a modification to an existing job is something the customer doesn't want to pay. Don't forget that if you remove dead code from the project, it will have to be debugged, just as if you added new code. To the customer, there is no perceived added value in doing this-- therefore, they don't wish to pay for it.
john
 
C

C. Thomas Wiesen

Dead code buried in the "Real" code is highly annoying when debugging or modifying existing code. It wastes my time and processor time. One way to help prevent dead code in PLCs is to dedicate data files and ladder files for test or
simulation code. This way it is easy to cut the dead code after ALL the debugging is done. Just search for all instances of the "dedicated data" and delete them. Then delete the "dedicated" ladder files. I believe that AB has a feature to look for unused data so you can get rid of it. Dead code is a sign of undisciplined/sloppy programming.


--
C. Thomas Wiesen
Kukulu Automation
[email protected]
 
F

Francis Lovering

Furthermore, dead code causes confusion and wastes time and paper. I think it should be removed.
It is generally easy find, by using cross reference facilities. Any code that sets a coil or output that is not itself used is dead code, and a decent cross reference will show this easily.
Redundant code is another problem that I often come across. That is to say code that appears to be needed, but which in fact never ever can be executed due to the fact that some other logic is already present that is carrying out the some function. A simple example is having two rungs the same as in:
|--[A]------(C)-|
|--[A]------(C)-|
The second rung is redundant. Is this dead code?
What about
|-[A]---[A]-----(C)-|
Is this a rung that contains dead code?
Much more complex and less obvious cases can occur, typically from double checking interlocks in two sections of a program. One programmer told me that it was 'belt and 'braces' - if it were done with relays that can fail then that might be valid, but not in ladder code IMHO. He thought he was protecting himself against his own programming errors, but the logic was such that it could add nothing.

On the other hand something like simulation logic that is used during testing and then disabled in the application is not in my opinion dead code, since it served a purpose and may be needed again.
Francis
www.controldraw.co.uk

> Dead code "DOES" effect a PLC processing time. I've reduced scan times by as much as 40% by simply cleaning up the original code. This included removing all dead code as well as redundant and unnecessary code.

> Dave Hurd

> GE Appliances
 
One would think that this has to be true for all RLL based PLC source code schemes. Lets face it... logic found on a rung, even if the logic is never meant to do anything, must be solved during the scan and as such eats up scan time for no valid reason.

The only way that dead code could not effect scan time is if it never got downloaded to the processor. This would need code that was stored within the source as a comment or in a block that was never compiled to RLL.

IMHO this issue, dead code, is just another good reason as to why the industry should embrace the IEC 1131.3 standard.

Best Regards... Rick Kelly

Chief Technician
Natural Cuts
Cheese Operations
Kraft Canada
(613) 537-8069 V
(613) 537-8057 F
[email protected]
 
P
Does this depend on the physical configuration of the system more than the logic? I am presently using a 90/30 with a 364CPU and three expansion racks. The ladder logic is in about 20 subs and comprises about 1300 rungs; I get a 31ms scan time. This is for machine control, so the racks contain 2 servo modules, 5 stepper modules, 3 HSC's, 256 points in and 160 points out. No analog modules. Last month, I was doing some testing on a servo and I loaded a 10-rung program.
Only <g>. The scan time was around 26ms. I concluded that the 364 processes the rungs damm fast and that scanning the I/O was the limiting factor in cycle time.

As far as dead code... does the 90/30 read the remainder of a rung after encountering an open bit?

Finally, as an aside... the VersaPro guys did a great job with it, especially 1.10. I think it's an outstanding LL package and, at present, the best I've seen.

Paul T
 
A

Anthony Kerstens

If the customer doesn't know what it is, they won't know to ask to have it removed. I do know. Dead code can increase scan time, and certainly it increases cross-references and the time it takes to troubleshoot logic.

In most cases (most...) dead code is the result of either "standard" logic or removed functionality. In one severe case, I seen an
engineer proud that his 800 rungs of "standard" Modicon logic forced him to upgrade to a more expensive processor to the tune of CDN$4000.00.

The decision whether to delete or leave dead code is just that, a decision. each case must be taken on its merits. As I've said before, there are times to delete, and times to leave it alone.

Anthony Kerstens P.Eng.
 
how is that? Does 1131.3 include some automatic method of detecting and removing unused logic? Poor programming is poor programming, and AFAIK
there is no way to automate the programming process, or make a good programmer out of someone who takes no pride in their work.

--Joe
 
B

Brian Martinicky

Hi,

In my experience, leaving dead code around in the interest of saving time/money is a false economy that tends to increase the maintenance burden
for a given piece of code. For example, the poor soul who has to make a mod to a strange program not only has to wade through the active logic, but the dead stuff too.

If the dead code is really just inert (actively executing, but apparently harmless), then new mods risk reactivating it (often in unexpected ways). If the dead code is truly non-executing dead code, then new mods threaten its
potential for future reactivation; subsequent mods may change the ground rules it used to execute under. Of course, the spending extra time to understand otherwise useless code reduces this risk, but the cost of the mod just went up.

It might also be argued that otherwise benign code can drive the design/implementation of a mod into a non-optimal direction. Why should dead
code be allowed to play a role in steering a solution?

Regards,
Brian

--
Brian Martinicky
Automation Intelligence, Inc.
 
Hi Joe...

No... the languages of the 1131.3 construct do not include automatic junk removal systems. Though I agree it would be nice if it did. But what it does have... or more correctly what it does do is try and apply structure to a free form environment. This alone should help with some of the valid points you have raised.

At a minimum, the easy use of comments in the 1131.3 environment allows for dead code to be moved to a comment block so it does not get downloaded to the target.

Best Regards... Rick Kelly

Chief Technician
Natural Cuts
Cheese Operations
Kraft Canada
(613) 537-8069 V
(613) 537-8057 F
[email protected]
http://trondata.on.ca
 
S

Steve Myres, PE

I sometimes put in contacts with addresses that are not manipulated elsewhere in the code to provide for runtime manual switching of subroutines, manual enable-disable of critical rungs. I always label these as "Programmer's Manual Override Bit", etc. Just remember to turn them off (or on) as the end of your troubleshooting cycle, to return the machine to normal running logic. I normally leave these contacts in the logic, as I may need to use them on a future visit, and the program is not capable of turning them on internally.
 
Top