S7 Local memory problems...

Hello Guys!

Another S7 question....

I've been having som strange problems for time to time with local memory in the S7 plc's. Especially with temp data but sometimes also with stat data (witch should be the same as using Memory bits).

It seems like I have to reset all local variables in the top before using it in my program. I know that temp variables are only valid inside the executing block and stat variables are always valid. But it seems like I have to reset the data in the beginning of the fc or fb even if im using a "=" statement to update the status. This is probably caused by a program error somwhere but I haven't found it yet.

So I'm just asking for quidelines for proper use of the temp and stat variables.

Hope this makes enough sence so you guys understand my question.

Regards
Borte

Borte

TEMP variables for both FCs and FBs are simply assigned to memory grabbed from the local execution stack whenever the FC or FB is called. No attention is paid to the contents of these registers when they are allocated. You can't control or predict where this memory comes from and how it was previously used. The registers may (almost certainly will) have residual values from previous calls to other FCs or FBs. My own rule is never to read a TEMP without having written to it first - that way I control what is in the register.

A STAT on the other hand exists in the instance data block of an FB and should have a 'permanent' register assigned to it by the CPUs operating system. The values there should be predictable and only affected by the user's application code. If we can't trust STATs to stay the same, we can't trust any DB data!

regards

Ken.

Static data in an FB is stroed ad part of a data block. So it can be manipulated outside of the FB that uses it as it's instance data block. It is possible that a typo somewhere else in the program is causing a write to the instance DB for the FB in question. A cross-reference should highlight this one pretty quick. Just make sure to set your display filter to include DBs. Step7 doesn't do this out of the box.

As for local variables, like you, I believe they are just general memory allocated to the FB when it starts. As such the local variables can contain anything when the FB starts. Make sure the you don't use a local variable before it is equated to something. Be especially aware of jumps that might cause the program to skip an equation you expect to run and set a local variable.
I have personally not run into this before. But most of my S7 prograams have been relatively small and straight-forward. However, the initialization idea is a pretty good catch-all that would save you some grief if unexpected program flow occurs.

Keith

I can't remember the details and I couldn't find the reference quickly, but Siemens do warn that under certain circumstances local data can be random on entering the FB or FC. If the program is such that it it is possible to exit the program without actually using and thereby updating some local addresses, they may not contain what you expect. They suggest you should therefore, at the start of the FB / FC, always initialize the outputs to a defined state

I'll see if I can dig out more detailed information, because it sounds like a possibility for your problems.

Cheers

Roy

You shouldn't have to reset them as long as you are setting the status programmatically first in your code (as you are doing with the "="). For instance (I'm sure you know this), this could present problems:


In this example, the local variable #tempSpeedTooHigh can be randomly high whenever the speed is ok. I see a lot of beginners in S7 make this mistake, but I'm sure you aren't doing that.

A more common programming mistake is using absolute addressing with local variables. This is ok if you are very careful, but I avoid it at all costs. For instance:

Let's say someone has defined a local variable as #tempMotorSpeed (type INT), and it is located at LW40. You also need some local bools to use as placeholders, so you use the next available bits (L 42.0, etc), and let's say that one of them, L42.0, is called #tempMotorOvertemp. At the start of the function, you initialize them by transferring a 0 to the LW:

L 0
T LW 42

This ensures that all local bools are reset. But now, let's say that someone else decides they need to add a new variable, and inserts it at the top of the local data table. If they insert an INT, then your local bools get shoved down to LW44. Your code will still use the correct symbolic bool, but the wrong ones are reset at the top. So, I always reset everything that needs to be reset by using pointers:

Now, even if someone screws around with the local variable addressing, I can still access the correct variables using absolute addressing instead of resetting all of the bools one bit at a time. I would guess that if you have a problem with local data, you are using a mixture of absolute and symbolic addressing, and there is some unintended overlap.

Roy: Thank's this sounds interesting.

I do know how to use the local data, I also know how it behaves. It's just that even if I update the contents before I'm using it somehow still has a different value... It's even giving different readings based on which network I read it in (and yes the variable is still written before it's uesed), I just can't find any reason for this to happen. It's like RMA said, giving random results even when it's begin updated.

S7Guy: I just saw your post while I was writing this...

The error still shows up even when I'm doing it like this:
(btw: what's the vBcode for the code output?)

L #Motor.Speed.Feedback
L 2000
<=I
= #tempSpeedTooHigh

I'll fine search my code to see if I can find something regarding a absolute call to the memory area and overlapping access. I hope I find an error like that, cause if I don't that means I can't trust the status of the bits...

Cheers
Borte

Are you possibly using interrupt blocks? Maybe an interrupt block is being called that affects the local data stack. To my knowledge, I don't know how else local data could be affected during execution of the function. That would make local variables kind of useless.

Btw, to display code examples, use [ code ], [ /code ] (remove the spaces).

Since you seem to be doing everything by the book, it's beginning to sound like it might be related to a question I raised in my first thread here about STRING to REAL conversion. There I had problems because of what looks like a bug in the 317-2 DP firmware, but while struggling to find out what was wrong, I noticed that a command I made at the start of (a fairly long) network to transfer a constant into a Byte in a DB was either not being carried out or was beig reversed by the error in the FC39 call.

I always assumed that memory transfers (as opposed to I/O) would be carried out more or less immediately, effectively on a line by line basis, so to speak. The question is, is this assumption correct, or is the compiler doing (over-) clever things, so as to optimise memory transfers. (In the program, I was building a String in the DB Byte for Byte, so it would seem to have been sensible for the compiler to keep track and then transfer everything at once.)

I presume we'll have some experts somewhere who know the innards of S7 well enough to put us right. I just have to hope they find the threads!

No I'm not using any interrupts in the plc.

If the plc behaves like RMA is describing the this whould be a vaild reason. I just don't know how to verify this.

I have always belived that the plc updates memory as it executes the program. If this is not the case then I have a problem when it comes to the program.
This has always been the basic assumption of the plc system.

Cheers
Borte

I have always belived that the plc updates memory as it executes the program. If this is not the case then I have a problem when it comes to the program.

Click to expand...

Yes, it's always been my assumption too. Fortunately, because I usually program in FUP (that's the German name - can't remember the English one) because I started life in electronic circuit design the boxes somehow remind me of IC's. As a result most of my networks are fairly short. I HOPE that if the compiler does optimise, that it does it on a network basis and not a block basis. But when your working in AWL (Text list?) the networks can be as long as you like - and this one was pretty long.

If the code is genuinely not executed effectively line by line, then I guess I've got one or two potentially flakey programs out there!

I don't believe interrupt blocks (or any other kind of blocks) should affect local data. Each block call should get its own allocation of local memory by the operating system.

Lets say OB1 calls FB1 which calls FC1. There should be 3 lots of local data - 1 for each block. You can see this in the STEP7 cross-reference program structure, where it shows the amount of local memory assigned to a given block and the maximum amount which needs to be assigned through the calling path to reach that block.

Could it be residual accumulator data rather than local data? If you load value 'X' to ACCU1 in a block, call another block and load value 'Y' there, then return to the first block, where's value 'X' now held? Is it in ACCU2 since the second load instruction would have pushed it there from ACCU1? If you expected the contents of ACCU1 still to be 'X' and they are now 'Y' would that account for the symptoms? I don't know the answer to this - just thinking out loud.

Ken.

The code is executed and variables updated line by line, so there is definitely something happening in the logic. Another thing it could be is a pointer problem. Going back to Borte's previous post:

The error still shows up even when I'm doing it like this:
(btw: what's the vBcode for the code output?)

L #Motor.Speed.Feedback
L 2000
<=I
= #tempSpeedTooHigh

Click to expand...

Perhaps the problem is not in the local data, but the static data. Depending on how a person uses FCs and FBs (I manipulate AR2 even during FB calls), a mistake in calculating a pointer will affect which bit in the static data you are looking at. Just another idea.

Ok. Guys!

I agree that it seems like a logic problem somwhere...

I'll scour the programcode to see if I can find any programming errors or mistakes. Errors like this are usually hard to track down.

Cheers
Borte

The code is executed and variables updated line by line, so there is definitely something happening in the logic. Another thing it could be is a pointer problem. Going back to Borte's previous post:

Click to expand...

OK, if that's the case, how come my

L B#16#E
T DB41.DBB0

didn't work when the string definition was STRING[14] and with no changes to the FC program , after redefining the DB using STRING[16] and no other changes , everything worked perfectly?

Peculiar, huh!

Cheers

Roy

I have had similar problems but only if I turn the block on & off. If I have a condition on the rung enabling the block and expect it things to occur on the first enabled scan IE the enabling bit is also used in a one shot that is defind in the stat variables. the results are not reliable. I find it is often better to call the routines every scan unless the scan rate is getting unruly.