Names for programming styles?

Tharon

Member
Join Date
Jan 2007
Location
Other
Posts
1,430
I'm just curious, I'd like to communicate better with people who work with me from other companies about programming. Here, we have a standard way of programming machines. And if/when we get outside machines done for us, we'd like them to be done similarly, makes for easier troubleshooting later on in life by our maintenance crew.



I:0/1 B21/1 B20/1
---| |-----|/|------------------{OTE}

B20/1 T4:1
---| |--------------------------[TON]

B20/1 T4:1.DN Complete B21/1
---| |-----| |---------|/|------{OTE}
|
B21/1 |
---| |----------

B21/1 B21/2 B20/2
---| |-----|/|------------------{OTE}

B20/2 T4:2
---| |--------------------------[TON]

B20/2 T4:2.DN Complete B21/2
---| |-----| |---------|/|------{OTE}
|
B21/2 |
---| |----------

B21/2 I:0/1 Complete
---| |-----|/|------------------{OTE}



This is an example of how our sequences are usually structured. I'm sure this is nothing original, not claiming it is, but I'd like to be able to explain to others how our standard machines are programmed. Without throwing them an example each time, is there a name for this?
 
It is ladder programming, but from the sequence I'd guess it's designed with Grafcet and then converted to simple ladderprogramming.

Grafcet sometimes is called SFC or sequential function chart, but if you use that terminology you might end up with someone using SFC as a programming language.

Kind regards,
 
I guess I wasn't clear enough, I knew it was ladder programming :) I was just wondering if there were names for the various styles of programming ladder logic for a machine that does a repeated sequence.

Thanks for the answers anyway. I hadn't heard of Grafcet before.
 
Last edited:
I call it state programming in ladder without using SQO. You will see this done in sevral ways. I have seen companies send out pogramming standards in the bid package. You may want o look at that as an option.
 
Without throwing them an example each time, is there a name for this?

I've never heard of a name for the technique that you've posted ...

in my opinion, you really DO need to give them an example each time - and specify that it "MUST look like this" - or I'm afraid you're not going to get what you want ...
 
I'm learning that a lot goes into a particular programming style. Some of the considerations I've had to deal with lately:


  • Use of multiple output conditions on rungs in a ladder. In some places, where input conditions are identical, it's okay to do this, but as rungs become more complex, it becomes harder as time marches on to unravel what all a rung does. More simpler rungs is generally better.
  • Using the I/O configuration to isolate equipment or groups to particular I/O modules. This can be a plus in terms of maintainability and single point of failure avoidance, but it can lead to a larger I/O load (more expense) for the project. As with most things, it's a trade-off against the cost of downtime.
  • Similar to the previous, use of addressing schemes that make clear which address is for what function of a given piece of equipment. As an example, say B3:1/1 is the bit used as a permissive to start No. 1 pump. Use the rest of the B3:1 word for functions for No. 1 pump. Use B3:2/1 for No. 2 Pump permissive, and B3:3/1 for No. 3 permissive, etc. When your addressing scheme follows a logical pattern that is consistent, the folks maintaining your system can become familiar with it more rapidly.
  • Breaking a program up into functional groups can make it simpler to understand and troubleshoot. This can range from creating a separate file for each piece of equipment or each function under the control of the program, or can get as complex as an SFC or K-Sequence type program flow. Some of this is hardware dependent (some PLCs don't do SFC style programs).
  • Documentation! No matter which programming style you adopt, document EVERYTHING in a program. Use intelligible instruction and rung comments, or develop a table of long descriptions for your "symbols" if you are forced to use shorter descriptions for I/O. The value of your documentation to the overall usefulness and maintainability of your systems cannot be overstated.
  • Labeling & Nomenclature. This plays into your documentation, but also impacts programming style because it shapes the thinking that goes into a program's design. Be clear, consistent, and thorough in your labeling of wiring, terminations, devices, equipment, and subsystems. Ordered thinking here can improve communications and help avoid costly errors during the design and development phases of a project, too.
Well, I gotta get out of here for now... it's time for lunch. Talk at you all...

Later On,
D
 
Iec 1131-3

try searching IEC 1131-part 3 it may be of some help

If you are working with A-B gear, it's worth noting that A-B is only partially compliant with IEC 1131-3. They are migrating in the direction of full compliance, though.

The per copy cost of the document itself is about $300.00. That's a bit steep, but such is the price of standards compliance.

Back to the original ladder example: are the {Complete} instructions analogous or similar in some way to Zone Control Logic as implemented in many A-B PLCs? It seems to have a similar sort of function (if the conditions for a ZCL are not satisfied, none of the program code within the zone of control is scanned, though, so the results are a little different...maybe?) I'm just guessing.

Later On,
D
 
Last edited:
The "complete" was just the name I gave the bit. Basically it was just the example of a two step sequence that started every time I:0/1 went true. (like a cycle start button).
 
I'm just curious, I'd like to communicate better with people who work with me from other companies about programming. Here, we have a standard way of programming machines. And if/when we get outside machines done for us, we'd like them to be done similarly, makes for easier troubleshooting later on in life by our maintenance crew.



I:0/1 B21/1 B20/1
---| |-----|/|------------------{OTE}

B20/1 T4:1
---| |--------------------------[TON]

B20/1 T4:1.DN Complete B21/1
---| |-----| |---------|/|------{OTE}
|
B21/1 |
---| |----------

B21/1 B21/2 B20/2
---| |-----|/|------------------{OTE}

B20/2 T4:2
---| |--------------------------[TON]

B20/2 T4:2.DN Complete B21/2
---| |-----| |---------|/|------{OTE}
|
B21/2 |
---| |----------

B21/2 I:0/1 Complete
---| |-----|/|------------------{OTE}



This is an example of how our sequences are usually structured. I'm sure this is nothing original, not claiming it is, but I'd like to be able to explain to others how our standard machines are programmed. Without throwing them an example each time, is there a name for this?
I would call this sequential states.
A hint: always write them in reversed order, otherwise more than one state will be active in the same scan, on state transitions with previous state reset.
 
Last edited:
The "complete" was just the name I gave the bit. Basically it was just the example of a two step sequence that started every time I:0/1 went true. (like a cycle start button).

Gah! I just caught up to what you were doing... it's been a busy weekend and my brain is about fried right now. I'll shut up for a while. :oops:
 

Similar Topics

I copied a panel in factory talk HMI for an identical system. The label names are still the same as the original panel but I am trying to change...
Replies
0
Views
54
I was reading about the ability to add a name to an RSLinx Config so that it displayed in the tree, and further read that that functionality was...
Replies
5
Views
176
Hi all, I'm going to start programming a 1756-L73 and I'm still waiting for the full Studio5000 to be able to start at it in earnest. But I...
Replies
5
Views
385
This is kind of a beginner question. Let say I have 2 Rockwell PLC talking to an InTouch standalone installation. Let call them G1_PLC and...
Replies
9
Views
1,063
Hey all, I'm doing a more standardize version of one of my programs and organizing things into UDTs and whatever else I can do to shrink the...
Replies
0
Views
409
Back
Top Bottom