Wow! I LOVE getting these kinds of enthusiastic responses. And just to show my appreciation, I'm going to try to reply to all of you!
dmargineau:
===========
You had cited some Ladder (LD) instructions not available in Structured Text (ST). But then 'nhatsen' seemed to refute that, listing ST equivalents. You replied that the structured text instructions were "not equivalent", but could "achieve similar results". How do you square those two statements? Aren't they equivalent if they achieve similar results? The goal is to write a program that performs a specified function, right?
Also, later in the thread, you said programming instructions are "conveying information/commands from the user to the operating system of the automation controller". This is not true in a conventional computer (maybe PLCs are different, I don't know). Typically, the instructions (in whatever language you are using) are compiled down to assembly instructions (where you can see the individual native CPU registers selected to execute each instruction). Below even *that* are the machine-level instructions (that you never see), which execute at the 'microprogram' level, driving the actual hardware to move data to/from memory and in/out of the processor registers.
The Operating System is just another piece of software that runs at the Executive (or Privileged) level to manage multiple "Task" level applications, giving them CPU control or executing privileged-level instructions on their behalf (amongst other things).
just the cowboy:
===============
It turns out, that at this facility at least, Maintenance and Production *never* look at programming software. Neither have access, know where anything is, and have never even *tried* to feign interest. Now, it's possible that could change someday. Never is a long time. But I have to admit - I've never written logic for someone else who wasn't also an engineer or someone who would understand.
RET:
====
This is an in-house (OEM) project, so no contractor issue here. But if I *was* a contractor, I would do whatever the customer wanted ... for obvious reasons.
Phrog30:
========
See RET response above. And with regards to your tiff with Epy ... I *never* write 'complicated' code. Every programmer should strive to write logic that balances clarity with efficiency. And that includes good documentation that describes WHY something is being done (instead of WHAT). Structured Text allows for free-form endline comments, which I hold dear to my heart. The commenting model in ladder leaves a LOT to be desired, IMO.
Also - it IS, in fact, considered bad programming practice to use JUMP-to-LABEL type structures in your logic (aka "GOTO"). I was trained on this right out of college on my first project by a senior software engineer. Not entirely sure WHY ... because the compiler will generate a JMP-to-label on its own anyway (for any loop). I think it's just considered bad style. And all these years, I've *never* used a GOTO statement in any program I've ever written.
Lynx777:
========
Well, Structured Text is fairly new to the Industrial Controls programming world, and with Ladder so firmly entrenched already for years, that's pretty much what most programmers in this industry know and are used to. And if you don't see a compelling reason to change to another model, I can understand the negative reaction to coming across it. Probably thinking ... 'oh c'mon ... why did this guy use Structured Text when 99% of programs are written in Ladder?"
nhatsen:
========
Nice job pointing out those equivalent Structured Text instructions. I get the impression here that Structured Text is not fully understood, or hasn't *really* been properly compared to Ladder because most Ladder programmers don't see a reason to change to it. And I can understand that. If what you have is working for you, why change it up, right?
Paully's5.0:
============
You're right. No ControlLogix experience, very very little PLC coding (2 or 3 apps years ago), no love for Ladder, so I'm looking to leverage what I prefer to do with what the platform allows. When it gets turned over to someone else, they'll just have to learn it. It's not like this is a one-of-a-kind programming language. "C" is very well known in the programming world, and more and more 'conventional' programmers must be entering this Industrial Controls field (or Rockwell is trying to attract them) ... otherwise why would Rockwell go to the trouble of adding that language to their programming IDE?
Also, regarding looping in logic, it's done everywhere, in every program, whether you program it in or not. If you call a subroutine, the compiler will generate an instruction to load a register with the address of the next instruction, then generate a jump to a label where your subroutine is. When the subroutine completes, the compiler will restore the Program Counter with the saved address and jump back. Not sure exactly *what* PLCs do with a FOR instruction, but it *looks* inefficient to me in that it performs repeated subroutine calls, which has the overhead I mentioned above (and is therefore slow-er). Now maybe PLCs have more onboard registers to handle this more efficiently, I don't know. Never seen any internal architecture of PLC hardware.
As for "farming out" this project. I'm pretty sure I can handle this program, however, I will be fighting with the idiosynchrasies and weirdisms of Rockwell, so that's going to slow me down a bit. Let me program this on a platform I want, and it's a piece of cake.
James Mcquade:
==============
About 100 PLC apps here. All Ladder. Mostly Allen-Bradley, some GE, a few outliers on skids, but most are not changed or touched much (or if at all).
No specs/preference here for any particular programming platform. Management will let me do whatever I want. They don't care. Just make it work. No maintenance involvement whatsoever here. Automation is the sole owner.
ASF:
====
As I stated above. This is "in-house" project, no contractor. And I'll say it again - nobody should be looking at these programs who doesn't understand programming. And it they *DO* understand programming, then they can adjust to learning something new, which we all have to do from time to time.
Epy:
====
I don't write programs to be unreadable by others. Just the opposite. That's how I was trained coming out of college. Clean and clearly-written source code. Personally, I think Ladder is the worst programming model I've ever seen. But maybe I haven't seen good Ladder logic, either. I just *hate* looking at Ladder logic and seeing rungs serpentine around and around ... to me, that's very hard to look at. I also tend to see a LOT of repeated logic on rungs, but maybe that's just bad Ladder Logic programming, I don't know. And the commenting is lousy. You've got those same tag names popping up all the time ... and you can add rung comments, but it's just not the same as end-line comments in "C". Ladder programs seem to go on and on for 700, 800, 1000 rungs, and I just look at all that and I say ... I betcha I could write this much more efficiently, and you'd be able to read it much more clearly, in Structured Text. You could also print it out very neatly and read it like a book. Ladder is a hodgepodge of intermingled constructs. It started out as a good idea, but then it was extended, but without breaking free of that "Power Rail" model. I just don't care for it at all. It really looks like something that was extended and extended and extended until someone realized it couldn't continue like that ... and so Structured Text was introduced.