S7-1500 and temporary variables - strange behavior

I have one strange issue, I'm not experienced enough to understand.
We have generated one FC for scaling and writing to analog outputs, which we use as standardized interface for analog control.
I use it on more than 100 places in my project for one PLC.

In one FC I call this AO, and for channel fault output I assigned one temporary bit variable. I check this temporary variable for channel fault and generate an alarm for HMI if it's on.
I use it like this so I can have easy copy-paste between FCs dedicated for analog control, no need to create hundreds of global variables.

But what happens is some very strange behavior.
This AO FC is not called during testing, since we're still simulating. But alarms related to channel fault appeared in HMI, which should be impossible, since functions for analog reading and writing are disabled during simulation test.
I checked software and only thing that could be is this temporary variable I assigned as channel fault. I checked if this temporary variable goes ON, and it went ON no matter AO FC which writes it is not called!!
Then I went into one FC and forced temporary variable to be always true, which then generated alarm of HMI. But not only for FC where I forced it, but for all FCs using using temporary variable with that name!

This should be impossible by my understanding of how temporary variables work. What could be the problem?

Without seeing your logic, this is just guess work.
But first temporary variables are just that.
They should never be read without writing to them first.
Temp variables uses a shared stack space, so a variable 'A' unless zeroed out before use, could have a left over value from another temp in any other FC / FB / OB.

As Mike mentions, a temporary value needs to be reinitialized for every cycle. You want to make an FB and use a STATIC value.

Yeah, I think that's the reason. I think I'll have to reduce copy-pastability and use global variables for this.
I think problem would disappear in real conditions, but better be sure.

Maybe I'm not understanding what you're trying to do. You wrote an FC named AO and then called this FC numerous times in your program. You edit AO to change the value of an internal temp tag.

If the above is true, you haven't edited just one instance of AO, you've edited every instance of AO, because they all share the same code. That's the point of the internal data.

Also, temp variables used a shared memory space in the 300/400's, but the optimized code in the 1500 is supposed to automatically initialize all temp tags to 0/false. I don't think changing AO to an FB from the existing FC would solve the underlying confusion, although it might make it easier to force bits in one instance of a block.

As an easy test: create a new FC with an INT temp tag and an INT. In the first network, increent the temp tag by one (storing result in the temp tag), then move the value into the output. If you copy this block multiple times, the output will always 1, because the temp tag is initialized for you by the 1500.

mk42 said:

Maybe I'm not understanding what you're trying to do. You wrote an FC named AO and then called this FC numerous times in your program. You edit AO to change the value of an internal temp tag.

If the above is true, you haven't edited just one instance of AO, you've edited every instance of AO, because they all share the same code. That's the point of the internal data.

Also, temp variables used a shared memory space in the 300/400's, but the optimized code in the 1500 is supposed to automatically initialize all temp tags to 0/false. I don't think changing AO to an FB from the existing FC would solve the underlying confusion, although it might make it easier to force bits in one instance of a block.

As an easy test: create a new FC with an INT temp tag and an INT. In the first network, increent the temp tag by one (storing result in the temp tag), then move the value into the output. If you copy this block multiple times, the output will always 1, because the temp tag is initialized for you by the 1500.

Click to expand...

No, I have one FC for flow control. In that FC I use another FC which is our analog output function, it sends valve position to analog output.
For FC for analog output I used temporary variable as variable where channel fault is written and I check this temporary variable and send it to HMI as alarm.
But currently analog output functions are disabled everywhere, since we're still in simulation phase, not remotes are connected, we just have CPU.
What I noticed is that I recieve that alarm (not possible in simulation mode), no matter it's not written anywhere.


Then I tested what is happening by modifying temporary variable to 1 in flow control FC (that calls this FC when it's not disabled in simulation mode). I recieved an alarm as expected, but I also recieved alarms from all other flow control FCs which are using temporary variable with same name (all flow control FCs share same temporary variable names).
All flow control FCs are different, but with same temporary variables names.

What bothered me is why would temporary variables change in all FCs if I set it to 1 in only one FC, I think probably this temporary variable is same memory location for all FCs.

doomsword said:

No, I have one FC for flow control. In that FC I use another FC which is our analog output function, it sends valve position to analog output.
For FC for analog output I used temporary variable as variable where channel fault is written and I check this temporary variable and send it to HMI as alarm.
But currently analog output functions are disabled everywhere, since we're still in simulation phase, not remotes are connected, we just have CPU.
What I noticed is that I recieve that alarm (not possible in simulation mode), no matter it's not written anywhere.


Then I tested what is happening by modifying temporary variable to 1 in flow control FC (that calls this FC when it's not disabled in simulation mode). I recieved an alarm as expected, but I also recieved alarms from all other flow control FCs which are using temporary variable with same name (all flow control FCs share same temporary variable names).
All flow control FCs are different, but with same temporary variables names.

What bothered me is why would temporary variables change in all FCs if I set it to 1 in only one FC, I think probably this temporary variable is same memory location for all FCs.

Click to expand...

Agreed then, that sounds really weird. I'd be curious to see a screenshot or something.

1) You say the temp tags have the same name. Are they also in the same order?

2) Are you running optimized FCs? You can check in the block properties, under attributes. If optimized access is not checked, then the blocks would share address space.

How do you read a temporary value from outside the FC?

mk42 said:

Agreed then, that sounds really weird. I'd be curious to see a screenshot or something.

1) You say the temp tags have the same name. Are they also in the same order?

2) Are you running optimized FCs? You can check in the block properties, under attributes. If optimized access is not checked, then the blocks would share address space.

Click to expand...

All FCs are basically copy-paste, everything is the same since logic is same for every flow control FC, just different valve is controlled.
I checked, it's not optimized FC, could be because I generated these FCs from older FCs in 300/400, I exported them as text and used text editor to edit changes (basically our set of variables are different only by increasing number in name), much faster than doing it in TIA Portal. I think that's why they remained unoptimized.


Some screenshots:


below are temp variables interface, same for all
https://image.ibb.co/mFXhdT/tmp.png


then when you add this network in one of flow control FCs
https://image.ibb.co/ngzTJT/flt.png


for analog output interface that looks like this
https://image.ibb.co/hWzTJT/intf.png


you get this on HMI
https://image.ibb.co/mq4vyT/hmi.png




You can see alarm appeared more than once, yellow are all alarms that were activated (other things I fixed by renaming that variable, surprisingly it also fixed the problem).


I think solution is easy here, either initialize variable (pointless, since this won't be used in calculations) or use global variable, what will I do, to avoid this issue when alarm is not written when in simulation mode. Not a real problem as it would be avoided since this alarm would be written every cycle when not in simulation mode.


But very interesting behavior, not completely chaotic like when you mess up something related to memory management and know it must be something like that. This is a repeating pattern across different FCs (though with same block interface, maybe compiler recognizes this and thinks it's the same FC, giving it the same memory area?).

boneless said:

How do you read a temporary value from outside the FC?

Click to expand...

You don't, it's read in FC where it's defined. It's written by another FC inside FC where it's defined. Since FC that is supposed to write is disabled nothing is writing it.
I got alarms, which should be impossible in simulation mode, and then I realized it's because of this temporary variable, which wasn't written.
When i forced writing in another network, I got related alarm AND all other alarms in other FCs which have same block interface.
Which is what surprised me, I thought this should be impossible.

Can you explain what tag is connected to the alarm?


I just don't see how you can access a tag, any tag, that is declared in an FC.



As far as I know (limited as my knowledge is) the only addresses you can access from the HMI are DB's and global tags.

boneless said:

Can you explain what tag is connected to the alarm?


I just don't see how you can access a tag, any tag, that is declared in an FC.



As far as I know (limited as my knowledge is) the only addresses you can access from the HMI are DB's and global tags.

Click to expand...

Okay, so every FC you have has it's own FC number and own DB99 tag for alarm?


Do you care to share your program? I can take a look if you like




Also, you might try to recompile your whole program. That often helps for weird things..

Doomsword,

Based on the screenshot tmp.png, I can see that the FC is set for "standard access", ie not optimized. This means that the temp tags are using absolute addresses just like they would have in the 300's, and the local memory is not initialized.

Best practice is to make sure you write to your temp tags before you read them. That can be a pain to fix, so it may be easier to just clear out the data. You have two options for initializing your temp tags:

1) Switch to optimized, which will initialize the tags for you, but could potentially affect your program's execution. 75% of the time, when I see standard code in a 1500, it is because it was migrated from a 300, and things COULD be optimized, but no one went and changed the settings in each block. The other 25% of the time, there is a reason the code is standard access.

2) Clear out your temp memory at the beginning of each block. Doing a Fill of 0 into everything could work, but I'm not sure how that would affect your REALs.

boneless said:

Okay, so every FC you have has it's own FC number and own DB99 tag for alarm?


Do you care to share your program? I can take a look if you like

Click to expand...

No way. Too much company know-how inside, don't want to be accussed for information leaking no matter how small chance to be detected. Big problem if you work for a big company.



And yeah, flow control for every valve is another FC, for analog outputting it's only one library FC.