SIMATIC: Problems writing a value

[JesperMP]

According to the online help for OW:

OW (OR word) combines the contents of ACCU 1-L with ACCU 2-L or a 16 bit-constant bit by bit according to the Boolean logic operation OR

and

The instruction is executed without regard to, and without affecting, the RLO

But in order to just try something, I suggest putting a SET after the jump to "done".

 

[Robert Carlsson]

Didn't work either. The RLO is already set when reaching the done label.

 

[S7Guy]

What do you see in the accumulators and AR1 and AR2 registers at the point in the code where you are writing zero to RET? Can you post a snapshot of that?

 

[RMA]

Thanks for clearing that up Jesper, as I mentioned, I was assuming - incorrectly as it turned out - that the OW command would work like the normal Boolean OR.

The fact that the program works when you use a Pointer suggests that it might be the old problem of Parameter passing when calling FCs from an FB, etc.

I can't quite see from the code snippets which part of the program are in an FB and which may be in FCs - also I can't remember whether DPWR_DAT is an (S)FC or FB.

 

[JesperMP]

I have to go now, but I think that the RET_VAL from the DPWR_DAT call is not "0" even if the transfer went OK.
Try to transfer RET_VAL to a non-temporary address and then observe it in a VAT.
I.e.
CALL "DPWR_DAT"
LADDR :=#wLADDROut
RECORD :=#pSrc
RET_VAL:=MW1000

L MW1000
T #iReturn

L #iReturn
L 0
==I
JNB err

 

[Robert Carlsson]

@JesperMP: Okay, thanks for your effort. The RET_VAL is zero, as you can see in the screendump I'm posting

@RMA: This block is called directly from OB1, and is a FB. DPWR_DAT is a SFC.

@S7Guy: Of course, here's a screendump. I'm also posting a screendump of the VAT. The RET value is put in MW1 in the VAT.

 

[TurpoUrpo]

You said you tamper with ar2, have you rememberd to save and restore it? Your first pic show AR2 referencing DI 3103.0 is that right?

 

[RMA]

If I remember correctly, only FCs have a RET_VAL variable built in. In post 1 you said you were working with a Function Block. If this is the case, is the RET variable a TEMP? If so you must initialise it (in this case to zero at the start of the FB, so that the state is defined.

The problem with TEMPs is that the assigned memory is theoretically undefined. However, in practice, if nothing else changes it is often thecase that the same area of memory will be assigned each call. If this part of memory has not been used by any other part of the program between calls then the old data will still be there.

In other words if you have an error in one cycle, the data in your local memory will still be there next time round, unless you explicitly clear it yourself.

What makes this problem really serious, is that programs can work for months and even years until someone makes a small change to the program and suddenly you have a problem that can be exceedingly difficult to find!

Golden rule - always initialise TEMPs before using them!!!

 

[Robert Carlsson]

@RMA: I understand your point, and yes, this is a FB, but the #RET is not a Temp, it's an OUT, and therefore has it's own memory space in the DI.

@TurpoUrpo: How does AR2 affect me trying to write to #RET?
RET has address DI28.0, and that DI3103.0 is an array that I needed before in the block.

 

[L D[AR2P#0.0]]

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

YES. Once AR2 has been modified all accesses to IN/IN_OUT/OUT/STAT variables will give unexpected results.

 

[TurpoUrpo]

Look at this:

http://www.plctalk.net/qanda/showpost.php?p=338595&postcount=203

In short, when you access symbolically in FB, compler changes code to look like

t [ar2,p#28.0]

 

[RMA]

@RMA: I understand your point, and yes, this is a FB, but the #RET is not a Temp, it's an OUT, and therefore has it's own memory space in the DI.

Where are you trying to read the value that you store in RET? If it's the same FB, then I'm puzzled, but since you say it's an OUT then the problem is the Parameter passing problem I mentioned in Post #19.

The problem is that RET is a local memory area of your FB103 and cannot be accessed directly from another FC or FB, but only via a Pointer.

L D[AR2,P#0.0] has covered this area in detal in previous posts and can probably find the examples quicker than I can, but I'll give it a try with the search function in the mean time.

 

[L D[AR2P#0.0]]

Roy - AR2 has been modifed so all bets are off.

Here's another example thread to review: http://www.plctalk.net/qanda/showthread.php?t=49674&highlight=story

 

[Robert Carlsson]

Look at that, you learn as long as you live, isn't that what they say?

Thanks everybody for helping me understand this. I modified the code to

L 0
LAR2
T #RET

and it works perfectly. I know it's probably not the best to do this here, but it would take some time for me to change the AR2 back to 0 every time I've used it. Now I know I'll have to be more careful with AR2 at least.

Again thanks alot, all of you guys!

 

[TurpoUrpo]

That is your headache, but it would be easier to maintain code, where you always before using it save it and after using it restore it.

its this easy:

VAR_TEMP
      AR2store : DWORD;
END_VAR

TAR2 #AR2store

your code that modifies AR2

LAR2 #AR2store