Siemens SFC15 (DPWR_DAT) error...

Hello guys!

I have a strange problem when I'm using SFC15 in a siemens S7318 cpu.

It worked fine for about a week ago and suddenly after I downloaded a program on friday it started giving me an errormessage (return code 8090hex).
The helpfile says this about the error:

8090:
· You have not configured a module for the specified logical base address or
· you have ignored the restriction concerning the length of consistent data or
· you have not entered the start address in the LADDR parameter in hexadecimal format.

Click to expand...

I have checked the hardware config and this is still the same as it was while it was working and I'm using the same address for both sfc14 and sfc15 (sfc14 is working) so I know that the address is correct. The length of the consistent area is 2 bytes in the hardware setup and 2 bytes in my function call. shouldn't be any problem there.
The start address is given in hex 110 so that should not be the reason either. I just don't get it, it worked fine then it suddenly stopped working.

This is my program call:

CALL "DPWR_DAT"
LADDR :=#AmpIOAddr
RECORD :=#ControlWord
RET_VAL:=#ForceAmpData.Amplifier.RetVal.RV_SFC15
NOP 0

Click to expand...

I'm using SCF14 (read) from the same IO address without any problems, it's just the write that doesn't work.

The IO address corresponds to the hardware setup (110hex), the Controlword is 2 bytes.
If I write this using PQW directly then it works, but I don't want to hardcode the address, since this is inside a function which is used for different units. (it doesn't work on either of the units).
My other solution is building a pointer based on the io address used in the sfc14 call and then using pqw but I prefer figuring out why it doesn't work.

Anybody in here have any ideas?

Borte,
When you say it stopped working after downloading a new program, what do you mean? Did you change something in the SFC15 call, or did you change something elsewhere in the program unrelated to SFC15? Have you looked at the actual online value for #ControlWord? Is that a local variable that your initialize? It also looks like you might be calling this from an FB (#ForceAmpData.Amplifier.RetVal.RV_SFC15); is it possible that AR2 has been affected by your program download (I know from personal experience that this can happen ).

Hello S7Guy!

I figured this whould interest you...

It stopped working after downloading a change not related to this sfc15 call.

#ControlWord is a local variable (temp) that I initialize. It is being populated be s/r statments in the network above. So I know the status of this one. But the sfc15 should work regardless of what the #controlword variable contains. The only thing that really matters is that the size of the variable is according to the size in the hardware setup of the slave. Which is 2 bytes.

Yes I am calling this from an FB. Whould that make a difference?

What do you mean with AR2 can be affected by my download?
Isn't the AR1 and AR2 initialized every scan?
If this is the case how can I fix it? Delete everything and redownload?

Hey Borte,

I asked about the #ControlWord variable because it can be initialized a couple of ways. For instance, if I were using absolute addresses, I could enter either MW10 for the two bytes, or P#M10.0 BYTE 2. If you are using the latter method, then I could see how the data length could be wrong if the ANY pointer was constructed incorrectly. But, it seems like your variable is exactly two bytes, so we'll eleiminate that possibility.

As for why I asked about the FB, it really depends on how you use the FB. Personally, I always call FBs unconditionally, without declaring an instance DB, which means I have to calculate AR2 dynamically. If you are doing something like that, then it's possible that AR2 is pointing to the wrong data area for your #AmpIOAddress variable. I'm not 100% sure about this, but I bet it can even happen with instance DBs if you change the data structure without recompiling the blocks. To verify that AR2 is ok, look at the block in STL and look at the current AR2, and also the #AmpIOAddress value.

I'm with you on this one: Even though you can just as easily set up a pointer, I want to see why this isn't working.

Hi Borte,
Hint: check what you have in your AmpIOAddr variable exactly before calling SFC. Is it really 110h ? You wrote that access via PQW is OK.

Hello Guys!

Tnx for the replies!

I have checked the address both before, during and after the call and its still the correct address.
I'm using the same variable for SFC14 call 2 networks above and it works fine in that position so I assume that this is not the cause of the error.

I've said earlier that I called it from an FB, this is not true (stupid me!) I'm calling it from an FC with only local temporary data available.

The ControlWord is constructed as shown in the attached picture.
Its a structure with exactly 2 bytes size.

The strange thing is that this program is ok if I simulate it with the Siemens Simulation software. It only gives me this error when I'm online with the real cpu!

I haven't got around to check the AR2 yet, I'll get back with that info as soon as possible.


Regards
Borte

Here's the updated monitoring info...

I can't see anything strange, but maybe you guys have an idea...

How are you loading the value into the AmpIOAddress? It appears, you have 124Hex instead of 110Hex. You are using a TEMP varable, you must load the value in the TEMP after entering the FC and before the SFC call. The TEMPs can be over written in the scan by another block call. Try moving 272 (dec) into AmpIOAddress just above the SFC call. It must be moved each scan.

Im calling this from two places in my program, its used for communicating to two load cells.
The other address is 124Hex.

The AmpIOAddress is an input into the fc. So it's loaded every scan.

You are NOT loading in any new value. Look in the lower right corner of your picture. It has 124Hex in the accum.

I am loading in a new value. The monitoring display was taken from my other call. It's supposed to have the value 124 hex.

I'm wondering if there is something about the #ControlWord data type it doesn't like. SFC15 does not check the data type (it will even let you enter a bool variable), so I'm not quite sure how it interprets your struct. As a quick test, try this:

Create a new variable called #Record, of data type WORD. Set and reset the #ControlWord bools as your normally do. Just before the SFC call, enter this code (it doesn't look like you are using AR1, so this code can just be entered as is):

L P##ControlWord
LAR 1
L LW[AR1,p#0.0]
T #Record

Use #Record as the Record parameter, and maybe it will behave better since the data type matches the card address type. Just a thought.

Also, as a housekeeping matter unrelated to your problem, you don't really need those SET commands before the boolean instructions (sorry, I'm really picky about scan times and like to eliminate extra instructions ).

I got a tip this morning that may help explain it, I have not tried it yet. I just wanted to have som input on the idea first.

In my hardware setup the output area is set as 1 word and consistent over total length.
My structure consists of 2 bytes data. Should I change my hardware config to 2 bytes instead of 1 word?

Regards
Borte

I don't think it has anything to do with the hardware configuration, but it's worth a try. SFC15 "thinks" only in terms of bytes, and it shouldn't matter what the hardware format is as long as the length matches.

Before you change the hardware config, either try what I mentioned above, or enter in the actual local address in pointer format, i.e. P#L 10.0 BYTE 2. I bet it will work.

I tried changing the hardware config. The only result after that was a bus error, so I had to change it back to original config.

I also tried addressing the #ControlWord variable directly by using P#L 36.0 BYTE 2 but that did'nt help either. I'm still getting the same error. So it does'nt seem to be address area either.

Any other suggestions?