Basic PLC question that challenges the best:

Will probably get punished for this, but if you have a hard time to grasp AND,OR,NOT and the states TRUE and FALSE and needing virtual contacts & coils instead you should probably stick to your screwdrivers & multimeters.


It's not AND/OR/etc. that is the problem, it is looking at code and converting that to a model of what that code does. in one's mind.


You and I and many others here can do that without even realizing that we do it, so we don't care if we are using LAD or ST or FBD; to someone who does code for a living, it is not so simple.


I read English without thinking about it. From past schooling I can look at Deutsch and usually get a rough idea, though with a struggle. If you put Svenska* in front of me, I might be able to guess at a few words, but the meaning would be a mystery to me.


Some electricians can look at LAD and understand it better than either of us; there is value in that, but the magnitude of that value will be situation- and application-dependent. Show those same electricians some nested if-then-else clauses and the best they can do is blink.


* Svnesk? See what I mean?
 
Last edited:
Interesting conversation, I started repairing/designing videogames (commercial like bally midway and many of the Japanese ones), the logic was I believe ansi rather than European symbols, when I started PLC programming mainly on Siemens the symbols were a little harder to remember because of the IEC standard, however, ladder no problem. I also programmed in low & higher level languages so had a pretty wide grasp of the many types. Thinking about it, regardless of whether it is LAD FBD ST or STL, the compiled code will be similar regardless, so the point is it depends on personal preferences, I'm comfortable in all, however, I do prefer FBD or ladder (ST I have to think harder even though pretty fluent in pascal, C etc.). I believe ladder is a little easier to see the flow when on-line but it makes no difference to me.
 
Some electricians can look at LAD and understand it better than either of us; there is value in that, but the magnitude of that value will be situation- and application-dependent. Show those same electricians some nested if-then-else clauses and the best they can do is blink.

But is that not because they grew up reading electrical prints and relay logic, not because ladder is that much easier to read, I spent a good portion of my early days working with S5 STL and if you read it like a book it makes since, I think STL came around because they (Siemens) wanted something that programmers could program fast (for PLC's) and they were wanting all programmers to take it up and use their PLC's.

I will stick with ladder but anyone that is troubleshooting or programming should be familiar with them all because some day you will run into it.
 
But is that not because they grew up reading electrical prints and relay logic,


exactly. the best language is situation- and application-, maybe even organization-specific. coders need to know them all because they may come up against them some day.


it's only ones and zeros; it cannot be that hard.
 
Yes, Ladder is much better than FBD, if you can't make a good LAD network, you are trying to fit too much in one network anyway.

FBD is horrible, even more horrible than STL.


ST naturally trumps those all for almost everything when written with proper naming.

100% agree with all of those statements.
 
I think the main reason a lot of people stick to ladder is the programming software makes it easy. Click an icon get a XIC the one next to it XIO - or F5 and F6 in Mitsubishi or AD DirectSoft.



Trying to teach a beginner is easier if they can see the icons on a menu bar, so it becomes 'the best' even with more features and functions available in FB and ST.
 
It's not AND/OR/etc. that is the problem, it is looking at code and converting that to a model of what that code does. in one's mind.


You and I and many others here can do that without even realizing that we do it, so we don't care if we are using LAD or ST or FBD; to someone who does code for a living, it is not so simple.


I read English without thinking about it. From past schooling I can look at Deutsch and usually get a rough idea, though with a struggle. If you put Svenska* in front of me, I might be able to guess at a few words, but the meaning would be a mystery to me.


Some electricians can look at LAD and understand it better than either of us; there is value in that, but the magnitude of that value will be situation- and application-dependent. Show those same electricians some nested if-then-else clauses and the best they can do is blink.


* Svnesk? See what I mean?

First... I don’t generally agree that an electrician can look at LAD and understand it better than a programmer. Can you find “some” electrician that’s better than “some” programmer? Sure. But I don’t think that’s the typical case. They often make mistakes and misinterpret that it would function as actual schematics rather than what it is which is a series of instructions, often with asynchronous interrupts. And the difference in that interpretation makes a difference. Add anything even remotely non-schematic like and they’re done.

Second, comparing natural languages to programming languages is a false equivalence. For many reasons.

C has 32 keywords. Most natural languages have tens or hundreds of thousands.

With the exception of undefined behavior, there is exactly one way to execute a set of program instructions. Natural languages are ambiguous.

Look, learning a programming language is not the hard part. Programming is the the hard part. And they’re different things. This is even the point you’re basically trying to make. It’s something non-programmers generally don’t get.

But that’s not the same as all languages are equal. I’ve already enumerated some of my preferences.

And LAD specifically...geez. What a waste. It’s only benefit (which you almost appear to agree with me on) is a vague resemblance to schematics. It’s better at showing simple Boolean logic for people who don’t otherwise understand programming. I’ll give it that. But then that’s it. It’s a one trick pony and its trick kind of sucks. Anything that doesn’t abstract well to an electrical schematic is a complete train wreck in LAD compared to a text language. And modern control systems are more complex than that simple Boolean logic. It’s not that it can’t be done in LAD. It’s that LAD is extremely limited in what it is good at and the trade off isn’t worth it.

So, why not just use LAD in the snippets where it’s not a massive pile of garbage? Because that involves context switching as you navigate different sections of the code and again, the use cases are so trivial that I think the negative impacts of context switching negates any gains the fake schematic code has.
[edit: also, if requirements change, you don’t have to rewrite in ST when it has to change to something beyond what LAD doesn’t suck at]

But what about the electrician that has to troubleshoot the system? Look, I’ve already said that the program is for debugging and the HMI is for troubleshooting. Defaulting to the program as the main source of troubleshooting is lazy and doesn’t work as soon as the electrician finds something non-trivial. The industry went the wrong way with this one in my opinion.

Don’t take this the wrong way. I’m not bashing electricians. I’m bashing the idea that programs have to written in ways for non-programmers to read and use. Sorry. Not interested.
 
Last edited:
In my experience and personal opinion, I don't care much what language is used in a program. Besides, I think there's a convergence going on. Some PLCs allow you to write a program in ladder, then drop a "rung" of ST (basically a text box with a scroll bar) in the middle, and keep going in ladder. Some other PLCs allow you to write short ST statements as input to ladder functions or function blocks. Even Rockwell has CPT and CMP blocks which are basically logical or mathematical ST blocks, because everybody agrees that for anything more complicated than simple arithmetic, lining up basic operation ladder blocks to get to the grand finale 15 instructions later is a pain.

Also, language preference will be coloured by the preferred vendor's implementation. Sometimes I think that when people say "this language blows" they are really thinking "this vendor's implementation of this language's logic editor blows". Sometimes people say ST isn't visual, and I think it's true in Rockwell's editor because you have to use a watch window to see the values of variables. Most other vendors have little bubbles that pop next to the variable names when online that show their current value (even colour-coded for boolean logic). I think that's no less visual than seeing power flow from "positive" to "negative".
 
Personally I think that first sentence is a canard, because the second is universally true. There is no such thing as a structured programming language; there are only structured programmers.

P.S. I am not referring to ST specifically here, but to all "structured" languages. One can write good and ugly program in ST, in LAD, in Java, whatever. The language itself is a tool and irrelevant; there is only the convenience, familiarity, knowledge and discipline of the coder.

[sorry, I keep expanding this post]

TL;DR - Random thoughts, possibly OT.

  • There is at least one amusing thread on this forum about various "temporary" hacks that were never replaced by a permanent solution, even after decades.
  • One of the forum members has a signature something like "There is never enough money to do it right, but there is always enough to do it twice."
  • Standards only work if people follow them, and if something deemed "necessary" cannot be accomplished within the standards, what do we expect is going to happen?
  • Does IEC 61131-3 define byte order in a REAL?
  • LAD is part of the IEC 61131-3 standard


My question arose from the post mentioning use of recursive calls and dynamic memory allocation which is not allowed, and I think they wrote "prohibited". PLCOpen lists degrees of "importance" , high, medium and low.

I think I'm mostly in agreement that it's the responsibility of the programmer and more so his/her employer to produce safe, reliable and overall well designed (there's another mine field) equipment.
But, I haven't decided if it's better to remove those restrictions for those who want to experiment and see where that takes them. Maybe an open source tool that allows for predefined number of recursion and a compiler capable of calculating required memory or any methods that combines the features some may want and the reliability necessary of real life industrial applications.

And have a subset for IEC compliant applications.

(Similar implementation already exist) .
To your questions and notes:
I don't know if IEC defines byte order in real but doubt it. It is most likely "implementation dependant". I missed the point?
I realize ladder is part of IEC, I am missing this point too.
 
Last edited:
In my experience and personal opinion, I don't care much what language is used in a program. Besides, I think there's a convergence going on. Some PLCs allow you to write a program in ladder, then drop a "rung" of ST (basically a text box with a scroll bar) in the middle, and keep going in ladder. Some other PLCs allow you to write short ST statements as input to ladder functions or function blocks. Even Rockwell has CPT and CMP blocks which are basically logical or mathematical ST blocks, because everybody agrees that for anything more complicated than simple arithmetic, lining up basic operation ladder blocks to get to the grand finale 15 instructions later is a pain.

Also, language preference will be coloured by the preferred vendor's implementation. Sometimes I think that when people say "this language blows" they are really thinking "this vendor's implementation of this language's logic editor blows". Sometimes people say ST isn't visual, and I think it's true in Rockwell's editor because you have to use a watch window to see the values of variables. Most other vendors have little bubbles that pop next to the variable names when online that show their current value (even colour-coded for boolean logic). I think that's no less visual than seeing power flow from "positive" to "negative".

Rockwell shows inline values in ST as of either version 30 or 31 of Logix Designer. I don’t remember which. I know it’s in v31 and I skipped over v30.

A lot of modern ST editors show inline values live. Some implement it adjacent to the tag and some implement it either above or below. I wrote an RSLogix 5000 clone (viewer only) in WPF around 10 years ago and added similar features in it. I also added embedded tag tables for larger data objects so you could open the object and explore the values right in the editor. I did the same for LAD. Those were the only two language implementations I made because that’s all I used.

I’ve used enough different platforms to feel confident in my assessment. I’ll say ST is one of the most consistent across platforms. Graphical language implementations tend to vary more than text.
 
Even Rockwell has CPT and CMP blocks which are basically logical or mathematical ST blocks, because everybody agrees that for anything more complicated than simple arithmetic, lining up basic operation ladder blocks to get to the grand finale 15 instructions later is a pain.

Oh and I hate those CPT and CMP instructions. It’s much better to format Boolean and numeric expressions for readability in ST vs having it all on one line and trying to match up parens.
 
My question arose from the post mentioning use of recursive calls and dynamic memory allocation which is not allowed, and I think they wrote "prohibited". PLCOpen lists degrees of "importance" , high, medium and low.

I think I'm mostly in agreement that it's the responsibility of the programmer and more so his/her employer to produce safe, reliable and overall well designed.......to be continued

That was me. Direct recursive calls are not allowed in TwinCAT but can be implemented using function block pointers. I’ve never done it in production. Only in tests. [edit: specifically, I was trying to go through SICP using TwinCAT instead of Scheme).

Recursive data structures and recursive FBs through pointers are both allowed and recursive algorithms can be written that way. Runtime memory allocation is also allowed and I’ve used that as well for creating appropriately sized tree structures.

Nothing wrong with that.

You know what else you can do in TwinCAT? Write unit tests...
 
Last edited:
Runtime memory allocation is also allowed and I’ve used that as well for creating appropriately sized tree structures.

Nothing wrong with that.

You know what else you can do in TwinCAT? Write unit tests...


I am aware of unit testing and they're not the only one.


To my knowledge dynamic memory allocation is not allowed on twincat3 except for some "router memory" in vision hardware which I only and very briefly read about yesterday after reading your post. Perhaps you may expound on that as you seem to have considerable knowledge of the platform.
 
I am aware of unit testing and they're not the only one.


To my knowledge dynamic memory allocation is not allowed on twincat3 except for some "router memory" in vision hardware which I only and very briefly read about yesterday after reading your post. Perhaps you may expound on that as you seem to have considerable knowledge of the platform.

I’m not any kind of expert in TwinCAT. I’ve used it casually since 2015 and I’ve used TwinSAFE as well as EL and EP I/O on and EIP gateway for the last year.

This is what I was talking about with runtime memory allocation though:
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/2529171083.html&id=

When I did it, I only did it at startup to initialize things that would otherwise be difficult to hard code fixed lengths and sizes for at compile time. This prevents the possibility of memory leaks. I would generally think that runtime memory allocation should be avoided and don’t want to suggest that I think it should be the standard memory allocation mechanism in a control system.

But it’s nice when you need it.
 
I’m bashing the idea that programs have to written in ways for non-programmers to read and use. Sorry. Not interested.


I've been studying MBSE for a few months and from my learning I have one question with regard to your statement, what drives your system design including programming; how do you validate the project?
 

Similar Topics

What ladder logic is required to have an HMI button that gives output when you push it then removes that output when you push it again? For...
Replies
9
Views
3,804
I will apologize in advance for this question. In a PLC scan I understand the inputs are read, then the PLC carries out a scan out the logic and...
Replies
11
Views
4,090
:banghead: I am a newbie trying PSIM and am facing difficulty with a counter in the Batch program. I observe that there is significance in the...
Replies
2
Views
2,164
Hello Everyone, I am brand new to PLC's (learned they even existed 3 days ago) and have gone through the tutorial on this site. I am a little...
Replies
4
Views
5,203
Please,: Explain the meaning of Scan cycle in a PLC when it is running a program?
Replies
2
Views
3,199
Back
Top Bottom