I am in love with structured text

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.

On equipment that has been up and running, I'd say it's less than 1% of the problems are directly related to the program. Where I work it's about a 50/50 mix of failed devices and operator error. And you're right, basic troubleshooting will solve most of the problems. However, since our process covers 20 or so different processors spread out over 4 floors with each one passing information and permissives, often the only way to resolve the operator error problems is to track down what button got pressed when it shouldn't have, or not pressed when it needed to be. Those are the times that bad (in my opinion) programming raises serious havoc. Our system uses a lot of indirect/indexed addressing, and tons of messages between processors. Unfortunately the person that did 90% of the programming feels that things like rung comments, and tag descriptions are a waste of time. Combine that with devices that are labeled one thing in the field, something else on the HMI, and some cryptic abbreviation in the program, and you get one grumpy Bubba that is only all too happy to call you at 2 AM to let you know that things are not going well. And don't get me started on the "testing something new" without telling anyone that you are doing it or why. Nothing is more fun than having one of your good operators call you and say, "Well I've never seen this before...."


Will.
 
Last edited:
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.

I can do all of this w/ the M340 and Indusoft.
 
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.

It's something that would have to come from the customer's spec/expectations, not pushed up from the OEM/Integrator. You're 100% right, if the customer doesn't want it, they won't pay for it.

I've always been of the opinion that diagnostics fall into the category of lowering "Total Cost". If you get the line up and running faster, it'll pay for itself. However, that requires managers to think of next year instead of this quarter, and that doesn't happen too often.
 
I know of no PLC that has these functions.

The in-line automatic step/value tracking sounds pretty unique, but at least some PLCs can do the trending you mention. In the Siemens world, the newer 1200/1500 family can have multiple simultaneous trends active, and each trend can be either triggered immediately or have pre/post logs after a bit trigger (your rare bug scenario). The programming software is needed to set up the trace, but it isn't needed for the actual logging. It can be set up to log at a variety of intervals, as fast as the cpu can scan (the some models can do sub millisecond cyclic tasks/OBs, though I'm not sure if they can get down to 250us).
 
This thread boils down to: Use the appropriate tools for the task.

That being said, there's this one moment I won't forget soon.
We had our very first RSLogix production machines installed. So training was needed. Someone found local engineering firm that does Rockwell stuff and is certified trainer. They sent over one of their more experienced programmers to give us some training. Training went rather swift, you could tell the guy knew the platform.
Then he opened a ST routine. He stared at it, then closed it again. Then said: I have no idea what this routine does. We don't use ST.
And the training resumed.
 
This thread boils down to: Use the appropriate tools for the task.

That being said, there's this one moment I won't forget soon.
We had our very first RSLogix production machines installed. So training was needed. Someone found local engineering firm that does Rockwell stuff and is certified trainer. They sent over one of their more experienced programmers to give us some training. Training went rather swift, you could tell the guy knew the platform.
Then he opened a ST routine. He stared at it, then closed it again. Then said: I have no idea what this routine does. We don't use ST.
And the training resumed.

Nope, this thread boils down to : take a look at the Siemens S7-1200
Am looking for plcs around $300 that don't force me into ladder only.
I care not about your ignorance to a language.
 
Holy **** dude, dial that arrogance down a few notches.

I was struck by the inappropriate bluntness of the post you are replying to. It tells me a lot about this individual.

I hope he responds in a way that is appropriate for someone who is asking for help, though based on the post that started this thread, I wonder if he is *really* asking for help.

We'll see...
 
We almost exclusively use ControlLogix at work. Structured text is nice for program structuring at times, but for lots of data transfer and manipulation, it is sometimes 3x as slow as equivalent ladder logic. When I write a piece of logic, I will always check to see which language will execute it faster, especially when that logic runs often. Just something to watch out for.
 
Enough of this ****.

There are good implementations and poor implementations. Some companies wrote a quick and dirty ST just to say they have it for marketing purposes. It is clear that some of you have found some pretty bad implementations of ST.

We almost exclusively use ControlLogix at work. Structured text is nice for program structuring at times, but for lots of data transfer and manipulation, it is sometimes 3x as slow as equivalent ladder logic. When I write a piece of logic, I will always check to see which language will execute it faster, especially when that logic runs often. Just something to watch out for.
This is an implementation problem. Ladder must load and store data for every block. A ST line of code can be the equivalent of many ladder blocks and not have the need to store intermediate values.

See the screen shoot of some ST code, left, and the code it generates, right.
This is the part that is shown at the left at index 48
Code:
_Axis[].IntGain := 10.0 * Lambda **4.0 * InvGainAlphaMu;
_Axis[].PropGain := 40.0 * Lambda **3.0 * InvGainAlphaMu;
Index of offset 48-59 does lots of calculations and only one store at the end.
The same goes for the next line starting at index 60-70.
If this were broken into blocks the results of each operation would need to be stored, not just the results of whole equation.
In addition, look at how lambda is being raised to the 4th power in the first line and to the 3rd power in the second line. A PLC programmer would probably use a XPY function which is horribly inefficient because it involves the use of the exp(x) and ln(x) function which are both power series. We don't have a full implementation of ST but what we have implemented as done with a emphasis on speed and optimization. We can tell that even though the exponents are floating point numbers they still represent integers so there is no need for a XPY function. On top of that we implement multiplying the numbers together efficiently.

WordCode.jpg
 
Last edited:
I was struck by the inappropriate bluntness of the post you are replying to. It tells me a lot about this individual.

I hope he responds in a way that is appropriate for someone who is asking for help, though based on the post that started this thread, I wonder if he is *really* asking for help.

We'll see...

seriously?
 

Similar Topics

My thinkpad T420 is freaking awesome, but it is time for an upgrade. Any suggestions?
Replies
45
Views
17,943
Just had another run-in with a highly trained industrial engineer. I actually asked his boss in front of him if engineers had a college course on...
Replies
33
Views
8,038
Love this plc and software now. Anyone else? I feel I could answer any question on this device now.
Replies
12
Views
5,002
I had a project where I had spec'd a PanelView C300 (2711C-K3M) I got it working and it was functional, but I needed a few more options, and I...
Replies
37
Views
26,773
Back
Top Bottom