Programming best practices

I know I didn't start this thread, but I want to thank everyone for the great input, I have learned several things.

So here is a question: Do you create seperate sub-routines for inputs, output, and faults?

I have seen some programmers do this and it makes things "clean". But does it help/hurt performance?

Example: Instead of referencing directly to the input, there is a rung in a sub-routine called "Inputs" that uses the input state to control a boolean tag. Then, this tag is used as the "input" reference throughout.

The one thing I like it that it gives you the ability to "force ON" an input, which is not possible normally.
 
Subroutines do not hurt, and allow for organized/clean code.

My typical subroutines consist of:
Analog In
Analog Out
PID
Alarm
Main
discrete outputs (hand/off/auto) logic
Some sort of Control routine that handles the "auto" control of outputs
Sequencing
Communications
Block Transfers
.
.
and so many more!

I typically don't buffer the inputs, but I do see it done.
 
I don't translate inputs to internal bits, it's not really necessary with the forcing modes available now. I have seen it used a while back for the reason you mention.

However, I typically like to buffer the outputs in its own routine. This allows me to put the outputs together for the particular module and in order. It is a great troubleshooting tool. It also allows for an easy way to shut off all of the outputs if needed, by disabling that routine.
In the program I have multiple internal bits that drive each output. Usually an AUTO bit and a Manual bit, each from its own routine. If there are multiple Automatic sequences then they can easily be added without interfering with each other. There are also Man-Auto and Auto-Man routines that provide bumpless transitions. I have seen Manual modes integrated into the Auto sequence and I think it has a tendancy to "clutter" the program. Completely separating manual modes from automatic sequences, the manual modes can be made as extensive as possible and not add any scan time to the normal operating sequence. It is also a safer way to transition between modes. I actually write the Manual modes first so that hardware can be verified. Sometimes I think that I spend more time writing those than the actual run sequence. It saves time in the end, because the mechanics can operate jog parts of the machine they are working on without my need to be forcing bits on and off.
 
Wow, (light bulb goes on!) I never thought about separating the manual mode into a different sub-routine and then not calling that subroutine during auto-cycle.

I guess in my head, sub-routines seemed more a way to keep common parts together for organization. I haven't yet, or really seen much use of NOT running sub-routines that aren't needed.

I bet this really helps bigger machines to run smoother and faster! Thanks again ATU!
 
Not only Manual routines, but also configuration/setup routines, intializations, statistical calculations etc. In the early 90's, I was developing high speed assembly equipment.In order to get those earlier PLC's to meet scan time requirements, I had to make sure that only the logic that was needed during run time was in the scan. I still use those same techniques on the newer PLC's, only now with the faster processors, it allows me to do more.
 
There are also Man-Auto and Auto-Man routines that provide bumpless transitions.


ATU

Can you give more detail on this? Bumpless transitions from manual to auto? Sounds very intresting.
 
Typically, I use separate internal latched bits for both the AUTO mode outputs and for the Manual mode coils. These are both used in the output routine, enabled depending on the current mode.

The problem occurs when you are transitioning from Manual to Auto and vice versa. The last thing you want is to have outputs change when this mode change occurs. To make sure they don't, I create 2 routines. These routines only are executed on the scan between the transitions. In each routine the current state of the outputs are transferred to the state of the internal Manual bit ( for Auto to Manual) or the internal Auto bit (for Manual to Auto). This prevents the outputs from changing state when the new mode takes control.
Now, you do have to make provisions in your automatic sequence when you re-enter because cylinders may have moved. However, it is probably a good practice to make sure everyting is in place in each step of sequence. If not, then you need to flag a fault. This isn't a big problem, operators ususally learn pretty quick to put cylinders back into the position they should be.
One advantage of setting up a sequential type machine like this is that it allows the operator to clear a jam and test a cylinder and return back to the same step in the sequence. On the type of machines I have worked on, this technique saves scrapping out scores of partially formed good product.
 
I prefer to see code with the following features. Note that I come from a largely Siemens background and should be read with this bias in mind!

1. Concise variable names written in CamelCase (xxxVariableName) with a meaningful prefix that indicates the function or location of a variable. For example, inpVarname for variables connecte to a physical input, pibVarName might refer to a permit into the block from external.
2. Also where possible, I like to ensure that variable names when considered in the context of where they are located in a DB or UDT have minimal redundancy. I hate reading things like Heater002.HeatingElements.TurnOnHeatingElement1.
3. Good encapsulation of objects. For example, I like to see device blocks for processing analogue inputs include simulation and test features that don't have to be programmed specially for each project. A library of these sort of things makes implementing future projects that much easier. Device blocks in general should be capable of being "wired" to the rest of your code with minimal hassle and external logic.
4. Above the device level, I like to see standardized integer based state machine layout (there was a good thread on this a few weeks ago) written with clarity and robustness in mind,and with appropriate troubleshooting features built into the code (inhibit transitions, skip to step, minmum state time).
4. "symbol has priority" style is my preference in S7. I don't much like seeing code with loads of manual buffering placed all over the place.
5. Minimal tag interface to interface panel or SCADA. The number of tags influences the processing load the PLC must bear and also influences the cost of some packages. A well defined standard interface for tags can, depending on package, reduce development time as well.
6. Searchable links to functional specification. Where possible the functional spec should be linked to the code
7. Comments for physical inputs and ouputs should make finding them in the electrical drawings easy.
8. I can't believe nobody else has said it yet - try and use a standardized languge where possible (Ladder, FBD). Writing code in less common languages like STL, SFC or any other graphical/text language is likely to reduce the chance of being able to reuse the logic on another project, the more so since clients don't often like to buy new packages and retrain their maintenance people to troubleshoot problems late at night when support is far away.


I agree with this fully. Most likely due to starting off on Siemens, then transistioning to AB. I fell that I can get alot more organized in siemens then AB, with the use of DB's and UDT's. Now I'll have to search around the thread you mentioned in line item 4 :)
 
Grafcet

There is a method of programming called grafcets. It is so easy to trouble shoot. That is the only way I program anymore. Standard Code is what I call speghetti code. Google it and there is a lot of information on it.
TT
 
Compact Logix Communications

We purchased a PLC trainer and the plc that is used on it is a Compact Logix.
Here is the PLC information:
1769-L16ER-BB1B
There was a sticker on the front of the PLC that said: This Series B controller requires firmware version 20(20.014 and later) Verify that you are using compatible software firmware version. Failure to do so will result in an inability to program the controller.

We are using the latest version of RSLogix Studio 5000 software. I am now what what I should be looking at to make sure we have the correct firmware.

When we configure an ethernet driver and put in the IP address that is listed on the PLC trainer, the RSLinx software can not communicate with the PLC.

Does anyone have any ideas of things that I can look at. I have a ethernet cable going from the laptop to the compact Logix plc
 
I/O and their respective internal bits should be named to indicate what is happening when energized. For example, a prox switch’s name should be “Lift is raised” and the solenoid’s name should be “Raise lift.”
 
The standards I like to see are PackML structure and use of Equipment Modules and Control Modules. Using them structures makes it very easy to understand each part of a machine or process plant, and where to look if you want to check the alarms, outputs, etc.
 

Similar Topics

I've been doing PLC programming for about 15 years now but all of my experience has been with Allen-Bradley PLC's. A few months ago I started a...
Replies
5
Views
3,147
I'll start. Name coils with their true state. For example, if the photo eye is light operate, make the coil PE Clear. That way, when you see the...
Replies
72
Views
25,018
Hi All - I have a system that I am setting up with about 50 axes of motion. There are 10 stations total where 9 of them are exactly the same. I...
Replies
0
Views
1,379
If I have a program that requires 10 different PID loops should I 10 different period tasks (using RSLogix5000)?
Replies
4
Views
2,334
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...
Replies
65
Views
21,495
Back
Top Bottom