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.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


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

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old April 17th, 2017, 01:22 PM   #1
SoftwareJanitor
Member
United States

SoftwareJanitor is offline
 
Join Date: Dec 2016
Location: Southeast
Posts: 116
ControlLogix: Ladder vs. Structured Text

With this upcoming project, since I am really a "C"/"C++" programmer and *not* a PLC/Ladder programmer, I would like to use Structured Text for my logic.

So just for the fun of it, I re-wrote a couple of ladder programs here in "C" just to see what they'd look like, and it turned out to be a thousand IF statements with some embedded PIDs and Timers (an oddball-looking program, I'd say).

Anybody here using Structured Text with ControlLogix? Can the entire thing be written in Structured Text, or do you still have to cross over to another model in order to use certain macros?
  Reply With Quote
Old April 17th, 2017, 01:51 PM   #2
dmargineau
Lifetime Supporting Member
United States

dmargineau is offline
 
dmargineau's Avatar
 
Join Date: Dec 2011
Location: Midwest
Posts: 2,255
Most of LAD programming instructions are available in ST, however, some are not; if your application requires OSRs, OSFs, TONs, TOFs, RTOs, CTUs, CTDs ( just to name a few), you will also need to implement LAD programming routines in addition to ST.

I/O processing with ST is like commuting to work using a thirty foot mobile home...

Last edited by dmargineau; April 17th, 2017 at 01:53 PM.
  Reply With Quote
Old April 17th, 2017, 01:52 PM   #3
just the cowboy
Member
United States

just the cowboy is offline
 
just the cowboy's Avatar
 
Join Date: Nov 2013
Location: Pa
Posts: 249
Maintenance and production will hate you

If you do it in what you want, maintenance and production will hate you. In a real life troubleshooting world 1000's of IF statements will make your head spin. A ladder that is broken down to a area of machine will make it easy to troubleshoot. That is why they are so widely used, ST is great for a complex TASK, but thats about it.
__________________
Work safe, have fun, don't die
  Reply With Quote
Old April 17th, 2017, 01:55 PM   #4
RET
Member
United States

RET is offline
 
Join Date: Feb 2015
Location: Houston, TX
Posts: 211
Only fairly involved math operations that require several steps. Other than that, no.

Probably good idea if you're in integrator/contractor and your trying to obfuscate your code to ensure call backs and more billable hours from a customer (not that it can't be done in ladder). But either way, after that you'd be on my blacklist.
__________________
This statement is false.
  Reply With Quote
Old April 17th, 2017, 01:55 PM   #5
Phrog30
Member
United States

Phrog30 is offline
 
Join Date: Dec 2006
Location: Montgomery, Alabama
Posts: 271
Some of the worst PLC programs I've seen were written from "true" programmers. Most plant personnel will not understand anything but ladder. Perhaps you are good at c programming, but there is a trick to ladder and it really only comes with experience. Just remember the customer in whatever you choose.
  Reply With Quote
Old April 17th, 2017, 02:03 PM   #6
Lynx777
Lifetime Supporting Member
United States

Lynx777 is offline
 
Join Date: Aug 2008
Location: Indiana
Posts: 29
I have never programmed in structured text, though I've done troubleshooting and rework with quite a few programs that have it. In my experience there is always a mix of text and ladder in a program. I've been told by a couple of programmers that I know that use structured text, that you "can" do the whole thing in text, but it's easier to go with ladder for some things.

From my viewpoint, (as the guy that normally comes in later on to repair or modify the original equipment) if I saw that the entire program was done in structured text, you would be able to hear me cussing from five miles away. That's just my opinion though.
  Reply With Quote
Old April 17th, 2017, 03:28 PM   #7
nhatsen
Member
Venezuela

nhatsen is offline
 
Join Date: Oct 2010
Location: Venezuela
Posts: 622
Quote:
Originally Posted by dmargineau View Post
... if your application requires OSRs, OSFs, TONs, TOFs, RTOs, CTUs, CTDs ( just to name a few), you will also need to implement LAD programming routines in addition to ST.
Those instructions have an equivalent on ST:

OSR -> OSRI
OSF -> OSFI
TON -> TONR
TOF -> TOFR
RTO -> RTOR
__________________
"If you can't solve a problem, then there is an easier problem you can solve: find it." (George Pólya)
  Reply With Quote
Old April 17th, 2017, 03:46 PM   #8
dmargineau
Lifetime Supporting Member
United States

dmargineau is offline
 
dmargineau's Avatar
 
Join Date: Dec 2011
Location: Midwest
Posts: 2,255
Quote:
Originally Posted by nhatsen View Post
Those instructions have an equivalent on ST:

OSR -> OSRI
OSF -> OSFI
TON -> TONR
TOF -> TOFR
RTO -> RTOR
They are not equivalent; you could use them to achieve similar results, however, functionality and "handling" differ.
  Reply With Quote
Old April 17th, 2017, 03:48 PM   #9
Paully's5.0
Lifetime Supporting Member
United States

Paully's5.0 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 1,892
The problem is that the OP doesn't know the Logix platform very well at all, and is starting from scratch on a rather large project resulting in a non-traditional approach.

ST has it's place, and for the fun of it I've taken logic used previously done in ladder on a ControlLogix for use in batching and re-did a lot of it in ST. The objective was to learn a bit of Codesys, in which I decided the ladder editor on that platform wasn't great so I decided what the hell, learn some Codesys and mess around more with ST.

Because of my experience in this area, and having good structured methods to begin with applying that knowledge to ST came pretty easily, I did have some challenges but I did find some advantages too it, which was more due to the Codesys platform. Primarily the ST editor is much nicer and I could define a simple function (No Logix equivalent) rather than function block (AOI). I even built in an equivalent to the Logix "Phase Manager" functionality. I was actually pretty surprised, the ST logic is pretty "clean" however this was due to already working from established standards and methods of handling large process systems.

So yes, it can be done. But be prepared for being responsible for this 100% even 1-2-5yrs after the fact.
__________________
"Comments should be like a mini-skirt... long enough to cover the essentials but short enough to keep your interest." - Uptown47
  Reply With Quote
Old April 17th, 2017, 04:25 PM   #10
James Mcquade
Member
United States

James Mcquade is offline
 
Join Date: Oct 2007
Location: Tennessee
Posts: 1,867
this is what I would do.

See what programs are on the plant floor - ladder versus structured text.
find out how many maintenance guys know structured text and are comfortable with trouble shooting.

see what the company specification and requirements are for programs.
get with management, engineering, and maintenance and get an agreement on how to proceed.

if they say ladder, ladder it is.
if they want structured text, then st it is, and if no one in maintenance can work on it, and production suffers, everyone in the meeting gets the blame, not just you. BUT, you will be the one getting all the calls!

Remember, maintenance can be your best friend or your worst nightmare!
you can't just throw something at them and expect them to work on it, you need to work with them and explain things.

james
  Reply With Quote
Old April 17th, 2017, 05:35 PM   #11
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,165
I have customers that outright ban ST in their procurement specification.

I have other customers that will accept ST as long as the price your company is quoting includes 24/7 remote troubleshooting support for 5-10 years after the machine is purchased for any issues that can't be immediately diagnosed using the HMI.

I have customers that couldn't care less what language you program your machine in, as long as it works.

I have customers that will have their technicians review your code as soon as you hand over the job, and if it's poorly written (no matter what language you chose), your company will not be favourably looked upon for the next round of tenders.

The common theme here is that it makes no difference what I like doing inside my PLC, I do what the customer wants. They're the ones paying me to do it, and if they don't like what I'm doing, they don't have to pay me.

If your customer will accept ST, and the resulting ST code is clear, concise, and easy to follow for a suitably skilled maintenance technician (who I can almost promise you, will not be a C++ programmer), then go for your life. If not, you'd have to spend a long time convincing me that it's a good idea.

Also:
Quote:
Originally Posted by dmargineau
I/O processing with ST is like commuting to work using a thirty foot mobile home...
This just made my morning
  Reply With Quote
Old April 17th, 2017, 06:50 PM   #12
Epy
Lifetime Supporting Member
United States

Epy is offline
 
Epy's Avatar
 
Join Date: Jul 2012
Location: Allen-Bradley Valley
Posts: 351
Quote:
Originally Posted by Phrog30 View Post
Some of the worst PLC programs I've seen were written from "true" programmers. Most plant personnel will not understand anything but ladder. Perhaps you are good at c programming, but there is a trick to ladder and it really only comes with experience. Just remember the customer in whatever you choose.
Some of the worst programming I've ever seen was from "good" PLC programmers. Don't know how many times I've seen people either use LBL/JMP loops or actually write out the individual COPs/MOVs when they have to shift arrays.

I think your strategy depends on your industry. There are some places where it is expected that the customer's employees will tinker in your program. In others, such as OEM, it's the complete opposite. You don't want to make it easy for people to tinker in your program in the first place.
__________________
Quote:
Originally Posted by ganutenator View Post
customers:
I don't know how to do it so it must be easy
  Reply With Quote
Old April 17th, 2017, 08:04 PM   #13
Phrog30
Member
United States

Phrog30 is offline
 
Join Date: Dec 2006
Location: Montgomery, Alabama
Posts: 271
Quote:
Originally Posted by Epy View Post
Some of the worst programming I've ever seen was from "good" PLC programmers. Don't know how many times I've seen people either use LBL/JMP loops or actually write out the individual COPs/MOVs when they have to shift arrays.

I think your strategy depends on your industry. There are some places where it is expected that the customer's employees will tinker in your program. In others, such as OEM, it's the complete opposite. You don't want to make it easy for people to tinker in your program in the first place.
Not that you will care, but not much I agree with in your post. So using lbl/jmp is not good practice? That's ridiculous. Intentionally making a program complicated to prevent tinkering is even more stupid. You don't want tinkering, try a password.
  Reply With Quote
Old April 17th, 2017, 08:19 PM   #14
LadderLogic
Member
United States

LadderLogic is offline
 
LadderLogic's Avatar
 
Join Date: Jun 2003
Location: Chicagolandia
Posts: 1,223
I should say that in my experience "jumping" the regular program scan order is considered in the PLC world just as bad practice as using GO TO statement used to be considered in Basic, Visual Basic etc. Each has its use but better to be avoided for clarity.

Modern PLC processors are typically fast enough so not to worry about the execution times and not to skip sections of the code with jumps. Just my two cents.
__________________
Don't trust, don't fear, don't beg...
  Reply With Quote
Old April 17th, 2017, 08:28 PM   #15
Phrog30
Member
United States

Phrog30 is offline
 
Join Date: Dec 2006
Location: Montgomery, Alabama
Posts: 271
Quote:
Originally Posted by LadderLogic View Post
I should say that in my experience "jumping" the regular program scan order is considered in the PLC world just as bad practice as using GO TO statement used to be considered in Basic, Visual Basic etc. Each has its use but better to be avoided for clarity.

Modern PLC processors are typically fast enough so not to worry about the execution times and not to skip sections of the code with jumps. Just my two cents.
If I want to create a loop in ladder I will use a jmp/lbl. So, let me guess, looping is bad practice?
  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
Which programming method is better - ladder logic or structured text sinha_nsit LIVE PLC Questions And Answers 32 February 29th, 2016 11:47 AM
RS Logix Structured Text JasonWade LIVE PLC Questions And Answers 22 July 28th, 2014 04:19 PM
why use structured text and function block over Ladder spidermonkey LIVE PLC Questions And Answers 46 January 8th, 2013 10:02 AM
Structured Text on a PLC-5 antjon1 LIVE PLC Questions And Answers 6 March 30th, 2006 01:05 PM
Documentation on Structured Text cmulder LIVE PLC Questions And Answers 13 June 11th, 2003 10:10 AM


All times are GMT -5. The time now is 08:38 PM.


.