best plc programming tips:

Phil Buchanan said:

I second this. There are many great features of 5/500 that were never ported to logic that should have been IMHO.

Click to expand...

I used page titles for section headers also, since RSLogix500 would let you put a page title on every rung

if you can ask the question "what if this happens?", you better plan for it.
every time any one says that is a 1 in a million chance, forget about it, it happens
10 minutes in the run off in front of the customer, every time!
at least for me it does.
james

I've done a fair amount of work coming in to small companies and modifying someone else's programming. I appreciate those who keep it simple, organized and documented. I try to carry that practice on.

If I am making changes I will put a comment in the rung with the date and the change that was made. In the revision notes I'll leave my name, company name, email and ph. no. Sometimes its almost impossible to to go through channels to find out who did it.

IF there is a place to save your modified programming, such as an SD card or HMI memory, then use it. USB drives are cheap, you can save files on one and zip tie it inside the enclosure door.

Keep rungs to a manageable size. If you have to scroll to the right or follow wraps, its too big.

I loathe those (who may be very intelligent) but who think they are God's Gift to Programming. They will use the most complicated way to program the simplest thing. No need for documentation, its all in their head.

I despise the excessive use of AOI's. You can duplicate logic and do a search and replace when its the same logic, multiple times. Its alot easier to troubleshoot and modify for someone else down the line.

i agree with you on the line length.
i have a program that can only be viewed on a 32" monitor, the rung is that big.
on a 15" monitor, when you see the whole rung, you cannot read the tags.
i have also seen a plc 5 program that had 125 contacts on 1 rung. how can you debug rungs that big?
james

johnd_125 said:

If I am making changes I will put a comment in the rung with the date and the change that was made. In the revision notes I'll leave my name, company name, email and ph. no. Sometimes its almost impossible to to go through channels to find out who did it.

Click to expand...

I always save a pre-edit copy called project_UPLOAD_date

johnd_125 said:

IF there is a place to save your modified programming, such as an SD card or HMI memory, then use it. USB drives are cheap, you can save files on one and zip tie it inside the enclosure door.

Click to expand...

I worked in a shop that bought Flash drive business cards to hand out at trade shows with a catalog and video on. I grabbed a handfull and put one in each control panel in the shop with the PLC & HMI programs and copies of the schematics.

johnd_125 said:

Keep rungs to a manageable size. If you have to scroll to the right or follow wraps, its too big.

Click to expand...

+1 here. I always broke them into single lines and set a bit, then started the next line checking that bit. Even what would be large branches I put on it's own rung and set a bit. Made troubleshooting a lot easier seeing which line wasn't true instead of looking through a rung wrapped 6 times with 5 large branches.

Cut the process/machine operation into small manageable chunks, then program those chunks in order. I try to have my program's organization follow the actual process flow, f. ex. stations in the IRL order in the program. Try to maintain the same overall structure in each of your programs. I work for an SI and I often do one-off machines or process sections, but my base structure remains similar throughout each different PLC I do. If we get repeat business it's way easier for maintenance staff to transition from one machine to another and they get a sense of the logic flow and where everything is even if they've never seen that particular program before.

The definition of a "chunk" may vary, especially when it comes to the process logic part. For instance, for me an entire valve matrix might be a "chunk". Someone else may separate the different pipelines instead into "chunks". I don't think there are real true answers as long as what is a "chunk" is constant throughout.

That's optional, but I like to restrict the scope of my variables to only as much as I need. That means using program tags or the equivalent. If I need "chunks" to talk to each other I will scope interface tags appropriately. I think of it like I/O mapping. If I need to change an I/O point I just have to change it at one place. Equivalently, if I have to change the logic of a "chunk" I just change it there and because of the interface I don't have to run around the entire program changing stuff at different places. You don't really need to scope tags to do this but it helps keep the discipline.

Another optional tip, I like to have all my tasks periodic, especially the process task. The reason is that it keeps time-dependent logic with the rest of the logic, inside their chunks. I find that much clearer to follow than having to jump to a separate periodic task and find the bit of logic I need.

I don't have anything against latches and unlatches, but if you use them latch at one place and unlatch at one place, preferably in close proximity.

I like to place a "ChangeLog" ST subroutine that's just a huge comment that tracks changes. It never gets used except by me, but if it *did*, it'd really help tracking who did what where and for what reason.

For the love of your preferred deity, include a way, any way, for the operator to see conditions that interlock an action. No one should need to go into the program to tell the operator "yeah you can't do this because this swing elbow is not detected".

And if you make live modifications, erase your programmer bits and the old logic when you know it works. Nothing worse than seeing *years* worth of logic modifications onto a single rung. You've got a toggled bit JohnF_20160412 cancelled by TomC_20180718 and the old 2014 logic is still there!

Great thread
No one (or I missed it) mentioned anything about alarms yet, what is your best practice.


I recently had to troubleshoot an alarm message on HMI, I had access to the PLC program and not to the HMI. The alarm was something like "Product Detection Error, the sensor did not detect product", yet the machine continued on working, products going through fine, sensed and processed. There wasn't a single tag named anything close to "Alarm" or "Error" (I'm exaggerating, there were a couple) .
It was a nightmare to determine which bit the alarm was connected to. It was a bit that got reset very quickly once the product is sensed, a timer bit as I recall.

I put all alarms in an alarm array, whether DINT or BOOL, make sure the array is large enough for any future expansion, and usually include a couple of reserved alarms the HMI should never show.


Alarms like:
OMG - WT* Did You Do?
You Better Talk To Your Supervisor Before Trying That Again
You Can't Do That!!!
Hey, Slow Down - You're Making Second Shift Look Bad

Self Destruct Initiated

and the ever popular: Mothership En-Route

cardosocea said:

You should tell this to the Auto industry...
Not the makers of the machines that make cars, but the car makers. Most have one or two lights and that's it.

Click to expand...

Ah, I laughed at that.

This week I was called to a machine that would not run.
One flashing red fault lamp and the HMI just said 'not in home position'

Which part is not home? As it looks like everything is in the home position.
A Panasonic plc - so no software. Sherlock Holmes mode then.

No servo's or anything just lots of hydraulic rams with limit switches that are made??

4 hours later I spot that a ram linear sensor is not quite home.
Undo nut, slide up a little, light off, fault gone.

How hard would it have been to write on the HMI Top folding ram not home?

cardosocea said:

You should tell this to the Auto industry...
Not the makers of the machines that make cars, but the car makers. Most have one or two lights and that's it.

Click to expand...

Ah, I laughed at that.

This week I was called to a machine that would not run.
One flashing red fault lamp and the HMI just said 'not in home position'

Which part is not home? As it looks like everything is in the home position.
A Panasonic plc - so no software. Sherlock Holmes mode then.

No servo's or anything just lots of hydraulic rams with limit switches that are made??

4 hours later I spot that a ram linear sensor is not quite home.
Undo nut, slide up a little, light off, fault gone.

How hard would it have been to write on the HMI Top folding ram not home?

Ronnie Sullivan said:

Ah, I laughed at that.


How hard would it have been to write on the HMI Top folding ram not home?

Click to expand...

Or the famous Ram Not Home #618

Where it is not input 6/18, not on line 18 of page 6 on the schematics. Not sensor 618, cylinder 618, valve 618 or on output 6/18. Not even rung 618 in the program, no mention of 618 in any alarm, and no list anywhere except the original programmers files what the codes are.

Pro programming tip "Don't use FUBAR Bits in your programs"

Storytime.

I got a new job as a plant automation engineer and after a few days in one of the electrical technicians with some basic level PLC experience asked me to help him understand the "Few Bar" bits that were keeping some code working on one of the machines that they had not used in a long time.

This gentleman was a very sharp technician but English was his second language and he came to the states as an adult.

I had him connect to the machine in question and show me the logic he was referencing and it was a xic instruction being evaluated as false and being conditional to a lot of other logic in that section of the program and the instruction comment was FUBAR Bit.

I had a good laugh and had to explain to him that a FUBAR Bit was not some advanced programming technique and then spent a few minutes explaining the origin of the word FUBAR. He had been dealing with this in other programs in that plant for a few years.

Someone at some point in that plant had quite a sense of humor.

Phil Buchanan said:

Pro programming tip "Don't use FUBAR Bits in your programs"

Click to expand...

On a similar note don't label fuses FU1 to FU9.


I was working on a schematic at home and my 9 year old son looked at it and asked "I know what FU2 is, but what is FU3 and FU4?"


Also not good to abbreviate ANALOG the normal way and use ANLG instead.

cardosocea said:

You should tell this to the Auto industry...
Not the makers of the machines that make cars, but the car makers. Most have one or two lights and that's it.

Click to expand...

Here's on from Philip Koopman timeline in linkedin

I_Automation said:

On a similar note don't label fuses FU1 to FU9.


I was working on a schematic at home and my 9 year old son looked at it and asked "I know what FU2 is, but what is FU3 and FU4?"

Click to expand...

Lol. Kids pick up the craziest things don't they?