SIMATIC: Problems writing a value

[Robert Carlsson]

Hey all!

I've been developing a function block, and at the end of this function block I want to write error code to an output variable, #RET. If there were no error, I want to write the value w#16#0, if there were an error, I want the error code to be returned. Here is the code:

err:  NOP   0
      L     #iReturn
      L     W#16#8000                   // Make sure the error bit is set
      OW    
      T     #RET                        // Write the error information to the RET variable

      SET   
      SAVE  

      JU    exit

done: NOP   0

      L     0                           // Make sure the RET variable indicates no error has occured
      T     #RET

      SET   
      SAVE  

exit: NOP   0

This only works halfway. If I have an error, the error code is written to #RET and there's nothing strange about that. But when there is no error, the execution jumps to done (and the code between err and done is never executed), but still the previous error code sticks. When getting another error code, the #RET is changed immediately, but as soon as I clear every error, nothing happens.

I managed to get the things working by changing the code to this:

err:  NOP   0
      L     #iReturn
      L     W#16#8000                   // Make sure the error bit is set
      OW    
      T     #RET                        // Write the error information to the RET variable

      SET   
      SAVE  

      JU    exit

done: NOP   0

      L     P##RET                      // Make sure the RET variable indicates no error has occured
      LAR1  
      L     0
      T     W [AR1,P#0.0]

      SET   
      SAVE  

exit: NOP   0

Where the only change is after the done label.

Does anyone have an explination why it didn't work with the first code?

Thanks

 

[TurpoUrpo]

I assume you have some code upfront that decides the jump to done or err.

Try

l w#16#0000
t #RET

 

[Robert Carlsson]

I assume you have some code upfront that decides the jump to done or err.

Yes, that's correct.

There were no difference between
L 0
and
L W#16#0 (I wrote l W#16#0000, but step7 automatically changed it to l W#16#0000)

 

[TurpoUrpo]

What is the datatype of #RET?

 

[Robert Carlsson]

It's a Word

 

[TurpoUrpo]

Its seems like compiler has been buggy or sumthing. It should work as you want, have no idea, if you do not tamper with AR2 before executing jump.

 

[JesperMP]

You have to show us the code that jumps to the done: label.

 

[Robert Carlsson]

Well, I do tamper with AR2, but a bit further up in the code. Could this affect anything?

Here comes the code that jumps to done

      LAR1  P##pSrc
      L     W#16#1002
      T     W [AR1,P#0.0]
      L     #wBPSize
      T     W [AR1,P#2.0]
      L     DINO
      T     W [AR1,P#4.0]
      L     P##abSendBuffer
      T     D [AR1,P#6.0]

      CALL  "DPWR_DAT"                  // Write the send buffer to outputs
       LADDR  :=#wLADDROut
       RECORD :=#pSrc
       RET_VAL:=#iReturn

      L     #iReturn
      L     0
      ==I   
      JNB   err

      JU    done

 

[JesperMP]

I cannot see anything that can explain the problem with your code.

 

[Robert Carlsson]

Good, then it's not me being an idiot

 

[JesperMP]

Or we are both idiots.....

 

[RMA]

In the 300 CPUs when you execute a conditional jump the state of the RLO Bit is carried over after the jump is executed (this doesn't happen in the 400 CPUs). This means that when you arrive at the error check, in your case, you have the RLO Bit already set. The OR command then looks at the result of the immediate comparison and ORs it with the current state of the RLO, since this is TRUE then the result of the OR is TRUe.

Either invert your error query and test for no error and change your Jump to JCN (or whatever the English mnemonic is, I don't have a PC with Step7 available at the moment), or alternatively, as the first command in the error check issue a CLR instruction to reset the RLO Bit.

If you make a habit of checking things this way, then it might be a good idea to get into the habit of always CLRing the RLO in code you jump to conditionally.

This problem doesn't have anything to do with AR2.

 

[Robert Carlsson]

@RMA: I'm not quite sure I understand what you mean. Where is this OR function you are talking about? And how does it affect the

L 0
T #RET

?

 

[RMA]

I mean the "OW" command which you use to strip out the error Bit in the third line after the "err" label. I can't check it, but I assume that the OW command operates the same way as the O command for ORing two Bools and ORs the result with the state of the RLO Bit.

While I try to find my copy of Berger, try inserting a CLR command as the first instruction after your
err: NOP 0

label. I reckon that will solve your problem - at least it will if I'm correct!

 

[Robert Carlsson]

I think you misunderstood my question/problem.

The error code is reported correctly when jumping to the "err" label. the OW ORs ACCU1 and ACCU2, in this case making sure bit 15 is set, as I'm ORing w#16#8000. The OW instruction is executed as I want.

The thing that confuses me is why

L 0
T #RET

doesn't work, when

L P##RET
LAR1
L 0
T W[AR1, P0.0]

does?

Anyways, I tried CLR after the err: NOP 0 row, but it didn't help.