best plc programming tips:

and go!
I'll start.
Always comment the Boolean instruction for their TRUE state.
For example. It is much easier to read a normally closed contact as NOT + the TRUE state of the comment instead of trying to figure out: Ok, the float switch is N.C. but held open yada yada or, the PE is light operate, so ...

- Avoid Latch/Unlatch and One Shots as much as possible.
- Off timers are great, but document them well.
- Document, Document, Document, Document, Document!
- Document some more.
- If you don't want any 2AM calls from Bubba, KISS it.
- For the PLCs that fault, always use a Not Equal to zero of a divisor (unless it's a hard coded number)
- Make sure you trigger a PID loop properly. It changes from PLC to PLC. If you get it wrong your PID is just a sudo random number generator. I have seen more than one programmer pulling their hair out trying to tune one.
- Never assume an operator wont do something. I assure you, they will. So program accordingly.
- Test, Test, Test, Test, Test, Test. And then have someone else test it.
- If your stuck on a problem, explain it to someone else, it helps.

I would have to disagree about the Latch / Unlatch and one shot's
They have been around forever they were part of the original and i expect them be around for a very long time the problem is that most programmers don't understand how to use
always keep in mind that everything in a computer / plc is just bits

you touch it you own it

Good stuff. Random thoughts (rockwell bias):

- When using state machines, keep the transitions simple. More states is better than complicated ones.
- When using state machines, leave gaps for the states you will ultimately have to add in between.
- For me, if I'm trying to fix an issue and I don't get it right by the 3rd time, something is too complicated, I need to rethink some logic.
- Try not to guess at a fix. Use a trend to prove what you think the problem actually is.
- I like to separate logic/functions with a rung with NOP and a comment, explaining what the next few rungs are going to be doing.
- If you are going to indirect address or calculate timer presets, sanitize. Make sure your result plays by the rules (array boundaries, no negative numbers for timers). This will prevent most of the opportunities to fault your controller.

dmroeder said:

- For me, if I'm trying to fix an issue and I don't get it right by the 3rd time, something is too complicated, I need to rethink some logic.

Click to expand...

This used to be a huge problem for me. I used to spend a lot of time designing a system and when I got stuck coding I thought I did a poor job and should've spent more time on design; I then I read about "agile" and that was it. It is an entirely natural process to go back and re-consider the design, update it to new information or obstacles encountered while coding. It is impossible to foresee every single possible problem.
Add unit testing to agile and you have a reliable process.


Edit: Just like now, fixed my spelling and grammar

kalabdel said:

this used to be a huge problem for me. I sued to spend a lot of time designing a system and when i got stuck coding i though i did a poor job and should've spend more time on design; i then i read about "agile" and that was it. It is an entirely natural process to go back and re-consider the design, update it to new information or obstacles encountered while coding. It is impossible to foresee every single possible problem.
Add unit testing to agile and you have a reliable process.

Click to expand...

+1.

Here's a really stupid error that I made the first time I used TIA. It will absolutely allow you to assign multiple things to the same bit.
For example I'd written a program that used say M10.0, but also had a real/double word value that was assigned to MD8, which takes up MB8, MB9, MB10 and MB11. As my value was changing, M10.0 was seeminly doing whatever the hell it wanted as that bit was encompassed in the MD8 value. Then I found the assignment list and realised what an idiot I am.

JaxGTO said:

- If you don't want any 2AM calls from Bubba, KISS it.

Click to expand...

Nevermind Bubba, everything makes sense when you write it. When you come back to it two years later you'll wish you'd kept it simple.

If a device/sensor will fault / shutdown a machine (temperature, pressure. limit switch, etc.) always use some type of latched fault that has to be reset or at least logged somewhere (HMI).
This will save hours of "it just stopped" and trying to see if a switch blipped for just long enough to stop the machine but short enough the operator did not see it.
I know this sounds like common sense but we get machines in with a series of status bits that will stop the machine and it just says "Machine Fault".

Keystone said:

I know this sounds like common sense but we get machines in with a series of status bits that will stop the machine and it just says "Machine Fault".

Click to expand...

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.

dmroeder said:

I like to separate logic/functions with a rung with NOP and a comment, explaining what the next few rungs are going to be doing.

Click to expand...

I miss Page Titles. Criminally underused in the PLC-5 / SLC 500. Missing entirely in the 5000.

OG

I always create routines for defining physical I/O and mapping to internal tags. For discrete I/O I map a physical input to an internal tag and an internal tag name to output. I also create a separate routine for properly scaling analog inputs and outputs so that over-range values don't fault a processor.
It makes it a ton easier to move a device channel, rather than searching through an entire program looking for places, in it, a physical input/output was used.

as stated keep it simple.
before you start writing code, get with the maintenance crew to see what their level of plc programming experience is. It WILL help you to no end.
they are your best friend and worst enemy.
when writing your maintenance manual, document the sequence in order. i always included the i/o numbers, timers so maintenance can then find it in the code.
Write the code in sequential order like you describe in the manual so that everyone can understand and document everything. if maintenance can follow manual and locate the code as you described, they will bend over backwards to fix the issue. If you make the code so complicated they cannot understand it, then the machine is down, production suffers, your boss gets a call, and you get a good chewing out and end up rewriting the code.
ALSO
when comparing numbers, don't forget A<B, A=B, or A>B.
regards,
james

Use structured text instead of instruction list.

The coding is a one-time thing; maintenance could last for decades. So clarity is paramount; nobody (but me ) cares about code golf.

• Comment the code
  • Too much is too much, but better than too little
  • Comments should mostly describe the process, not the code
    • Not how but what and why
      • E.g. not "Add 1 to part_count,"
      • rather "Keep track of part count, in preparation for doing X when N parts are complete"
• If the code cannot be easily read and understood to match what the comments say about the process, then re-code, rename variables, etc., until it is.

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...

They have had real diag for >25 years... You just might need a $40 tool to get to them. Every sensor has an "alarm" (DTC code) for sensor low voltage (sensor failed open or cabling), sensor high voltage (supply/return shorted or sensor internal fault), and a windowed "sanity check" is the third... For example, a MAF is not going to ever see WOT levels of airflow at idle, so a high frequency input at that time will set P0101 ("MAF performance").

Some sensors, such as the heated front oxygen sensors that control all mixture after first startup and outside of WOT (or including WOT if they are OEM wideband oxygen sensors; narrowbands that are more common are only useful around stoich for the given fuel) are so dynamic in operation that they have dozens of fail codes.

I have "re-calibrated" thousands of ECMs. In the GM world at least, they are seriously battle-hardened controllers. Some late-late model vehicles can have well over 1,000 fault codes.

The 97-2004 C5 corvettes have a cluster option for "engineering mode" and the cluster itself will give you the list of DTCs and even let you reset them from there. <ALL CARS AND TRUCKS SHOULD HAVE THIS>