One shot in ST

How is a one shot done in ST. Does it have to be coded, or is there a command for this function?

Hello Scott,

Generally speaking, unless the ST compiler you are using supports the manufacturers instruction set (and that set includes something like a 'ONS' function), then you have to code a One Shot using ST.

You mean this http://www.plctalk.net/qanda/showthread.php?t=18201
Henry

yes, R_TRIG is the way to do it.

I am using Omron FB, the R_trig function does not seem to be recognised.

Nothing in the documentation about it as yet.

Trying to do a MOV instruction, only once though, so then I can manipulate the destination.

Can do it in ladder, would prefer to use ST as is neater for calcs.

Scott

If they are IEC 61131 compliant then they would have to support the R_TRIG function block.

Here's a simple program that adds one to the variable i whenever the signal MyOnSignal comes on.


This code was done in a variant of CoDeSys and compiled and ran as expected in the simulator.

Hope this helps.

It still boggles my mind why the creators of IEC 61131 standard decided to have one-shots in the form of a function block.

Such a basic and frequently-used thing. A little up or down arrow, that's all. More needed than even an ADD command.

Can't help but to recall an old parable about some people who tend to do things the hardest way possible. Or, as my schoolteacher used to put it, to scratch one's left ear with his right hand...

It is a function block because it needs data (a boolean) to "remember" the state of the one shot on future scans.


In the MicroLogix it is a function block. Even in the SLC/500, I would say the [OSR] is technically a function block because you can't use the address anywhere else in the program (of course it lets you but it will usually messing something else up).

You can't make your own one shot without some piece of data to "remember" the previous rung state so whether you put it in a function block or reserve the space yourself in a boolean you are really doing the same thing.
I prefer the R_TRIG because it is defined and should be understood by anyone else familiar with ST programming.

The thing I really dislike about IEC 61131 is that comments are delimited by 2 characters (* and *) and that you can't have end of line commments like C++. That stinks!!

ndzied1 said:

I would say the [OSR] is technically a function block because you can't use the address anywhere else in the program (of course it lets you but it will usually messing something else up).

Click to expand...

Well, the same is true about any boolean instruction, isn't it? You can use the address of an output coil anywhere in the program... but should be careful, right? Not to mention that for an advanced compiler, it should not be a big deal to pick an address for the internal bit from the "heap" of unused memory - totally hidden from me. I don't really care where that data is stored - as long as that location is not used twice. To me, a one-shot could (and should) be a small graphical symbol on the screen - just like a nNO or NC contact - and not a "box". Waste of screen space and trouble reading the program. BTW, AB's OSR and ONS instructions are not the best representations either - Omron's and GE's are much better.

Entirely agree about the comment delimiter.

LadderLogic said:

Well, the same is true about any boolean instruction, isn't it?

Click to expand...

Not really.

This is perfectly fine:

  Input_1                   STEP_1

-----] [---------------------( )----

 

 

   STEP_1       Input_2       STEP_2

-----] [----------] [----------( )-----

But this is not OK:

   Input_1      OS_1             STEP_1

-----] [-------[OSR]--------------( )----

 

 

    OS_1        Input_2       STEP_2

-----] [----------] [----------( )-----

Once I use the OS_1 as the address for a one shot, I cannot use it (even for an XIO or XIC) anywhere else in the program. However, I can create STEP_1 with an output instruction and use it anywhere else in the program as an input (XIC, XIO) type instruction without question.

I've never used Omron or GE but they must, like you say, reserve memory from the heap to save the state of the one shot.

I suppose it's just a philosophical choice to either let you the programmer reserve the memory or have the compiler do it. The way IEC 61131 ST programs can have scope (local vs. global), it might be more complicated for the compiler to decide where to put the memory or which POU's can access it unless it is explicitly declaired.

An option and back to basics.

ndzied1 said:

The thing I really dislike about IEC 61131 is that comments are delimited by 2 characters (* and *) and that you can't have end of line commments like C++. That stinks!!

Click to expand...

That's because they didn't ask us first. When we get around to it we will have an optional way of adding comments with //.

We don't have a full implementation of ST yet either. We don't have an R_TRIG. Since we do have a state machine there isn't really much need but when a one shot is required we recommend:

os := input and not lastinput;
lastinput := input;

When I write C code I do it like this. C doesn't have a R_TRIG either. One shots FBs aren't necessary. I programmed for many years with out knowing the term one shot even though I had been using them for years. Believe it or not, there was programming before R_TRIG and one shots.

Peter Nachtwey said:

Believe it or not, there was programming before R_TRIG and one shots.

Click to expand...

I hope no one thought I was saying that R_TRIG was the only way to make a one shot. I was just stating what I think the reason is that in IEC 61131 it is implemented as a FB and not a function or little arrow symbol.

Heck, in the 60's NASA reguarly did life and death calculations with less computing power than is in the average cell phone today and got trajectories right to within a few meters over hundreds of thousands of km.

We're very spoiled with Gigabyte memory spaces, optimizing compilers and graphical debuggers (not that I'd trade them in for anything). Those guys back then knew how to optimize every bit in their code.

Remember when there was a big hump to get over if your program exceeded 64k and you had to make it an EXE instead of a COM file?... I remember compiling database programs that took over an hour to compile (IBM PC Clone w/ soldered in math co-processor, 10MB hard drive, 512k RAM)!!!!!....

"640k, no one is ever going to need more than 640k"

Many thanks for your replies chaps, it appears that I cannot use the R_Trig command, even though it is stated in the documentation that the ST complies with IEC 61131.

Anyway, using Peters example, I came up with the following to calculate a decreasing length.

(*One Shot for Initial Reel Size*)
OS:=EN andnot lastip;
lastip:=EN;

(*Move the initial size for calculations*)
if OS then
reelsize:=initsize;
end_if;

mm_sec := Line_Spd/60.0;

(*One Shot when internal timer is on*)
OS1:=P_1s andnot lastOS1;
lastOS1:=P_1s;

(*Every second, decrease the reel size by the calculated speed*)
IF OS1 then
ReelSize:=reelsize-mm_sec;
End_If;


Is this a good way of structuring this type of calculation, I know that there will be other factors that I will have to allow for, but think that I am on the correct track? I am a ladder person, but like the use of ST more calculations.

I would do it like this:

[/size]

[/size]This way you don't have to worry about associating the one shot with the actions.

One should indent code between the if and end_if. It make is more readable. This applies to WHILEs and FORs to.

Sorry Peter, but I'm not sure I agree (groan ... he's got a lot o' damned gall that boy, challenging the great Nachtwey twice)

In Scott's second line of code lastip is controlled uniquely by EN, and lastip will move true and false according to the state of EN.

In your alternative I think whenever the IF condition solves false the following statements will be skipped to the END_IF. Since one of the prerequisites for the IF solving true is that EN is true, this then means that the only times lastip will be updated is whenever EN is true. There's nothing to set lastip false. On the occasions that EN is false the code is skipped. When controlling binary variables inside IF statements it's all too easy (done it myself) to forget that there is no implicit ELSE or ELSIF. You either need to code explicitly what you want when EN is false, or take it outside and use a simple assignment as Scott did.

Tentatively yours

Ken