You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

Reply
 
Thread Tools Display Modes
Old April 23rd, 2016, 06:21 AM   #1
ganutenator
Member
United States

ganutenator is offline
 
ganutenator's Avatar
 
Join Date: May 2002
Location: kansas
Posts: 1,266
I am in love with structured text

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.
  Reply With Quote
Old April 23rd, 2016, 08:16 AM   #2
sigmadelta
Member
Canada

sigmadelta is offline
 
Join Date: Apr 2016
Location: From Canada - Living in Bulgaria
Posts: 1,656
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.
__________________
Automation Programmer
PLC / HMI / SCADA / SQL
New Systems, Modifications
System Upgrades & Conversions
Siemens EPROM & EEPROM Service
------------------------
Visit: contrologica.com
Email: info@contrologica.com
  Reply With Quote
Old April 23rd, 2016, 08:54 AM   #3
LadderLogic
Member
United States

LadderLogic is offline
 
LadderLogic's Avatar
 
Join Date: Jun 2003
Location: Chicagolandia
Posts: 1,397
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.
__________________
Don't trust, don't fear, don't beg...
  Reply With Quote
Old April 23rd, 2016, 09:15 AM   #4
Paullys50
Lifetime Supporting Member
United States

Paullys50 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 2,175
And you can write "functions" (AOIs in the AB world) in any of the other languages, it's not a result of ST.
  Reply With Quote
Old April 23rd, 2016, 09:28 AM   #5
Archie
Member
United States

Archie is offline
 
Join Date: May 2002
Location: Orangeburg, SC
Posts: 1,938
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:
Code:
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:
Code:
     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.
__________________
Expectations lead to disappointment. Appreciation leads to satisfaction.

AdvancedHMI - HMI Software without the license key hassles
  Reply With Quote
Old April 23rd, 2016, 10:08 AM   #6
shooter
Member
Netherlands

shooter is offline
 
shooter's Avatar
 
Join Date: Sep 2002
Location: duketown
Posts: 2,711
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.
__________________
shooter@home.nl
skype shooter paul.deelen
Computer Shooter
Paul Deelen
J. Wassenaerstraat 29
NL 5224 GG 's-Hertogenbosch
+31653300739
  Reply With Quote
Old April 23rd, 2016, 11:49 AM   #7
mk42
Lifetime Supporting Member
United States

mk42 is offline
 
Join Date: Jun 2013
Location: MI
Posts: 2,710
Quote:
Originally Posted by Archie View Post
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.
  Reply With Quote
Old April 23rd, 2016, 12:26 PM   #8
AshleyParr
Member
United Kingdom

AshleyParr is offline
 
AshleyParr's Avatar
 
Join Date: Dec 2008
Location: Midlands, UK
Posts: 180
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
  Reply With Quote
Old April 23rd, 2016, 12:41 PM   #9
willxfmr
Lifetime Supporting Member
United States

willxfmr is offline
 
willxfmr's Avatar
 
Join Date: Nov 2013
Location: Wisconsin
Posts: 436
Quote:
Originally Posted by Archie View Post

For example. let's say "bubba", needed to know why his valve would not come on. He goes online and finds this:
Code:
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:
Code:
     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.
__________________
“Now will come the nay-sayers with all the reasons why you shouldn't do this. Some of them are teachers, and some of us are doers. Besides, you have got to let the smoke out of this equipment every now and then, or it starts to clog up the chimney.”
~Lancie1
  Reply With Quote
Old April 23rd, 2016, 01:04 PM   #10
Paullys50
Lifetime Supporting Member
United States

Paullys50 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 2,175
Quote:
Originally Posted by willxfmr View Post
...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.
  Reply With Quote
Old April 23rd, 2016, 01:36 PM   #11
Phil Buchanan
Lifetime Supporting Member
United States

Phil Buchanan is offline
 
Phil Buchanan's Avatar
 
Join Date: Jun 2015
Location: Atlanta, Georgia
Posts: 547
Quote:
Originally Posted by mk42 View Post
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
  Reply With Quote
Old April 23rd, 2016, 02:37 PM   #12
MrDnesco
Member
United States

MrDnesco is offline
 
Join Date: May 2013
Location: Milwaukee
Posts: 6
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...
  Reply With Quote
Old April 23rd, 2016, 03:13 PM   #13
Peter Nachtwey
Member
United States

Peter Nachtwey is offline
 
Peter Nachtwey's Avatar
 
Join Date: Apr 2002
Location: United Welfare States of America
Posts: 7,414
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.
__________________
"Living is easy with eyes closed, misunderstanding all you see...." Strawberry Fields Forever, John Lennon
  Reply With Quote
Old April 23rd, 2016, 03:33 PM   #14
ganutenator
Member
United States

ganutenator is offline
 
ganutenator's Avatar
 
Join Date: May 2002
Location: kansas
Posts: 1,266
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 ****.

Last edited by ganutenator; April 23rd, 2016 at 03:51 PM.
  Reply With Quote
Old April 23rd, 2016, 03:36 PM   #15
ganutenator
Member
United States

ganutenator is offline
 
ganutenator's Avatar
 
Join Date: May 2002
Location: kansas
Posts: 1,266
didn't care for the phoenix for 2 reasons:
1) renaming tags
2) modbus tcp
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Structured Text Programming Andreik LIVE PLC Questions And Answers 12 March 19th, 2016 10:44 AM
TwinCAT Structured Text Programing (LOOP) Sohaib28 LIVE PLC Questions And Answers 5 November 19th, 2015 01:36 PM
Mitsubishi Q Series Structured Text cobra_phil LIVE PLC Questions And Answers 0 April 24th, 2012 10:01 AM
Structured Text & RSLogix - good reference books & docs? ChrisOfMaryland LIVE PLC Questions And Answers 4 November 4th, 2009 01:10 PM
Structured Text for automating experiments? I'm new... ChrisOfMaryland LIVE PLC Questions And Answers 1 November 4th, 2009 12:40 PM


All times are GMT -4. The time now is 10:12 AM.


.