Explain this STL

How he can but 2 SFC ( 14 , 15 ) in same network without a bit logic ?
and have a not equal compare for both

CALL "DPRD_DAT"
LADDR :=#IN0
RET_VAL:=LW0
RECORD :=P#DIX 4.0 BYTE 20
L LW 0
L 0
<>I
S #OUT1
CALL "DPWR_DAT"
LADDR :=#IN0
RECORD :=P#DIX 26.0 BYTE 20
RET_VAL:=LW0
L LW 0
L 0
<>I
S #OUT1

It is a simple OR functionality.
If RET_VAL of either the call to DPRD_DAT or DPWR_DAT is not zero, then there must be an error, and #OUT is set.

I guess there must be more code than this. Something must reset #OUT.

Another thing to note.

Using Set/Reset on a variable declared as an OUT from FC is a bad idea.

If the block is subsequently called in ladder, you might assign M100.0 as out #OUT1 but what happens invisibly in the background (at least in S7300/400) is that the compiler allocates a temp variable to #OUT1 and the RLO state is then copied to M100.0

In your FC, if you use a S or R instruction for #OUT1 then you will be setting/resetting the value of the temp variable assigned. As temps are not persistent between scans, all kinds of problems can ensue.

If you wish to write reliable code, avoid set/reset like the plague!

Nick

JesperMP said:

It is a simple OR functionality.
If RET_VAL of either the call to DPRD_DAT or DPWR_DAT is not zero, then there must be an error, and #OUT is set.

I guess there must be more code than this. Something must reset #OUT.

Click to expand...

1st - it's a FB ( called every time in a FC ) to communicate with Abb drive so he don't want to insert SFC14 and SFC15 every time he want to communicate with a 6 drives ( this is what i think ) and he will link this FB every time to another DB where the data stored for each drive .

2nd - i try to understand this FB but it's written in STL so i try to make another one ( another project ) in LAD and just change it to STL ( view > STL ) but i couldn't get the same result as the code he wrote .
this is my work , i could do both of SFC 14 and 15 in separate networks

network 1
A(
CALL "DPRD_DAT"
LADDR :=#IN0
RET_VAL:=LW0
RECORD :=P#DIX 4.0 BYTE 20
A BR
)
A(
L LW 0
L 0
<>I
)
= #out1

network 2
A(
CALL "DPWR_DAT"
LADDR :=#IN0
RECORD :=P#DIX 26.0 BYTE 20
RET_VAL:=LW0
A BR
)
A(
L LW 0
L 0
<>I
)
= #out1



3rd - yes there is another network to reset out1
L LW 0
L 0
==I
R #OUT1

All is good.
You wont get exactly the same in STL generated from LAD than pure STL.
When you place several instructions in series, STL generated from LAD inserts extra statements to save the "branch result" for example.

Btw, dont address local data directly. In the original FB, the LW0 probably is a declared TEMP variable.

Also, your LAD code will probably work, but it is not 100% the same as the original STL code.

If there is a problem with the execution of the DPRD_DAT (granted, it is very unlikely since it is a system function block and therefore very well tested), then the ENO will not be set and the OUT1 also not be set since it is in series with the DPRD_DAT block. So in praxis it will be OK, but in priciple it is a bug waiting to happen.

JesperMP said:

All is good.
You wont get exactly the same in STL generated from LAD than pure STL.
When you place several instructions in series, STL generated from LAD inserts extra statements to save the "branch result" for example.

Btw, dont address local data directly. In the original FB, the LW0 probably is a declared TEMP variable.

Also, your LAD code will probably work, but it is not 100% the same as the original STL code.

If there is a problem with the execution of the DPRD_DAT (granted, it is very unlikely since it is a system function block and therefore very well tested), then the ENO will not be set and the OUT1 also not be set since it is in series with the DPRD_DAT block. So in praxis it will be OK, but in priciple it is a bug waiting to happen.

Click to expand...

Am happy :site: that someone could help me and i could understand the STL , although i do a copy and paste for the data

but i don't get the point of last sentence ( problem with execution of DPRD_DAT .... ) am not going to try this at a physical drive , i was doing a search on how to connect Abb drive DCS800 to a plc ( Siemens ) and figure how it's done so i take a copy of our factory machine and try to trace the communication
the only step now missing is the stop , start , reference speed to send to dive and get the feedback ( CW and SW )

I am guessing that the #OUT is a bit the indicates when there has been an error in transferring the data to the drives.

If DPWR_DAT has an internal failure (which is unlikely) then the ENO will not be set, and the error bit #OUT will also not be set, despite the pressence of a problem.
Just me nit-picking here, it is a theoretical problem at most.
But if you use the same way of writing code elsewhere, with some other blocks, you can run into that it dont work.