Weird Structured Text execution order

[dalporto]

Good morning.


I'm doing a rehab and I need to recycle some part of the old code that won't change and that I need. This is a calculation that looks to 3 instruments and a couple coefficients.


I don't work much with Structured Text since the customers mainly don't want us too, their staff is mainly "trained in" LD and FBD. Anyway.



I'm not sure if this is weird, or if there is something that I don't understand about ST.


1- Energy_Kinematic_Global calculation is after the line that uses it;
2 - The Hn IF/THEN + the calculation seems an odd way to do it. The calculation, then the limiter using the same tag?



Also when I run it (without instrumentation present (Q, P1, P2)) and I pass the Hn value to InTouch, I'm getting 25.000, but I can clearly see the value flash to 2.208 from time to time. What is the Q**2 operation by the way?


Thanks.



K1 := 10.197;
C1 := -0.82;
Q := TUR_FT13;
P1 := (TUR_PT15 / 100);
P2 := (TUR_PT16 / 100);
Hn := ((P1 - P2) * K1) + C1+ Energy_Kinematic_Global;
Energy_Kinematic_Global := (Q**2)/274;
IF Hn >= 68.0 THEN
Hn := 68.0;
END_IF;
IF Hn <= 25.0 THEN
Hn := 25.0;
END_IF;

 

[AlfredoQuintero]

> What is the Q**2 operation by the way?


This is the square value of Q, or Q times Q

 

[drbitboy]

1- Energy_Kinematic_Global calculation is after the line that uses it;
2 - The Hn IF/THEN + the calculation seems an odd way to do it. The calculation, then the limiter using the same tag?

Also when I run it (without instrumentation present (Q, P1, P2)) and I pass the Hn value to InTouch, I'm getting 25.000, but I can clearly see the value flash to 2.208 from time to time. What is the Q**2 operation by the way?

K1 := 10.197;
C1 := -0.82;
Q := TUR_FT13;
P1 := (TUR_PT15 / 100);
P2 := (TUR_PT16 / 100);
Hn := ((P1 - P2) * K1) + C1+ [B][COLOR=#ff00ff]Energy_Kinematic_Global[/COLOR][/B];
[B][COLOR=#ff00ff]Energy_Kinematic_Global [/COLOR][/B]:= (Q[B][COLOR=#ff00ff]**[/COLOR][/B]2)/274;
IF Hn >= 68.0 THEN
    Hn := 68.0;
END_IF;
IF Hn <= 25.0 THEN
    Hn := 25.0;
END_IF;

1) the order of the Hn and Energy_Kinematic_Global calculations is certainly odd, since Hn is dependent on the energy value. This way, it is dependent on the previous scan cycle's calculation of the energy value from perhaps a few milliseconds earlier; that could be the actual intent, or it could be a typo. Either way is probably not going to make a lot of difference over time, although I don't the dynamic character of the TUR_?Tnn inputs, so don't take me to court over that .

2) the ** is the binary operator for exponentiation, perhaps rendered more commonly in text as Q^2, so it is the same as Q*Q (multiplication) or Q².

 

[robertmee]

Q**2 is squared.

It's not uncommon to use limiters like that, but usually not on the same tag that's used on an HMI. The HMI polls the PLC and it services those polls asynchronous to logic scan, so it's conceivable it sees the value before the limiter is applied. Hence the momentary blip in value.

As for why kinetic global is calculated after Hn, hard to say. Means Hn lags in value to Kinetic by 1 scan. Could have been done intentionally or mistakenly.

Edit...Dr beat me by a second

 

[dalporto]

That Hn value is not only going to the HMI. It also goes to a lookout table that will ultimately shift a "main" setpoint for a matter of milliseconds, but the system will react. It is probably not noticeable but i will certainly try to fix that.


I don't see why they preferred to use Energy_Kinematic_Global that way. Like you I first though it was done on purpose, but it don't make any sense, there is no need to lag that scan, this is an awfully slow process.


Thanks guys.

 

[dalporto]

although I don't the dynamic character of the TUR_?Tnn inputs

What do you mean?

 

[robertmee]

That Hn value is not only going to the HMI. It also goes to a lookout table that will ultimately shift a "main" setpoint for a matter of milliseconds, but the system will react. It is probably not noticeable but i will certainly try to fix that.


I don't see why they preferred to use Energy_Kinematic_Global that way. Like you I first though it was done on purpose, but it don't make any sense, there is no need to lag that scan, this is an awfully slow process.


Thanks guys.

Because of scan order, any other logic using Hn later will be fine, as the logic is scanned sequentially. It's only the nuisance of the HMI displaying the intermediate value of Hn as it can update asynchronous to the PLC scan. If that's the only destructive instance of Hn in the code, after the limiter, just add a MOV Hn to Hn_HMI and display Hn_Hmi instead.

 

[drbitboy]

What do you mean?

I don't know how quickly TUR_FT13, TUR_PT15, and TUR_PT16 change over time e.g. large swings over a millisecond timeframe, small irrelevant levels of noise over some timeframe, or stable values from an HMI with big or small changes a few times per day or hour.

 

[dalporto]

Oh ok.


No, it's pretty stable in normal operation, they are all related to a river elevation. I'm putting a flatline detection with a 10 minutes timer to give you an idea.



And in abnormal operation, I don't care about those values anymore since the unit is tripping anyway.

 

[dalporto]

Because of scan order, any other logic using Hn later will be fine, as the logic is scanned sequentially. It's only the nuisance of the HMI displaying the intermediate value of Hn as it can update asynchronous to the PLC scan. If that's the only destructive instance of Hn in the code, after the limiter, just add a MOV Hn to Hn_HMI and display Hn_Hmi instead.

I finally re-did the logic to fix it for good, also using another tag.



Thanks.

 

[durallymax]

That Hn value is not only going to the HMI. It also goes to a lookout table that will ultimately shift a "main" setpoint for a matter of milliseconds, but the system will react. It is probably not noticeable but i will certainly try to fix that.
.

The logic is not seeing that value as the limiter will prevent it. As mentioned, it is due to HMI update rate and being async.

The limiter is a very common way to accomplish that as it is easy to read in ST that way. Remember, in ST an IF statement is not like contacts in ladder. It will ignore the variable entirely if the condition is not true so it is more common to write to the same variable many times breaking LADs alleged golden rule. Everyone has a different opinion on this though.

If you want to verify, you should be able to trend that variable and step through the program or create a trigger to trend that variable through a cycle. Then you will be able to see when and where the value is changing and to what. If your IDE doesn't have these tools, create some test variables with R_TRIGs to save a value at each step for review.

 

[dalporto]

That make sense, but it's still messing with my head.


If at some point the HMI is reading that 2.208, doesn't it means that at some point during a scan Hn effectively turns to 2.208 when the calculation line is scanned? Then back to 25 once the limiter lines are scanned?


I don't have time to test it right now, but it sure should be interesting.


Like I said earlier I don't do a lot of ST, so this was just a gut feeling that something was odd.

 

[durallymax]

That make sense, but it's still messing with my head.


If at some point the HMI is reading that 2.208, doesn't it means that at some point during a scan Hn effectively turns to 2.208 when the calculation line is scanned? Then back to 25 once the limiter lines are scanned?


I don't have time to test it right now, but it sure should be interesting.


Like I said earlier I don't do a lot of ST, so this was just a gut feeling that something was odd.

Yes before the limiter it will be whatever the result of the calculation is, but the rest of the program won't see that as the limiter will clamp it before it is used elsewhere. The HMI may happen to catch it at that point though.

 

[dalporto]

Ok, thanks.


So I did that to correct the blip on the HMI, I don't see it anymore.


NHWL_K1 := 10.197;
NHWL_C1 := -0.84;
NHWL_Q := GX_80GOV;
NHWL_P1 := (GX_JB17_63SPIRAL_CASE / 100);
NHWL_P2 := (GX_JB17_63DRAFT_TUBE / 100);
NHWL_Energy_Kinematic_Global := (NHWL_Q**2)/274;
NHWL_Hn := ((NHWL_P1 - NHWL_P2) * NHWL_K1) + NHWL_C1 + NHWL_Energy_Kinematic_Global;
IF NHWL_Hn >= 68.0 THEN
GX_NHWL := 68.0;

ELSE IF NHWL_Hn <= 25.0 THEN
GX_NHWL := 25.0;

ELSE GX_NHWL := NHWL_Hn;
END_IF;
END_IF;



Is the syntax ok? It looks weird.

 

[drbitboy]

Ok, thanks.

So I did that to correct the blip on the HMI, I don't see it anymore.

NHWL_K1 := 10.197;

NHWL_C1 := -0.84;

NHWL_Q := GX_80GOV;

NHWL_P1 := (GX_JB17_63SPIRAL_CASE / 100);

NHWL_P2 := (GX_JB17_63DRAFT_TUBE / 100);

NHWL_Energy_Kinematic_Global := (NHWL_Q**2)/274;

NHWL_Hn := ((NHWL_P1 - NHWL_P2) * NHWL_K1) + NHWL_C1 + NHWL_Energy_Kinematic_Global;



IF NHWL_Hn >= 68.0 THEN



    GX_NHWL := 68.0;



ELSE IF NHWL_Hn <= 25.0 THEN



    GX_NHWL := 25.0;



ELSE



    GX_NHWL := NHWL_Hn;



END_IF;

END_IF;

Is the syntax ok? It looks weird.

[reformatted quoted text to make it easier to read]

[I believe there is an extra END_IF; in there.]


Yes, the syntax is okay; ST is just ugly, it can't help looking weird (this unironically from someone who programmed Fortran for decades).

And that should solve the HMI blip for most cases; if you want to be absolutely sure, you can use CPS(NHWL_Hn, GX_NHWL, 1);(cf. here); to ensure asynchronous HMI comm events cannot interrupt the routine mid-assignment (:=); you could also write to the final memory location only once; i.e. this

IF NHWL_Hn >= 68.0 THEN



    NHWL_Hn := 68.0;



ELSE IF NHWL_Hn <= 25.0 THEN



    NHWL_Hn := 25.0;



ELSE



    NHWL_Hn := NHWL_Hn;



END_IF;



CPS(NHWL_Hn, GX_NHWL, 1);