Structured Text?

[shooter]

a library can have type structures visualisations variables etc.
so just copy will not work all the time.
with oscat it is possible to cut and paste in the ST however it will need some functions as it is a collection of functions.
and yes you can copy the demo.

 

[darnbar]

Function blocks can be created using any of the available programming styles. You don't have to use ST.

that's what I was going to say

What industry are you in? What is the technical level of people who could use or look at this for troubleshooting purposes?

Hi guys thanks for the replies. I'm doing a project for a degree so I can chose what programming language I use.It's just most guides,tutorials on youtube and the OSCAT libraries are based on ST so I thought it would be beneficial to have an understanding of it.Though I will look at using different programming language to see if it will make things easier.

a library can have type structures visualisations variables etc.
so just copy will not work all the time.
with oscat it is possible to cut and paste in the ST however it will need some functions as it is a collection of functions.
and yes you can copy the demo.

I sent you a PM detailing the problem if you wouldn't mind taking a look at it,if you get a chance thanks in advance.

 

[rebelwithacause]

Structured text is by far the most powerful/capable of IEC languages (yes, I just heard you ladder guys groan). You don't need to know or understand C language to use it. I'm not a C guy, and I also can't do what I want in ladder or FBD, so I do EVERYTHING in ST. You can always call your ST code in LD/FBD/etc as a POU or FB.

Once great thing about it, is that it's text, so if you change PLC vendors, a simple copy/paste gets you rolling in seconds. Also, ST is great if you are into FOR loops, or CASE statements. Codesys based PLCs probably have the most examples out there. Just google "codesys structured text"

If you can understand the below code, then you can do ST.

Silly application, but lets say you want to count to 90 quickly, then count slowly after that.

IF myCounter < 90 THEN
myCounter := myCounter + 10;
ELSE
myCounter := myCounter + 1;
END_IF

Maybe that's a horrible example

 

[BobB]

Oh dear - I can see myself teaching customers (electricians) 1 1/2 or 2 days away from me in the remote outback of Australia how to use and debug ST! To be honest I do not even use FBs much because every job is different anyway. I do use a few scaling FBs and the like from time to time as it is proven and used on most jobs. Many of my customers have trouble understanding FB but they all understand control circuits and can figure out ladder with a bit of help over the phone.

Even when extracting data from Caterpillar engines you never know what is going to be in there. Modbus RTU but J1939 protocol - value, precision and offset. All floating point calcs - I have a standard routine written in ladder that I drop into the program. When the generator starts, have a look at what you get and just delete what is not there. Wrote the whole lot in ladder just a bit quicker than my friend did in ST strangely enough due to copy, paste and quickly modify. He was doing the same.

I was also working recently with a Schneider guy on a job and he wrote a whole pile of code in ST to place digital I/O into a block for extraction to the PLC - it was their remote I/O unit that is a dumbed down M340 processor. Took him ages - why? I would have done it in ladder in 1/4 of the time to be honest.

Perhaps you are doing the right thing for your degree - the examiners will probably be impressed if you do a good job of it. Probably a good choice for your degree but if you ever work in automation and are going to be a long way from your customers, many of whom will not be able to follow ST, think about ladder - it may save you a long trip!

I hate traveling in planes for 1 1/2 or 2 days to sort out a simple problem - rather use ladder and do it over the phone. Lose time on planes and cannot get any work done! Make more money when I am at home base. Changes many ideas working for yourself and it is your money being wasted or not earned because you have to travel to sort something simple out!

 

[Peter Nachtwey]

I was also working recently with a Schneider guy on a job and he wrote a whole pile of code in ST to place digital I/O into a block for extraction to the PLC

I would blame the Schneider guy not ST. I bet it can be done in ST just as fast or faster than ladder logic.

 

[Highland Controls]

At the risk of offending people, I will say that using only, or even mostly, ST for applications is extremely shortsighted. I can say the same for those who use only ladder. The small ST example above makes sense, and I will use ST for Case statements and small If/Then sections. Trying to debug a running machine using ST can be a nightmare, though. I think there is nothing better than SFC for controlling a routine(or overall machine cycle). It is nice to go into debug mode, glance at the SFC tree, and know exactly what the program is doing(or supposed to be doing). Yes, many techs can grasp simple Ladder programs. Ladder is easier to debug with little training, but even then, large Ladder programs(with multiple tasks, subroutines, etc.) can't be understood by most techs/electricians.

 

[ndzied1]

Deciding to program in only one language misses the whole point of IEC61131. Some tasks are naturally more ladder oriented, some are more ST oriented. At least in CoDeSys you can even use actions that allow you to have part of a POU in Ladder, part in ST part in FB, whatever.

The best way to ensure easy debugging is to have an experienced, organized original programmer that uses consistent tag and comment names. I have surfed into many ladder programs that were spider webs of logic connected in a neural network of (dis)logic.

If you follow any blogs that have to do with the computer programming there is a high emphasis placed on writing concise functions that compartmentalize logic as much as possible for readability and debuggability.

 

[JesperMP]

At the risk of offending people, I will say that using only, or even mostly, ST for applications is extremely shortsighted. I can say the same for those who use only ladder. The small ST example above makes sense, and I will use ST for Case statements and small If/Then sections. Trying to debug a running machine using ST can be a nightmare, though. I think there is nothing better than SFC for controlling a routine(or overall machine cycle). It is nice to go into debug mode, glance at the SFC tree, and know exactly what the program is doing(or supposed to be doing). Yes, many techs can grasp simple Ladder programs. Ladder is easier to debug with little training, but even then, large Ladder programs(with multiple tasks, subroutines, etc.) can't be understood by most techs/electricians.

+1 to that.

To understand what the logic is doing when observing the online status is easier with ladder. But only to a certain level of complexity. For complex code, you can easily get lost in a maze of ladder code.

 

[Peter Nachtwey]

For motion control we use a state machine that has steps, like SFC, and ST inside the steps.
I am still working on a ST compiler. I have the parser done. The parser shows where the errors are. It is fast. Debugging ST is not hard if there is log that can record what is happening. Most PLCs don't have a good log or trace feature.
I recommend using SFC and ST together for machine control.

 

[Highland Controls]

I usually use SFC for machine control, with ladder for the (direct)Transitions and whatever makes sense for the Actions. Usually FBD, but sometime ST.

 

[dwoodlock]

I think what you use will probably depend on the specific task, and then what your style is.

I use a lot of comparators for step sequences, so whatever does that the easiest is what I go with.

On my most recent project I started using an S7-1200 and programming using ST. The most relevant experience I had to programming with ST, was with running queries on an SQL database. I think it is pretty easy to figure out the language and you should'nt have much trouble.

 

[BobB]

Tis not me that is the problem - it is the guy 1 1/2 to 2 days away by plane who cannot sort things out or understand! Otherwise I would use it more for some things. LOL

 

[CapinWinky]

Tis not me that is the problem - it is the guy 1 1/2 to 2 days away by plane who cannot sort things out or understand!

Charge them double for service unless they have a working e WON installed. Also, why does everyone on here seem to have wayward service guys dicking around in their code?