I am in love with structured text

[ganutenator]

Been using this language since 2006.

Plus, I love how I can write my own functions and put it in ladder and call different instances of said function.

I can't wait until I can do this in the lower priced plcs.

[sigmadelta]

The Siemens S7-1200 has SCL (Structured Control Language) which might be worth looking into. It's the smallest of the new S7 family of PLCs.

[LadderLogic]

What is a "lower-priced PLC"? You can use ST in moderatlely-priced Omron CJ series PLCs, not to mentioen fully IEC-61131 compliant Beckhoffs and Wagos. Or Phoenix Contact for a different flavor.

[Paullys50]

And you can write "functions" (AOIs in the AB world) in any of the other languages, it's not a result of ST.

[Archie]

Structured Text is a very powerful and useful language as is other PLC languages such as SFC. But it can also become your worst enemy.

It is easy to lose sight of an important aspect that a PLC can be good at.... that is the ease of troubleshooting and maintenance. Writing everything in structured text can become a nightmare to maintain and for others to work with.

For example. let's say "bubba", needed to know why his valve would not come on. He goes online and finds this:

Valve:=(SW1 AND LS1) OR ((LS2 and SW1) OR LS3);

Most likely he would just turn off the computer and brute force the troubleshooting or go find and engineer.

Now let's say he finds this:

     SW1     LS1                                            Valve
--+--][-------][---------------------------------------------()--
  |                |
  | LS2      SW1   |
  +-][-------][----+
  |                |
  | LS3            |
  +-][-------------+

Within seconds he will be able to easily locate the problem.

The language choice also applies the other way around. Let's say you need to search through some FIFOs to see if a certain item exists. In ladder this would be a nightmare. Bubba would never figure it out, worst yet the original programmer would struggle with it. But then write it in ST and turn it into a function block with a good descriptive name and inputs/outpus,then there will be no need to try to figure out the code because it will be encapsulated in an easy to figure out function block.

A good programmer is not one that just gets something to work, nor does it the fastest. A program written by a good programmer will not only work properly, but will also be easy to maintain by the next person who uses it.

So my point is, having and using the tools properly makes a good programmer. But losing sight of the big picture and abusing the tools, can make a not so good programmer.

[shooter]

almost all you can do in ST is also possible in Ladder.
and yes most i write in ST too, however i use all 61131.

[mk42]

Originally Posted by Archie

For example. let's say "bubba", needed to know why his valve would not come on. He goes online and finds this:

And that, right there, is the real problem. If Bubba can't troubleshoot that machine from the information on the HMI, the programmer hasn't done his job properly. You should only need to go online to debug code, not to troubleshoot the machine sequence or hardware.

I do agree that if bubba is expected to make changes to the code, SCL is a choice.

[AshleyParr]

I'll admit that writing the code with structured text or similar is great, can make some tasks a lot easier & enable you to code more efficiently, BUT...

It's 3am & feeling shattered, I know I'd rather troubleshoot ladder. That's why when we wrote code for customers we tried to keep it in ladder so they could understand it easier.

Ash

[willxfmr]

Originally Posted by Archie

For example. let's say "bubba", needed to know why his valve would not come on. He goes online and finds this:

Valve:=(SW1 AND LS1) OR ((LS2 and SW1) OR LS3);

Most likely he would just turn off the computer and brute force the troubleshooting or go find and engineer.

Now let's say he finds this:

     SW1     LS1                                            Valve
--+--][-------][---------------------------------------------()--
  |                |
  | LS2      SW1   |
  +-][-------][----+
  |                |
  | LS3            |
  +-][-------------+

Within seconds he will be able to easily locate the problem.

A good programmer is not one that just gets something to work, nor does it the fastest. A program written by a good programmer will not only work properly, but will also be easy to maintain by the next person who uses it.

So my point is, having and using the tools properly makes a good programmer. But losing sight of the big picture and abusing the tools, can make a not so good programmer.

As the resident 3rd shift "Bubba", I have to say you nailed it right one the head. I have told more than one programmer that they don't have to write it well, but if they don't, they need to keep their phone next to their bed so I have someone to call at 2 AM when their "clever" programming can't be deciphered by a tired and always under caffeinated Bubba.

Will.

[Paullys50]

Originally Posted by willxfmr

...they need to keep their phone next to their bed so I have someone to call at 2 AM when their "clever" programming can't be deciphered by a tired and always under caffeinated Bubba.

Curious, how often is it a programming issue versus something else?

Generally speaking, my experience when I have gotten calls from "bubba", it's usually because "bubba" goes online with a PLC and uses this as his primary troubleshooting tool and quickly abandons everything else (including looking at the alarm information on the HMI!). They can't follow something in the PLC so they pass the buck and call to me. I arrive and and perform the basic troubleshooting "bubba" should have done in the first place and point out the mechanical or electrical component failure that is often the cause.

[Phil Buchanan]

Originally Posted by mk42

And that, right there, is the real problem. If Bubba can't troubleshoot that machine from the information on the HMI, the programmer hasn't done his job properly. You should only need to go online to debug code, not to troubleshoot the machine sequence or hardware.

I have to agree with you and disagree with you both at the same time.

Yes what you have stated should always be the goal 100% of the time but it's not always realistic. On small widget machines with several hundred I/O then yes I agree but when you have huge process lines like I work with that have 30,000 I/O points, Multiple controller, Distributed HMI systems,etc then this goal is much harder to achieve with time and budget constraints.

Building enough diagnostics in the HMI system to be able to find all possible problems and display on the HMI to the point that program access with a laptop is not needed for troubleshooting would increase the project cost by 150% and no one is going to pay that. They will go to the competition.

As I said it's the goal to strive for but sometimes it's just not feasible. Just my 2 cent opinion

[MrDnesco]

I worked at this OEM back in 2002, and the company brain trust decided to use the GE S2K servo drive to control the servo motion and all the machine control as well.... I told them repeatedly not to use it because it had to be programmed in all structured text and most maintenance electricians wouldn't know how to troubleshoot it.... But they went with it and it made the electrical engineers life a nightmare.... It was fun to sit back and watch him struggle... Eventually we went with a PLC and everything was written in Ladder... But we struggled with that system for a few years...

[Peter Nachtwey]

MrDnesco, you are pointing out is a failure in the programming and implementation of ST. Ladder is horrible for motion control. Structured text is much better than ladder when dealing with velocities, position, pressures etc. As for debugging, our motion controller uses a combination of a state machine and ST. The state machine forces the user to organize their program in steps that do something then wait will some event occurs before going to the next step. This makes debugging simpler because one always knows what step the problem is in. On top of that we log when variables were changed and when the task went from one step to another. This provides a trace almost like an in-circuit emulator. Now what ladder language has that? None that I know of. Anything complex I can debug faster with our controller than in a PLC. Another feature is that we can have up to 16 traces or pens in our graphs or trends. This allows use to plot variables graphically so we and see how they change together. If there is a problem you can find the time and then go into the event log at the same time to see what happened. Yes, Rockwell has trends but can the update 16 pens at 250 microsecond intervals? If not fast input changes can come and go and not be detected.
Finally, there are thing bugs or faults that show up rarely. Some faults may take days to appear. What do you do with a PLC? With our controller we can setup a trigger on the fault and it will stop the gather of data after at a point selectable by the user so he can see what led up to the fault and would happened after the fault. This is like a data analyzer.
I know of no PLC that has these functions.
It isn't the language. Its how it is implemented. Having trained programmers helps too.

[ganutenator]

wow, I guess I expected this.

Reminds me of arguments of why I didn't upgrade to windows 10. Different unrelated argument, but same feelings.

I love ladder for boolean logic. Still easier to look at.

But I'm in a unique position where I am writing code for an OEM, and no one gets to see the code.

And yes, if you can't troubleshoot it from the hmi, then I didn't do a very good job w/ the hmi.

But in my defense, I still comment the heck out of ****.

[ganutenator]

didn't care for the phoenix for 2 reasons:
1) renaming tags
2) modbus tcp