PLC Program Warnings

Hello Experts,

Is it a bad practice or something that is frowned upon if I have some warnings in my PLC code ? Up until this point, I had been always tasked with maintaining a PLC code and now a new opportunity came where I was asked to create the PLC code for a new system from scratch - I am able to get the job done but have some warnings in the code.

Thanks for your inputs!

PS: Just want to add that I am using RSLogix 5000 software for programming a compact logix processor.

I suspect this could be one of those topics that could generate more replies than it might seem.

I personally strive for zero warnings. I like to only see errors when I hit the verify button. It's not always that easy though, I had to implement a couple of rockwell AOI's that have duplicate destructive bits in them, it still bothers me.

dmroeder said:

I personally strive for zero warnings. I like to only see errors when I hit the verify button. It's not always that easy though, I had to implement a couple of rockwell AOI's that have duplicate destructive bits in them, it still bothers me.

Click to expand...

Yup pretty much the same. Depends on what the warning is for though.

There are some warnings that I've had to accept in certain cases, but I definitely strive to avoid them.

For me it's about minimizing risk of missing errors during compililation and to avoid confusion. Warnings are usually possible to disable anyway.

0 warnings too - On Siemens, you want that darn SF LED off.

To me, a warning says that I ought to find a different way to write my code. It flags the possibility that my program might not work the way I expect it to. Furthermore, someone else troubleshooting an issue with the process a few months or years later might see the warning and decide that the rung that generated the warning is the cause of the problems with the machine.
Bottom line, when commissioning a machine, eliminating warnings may not be at the top of my priority list, but it will be on the list.

I would strive for zero warnings, but RSLogix is both forgiving and hard to get rid of some warnings.


My pet peeve regarding this is related to variable types. In Siemens world that is not always the case as the system is not forviging when it comes to your variable types, but on the other hand there's plenty of instructions to sort it out correctly.

What kind of warnings are you having?

I also strive for zero warnings; in some controllers, the code may not compile if you have them, As others have said here, if someone else troubleshoots the code and sees the warnings, they may edit to eliminate, and change the system's operation.

Case in point; I inherited a pair of very complex machines that were built and commissioned by a vendor that went out of business before I started using them. These were controlled by GE 9030s, and had hundreds of warnings for duplicate coils and analog outs. We never got the OEMs copy of the logic on disk, but they did include a printout of the logic in a very thick binder. Reading through it, I found the first rung comment that said "There are numerous duplicate outputs, the program assumes that the last guy is correct and the last guy wins." I spent a lot of time getting all the documentation entered back into the program so that anyone else who worked on them would have it, but can you imagine trying to troubleshoot machine code without that knowledge? I have also been rewriting the code as tme permits to eliminate as many of these as I can. Just something I sholdn't have to be doing!

Yep, our customers are paying us to deliver good code, not warnings.

At my previous job, I had a project with 16 Modicon TSX Compact and Momenentum PLCs programmed in Concept that compiled with maybe a handful of warnings total. One of our other engineers had programmed the master telemetry units and gave me a pair of programs with over 10,000 warnings each! However, Concept has a global option to disallow/allow compiling of programs with more than 1000 warnings. Importing those programs changed the option on my laptop, rendering all of my working programs NOT EQUAL. The only fix was to recompile and download my programs.

Now, I support only two Modicon PLCs and one of those is a friend's hobby project.

Mike

I'm a bit the same as dmroeder and Steve - I hate seeing warnings, and will generally try to find another way to write my code to get rid of them if at all possible, even if I know that the code will function 100% correctly with the warnings present.

Of course, some warnings are for things like "AFI detected" or "shorted branch detected" which might just be evidence that your system is not yet fully commissioned, but not necessarily evidence of poor programming practice. Unless you leave them there once you're done!

A lot of my customers programming standards includes AFIs as placeholders for generic logic. The idea is to copy and paste the program and not have to add any logic. Edit a few rungs to include/not include additional sensors or valves, and you are done.

This of course generates a bunch of warnings. The logic is actually done correctly as the customer desires, but is full of warnings. In this case I usually disable AFI detection as it drives me nuts to see all the warnings.

Hello All,

Thanks for all your comments! I did get the feeling that it may be better to rewrite the parts of the code which is generating all the warnings but I wanted to get an idea about what the industry practice is.

I have all my warnings related to duplicate destructive bit reference detected.

AnotherPLCguy said:

I have all my warnings related to duplicate destructive bit reference detected.

Click to expand...

This should be addressed as it is at best a troubleshooting nightmare and at worst could cause unexpected machine/process operations.

You never mentioned what model plc ( I did not see it).

also, a habit that I have been using for years and put into our specs is to
specify an always on bit and always off bit for testing.
for the slc500 family b3/0 - latched off and b3/1 is latched on.
this is an unconditional rung.

I had a bad experience with an oem.
he picked test bits out of the blue and failed to fix the logic later.

somehow the bits were turned on / off and the machine quit.
since that time, I specify the test bits.
I got tired of 1 am phone calls.

james