s7 300 FC's and temp variables

tny

Member
Join Date
Jun 2005
Location
usa
Posts
105
hi every one!.
i have a question about using temp variables in FC's of s7 300
for example when i write a script like this

A #in1
= #temp
A #temp
= #out1

and use it in different positions; the fcs doesn't work correctly.
this example is very easy so no violence occurs but when the script gets longer and the number of temps are increased, fcs doesn't work correctly. so i have to define in-out variables and assign different M memories seperately for the fc.

how can i use the fc's without using seperate M memories?
 
To start you would better write:

A #in1
= #out1

Then to the question why your FC doesn't work: like you write it, it should work. Post the complete FC and then 'we' can see what the problem is.
 
that was an example, i cant write the real program 'cos it's too long but if i can attach archieved file that will be more understandable.

i had to use M memories for the function because when i used the function (this is turntable) more than once, violation occurs.

how can i attach the zip file?
thanks..
 
thanks again
i attached the file.
as i told before i tried to use local (temp) variables instead of usin M's as input variables, but when i use the fc (fc49) twice,
they effect each other.
this version of fc works well.
 
I think your problem was that you were writing info (0/1) to
your temp_variables and that in the next cycle you wanted to use this info again.

Example; i see that you write info with a SET to m_dolu wich in an IN-variable for who you used a merker M. A temp-variable will lose it's info after the program of the FC is finished.

To explain what you did wrong, i need to see what you did wrong, so post the program what gives you problems. If the program is to long, just make a copy of part of the program.
 
I've just had a quick look at your fc49 and I think you need to review your understanding of passed parameters. For example, the first network has the following code:

Code:
	  A	 #i_tvkntrl
	  S	 #m_tvkntrl
	  A	 #i_ykrd
	  R	 #m_tvkntrl

All of these variables are declared as inputs. Later on in the FC you have coils that are also declared as inputs. This will cause much confusion and much random behavior. Input variables in an FC should only be read. When you call the FC, the value of an input is copied to the FC, the variable you have passed is not used inside the FC.
Any variables that you wish to retain (using Set/Reset for example), must be declared as IN_OUT variables.
Any variables that are always evaluated (e.g. with an =) can be OUT variables.

Shout if you need further clarification.
 
for nw2 (Set m_dolu) the network was like this. there was temp_dolu instead of m_dolu and temp_dolu is defined as temp variable instead of in variable.
if it's not clear i can send you back up file of old version

AN #i_man
A(
A #i_asgd
AN #temp_dolu
A #m_tvkntrl
A #i_pltkntrl
O #q_ykr
)
AN #i_ykrd
O
A #i_man
A #i_ykr_btn
AN #i_ykrd
= L 1.0
A L 1.0
BLD 102
= #q_ykr
A L 1.0
AN #i_man
S #temp_dolu
 
Then your problem was like I told you. You wrote info to a TEMP-variable and wanted to use the info of this TEMP-variable in the next cycle. TEMP-variables will lose their info after the FC is finished. When you call the FC again there will be random information in this TEMP-variable. So never read the info of a TEMP-variable before you write to this TEMP-variable. You can only use a TEMP-variable inside 'the call' of the FC. After the FC is ended the info is lost.


And like Simon sayed;

Use IN-variables for info what you need as input-data for logical functions in your FC

Use OUT-variables for info what you only need as output-data for logical functions in your FC

Use IN-OUT-variables if you need to use your variable as input-, but also as output-data for logical functions in your FC.

Use TEMP-variables for data that is only needed within the FC. This data will be lost after the FC has ended.They can act like merkers (M) inside the call of the FC/FB but they will not keep the info after the call of the FC/FB.

In FB's you have STAT-variables. The info of these variables are retained in the instance-DB of the FB. So in a next cycle you can use the info of these STAT-variables (STATIC) again.
 
hi;
if temp vars are lost after fc ended, why does the output still remains set? i couldn't understand that, if you can explain i would be so pleasent..

A #in1
S #temp1
A #in2
R #temp1
A #temp1
= #out

and the fc is called as;

CALL FC 1
in :=I0.0
in2:=I0.1
out:=Q0.0

i click on i0.0 and release fc sets the q0.0 and it remains set until i clik on i0.1
if the temp vars are cleared after every cycle how does the q0.0 remains set when i0.0 is "0" ?

thanks..
 
Any variables that you wish to retain (using Set/Reset for example), must be declared as IN_OUT variables.
Any variables that are always evaluated (e.g. with an =) can be OUT variables.



Thanks for that one Simon, I wasn't aware of that subtle distinction, although I can see the logic of it now. I guess I've now got a major project after the hols, checking whether or not I've used S or R with OUT-variables anywhere, I've a sneaky feeling I will have somewhere!
 
tny said:
if temp vars are lost after fc ended, why does the output still remains set? i couldn't understand that, if you can explain i would be so pleasent..

Hi tny, the reason for your observed behaviour is easily explained when you consider how parameters are passed to/from an FC. Each time you call the FC, the editor fills in instructions (in the background, you can't see them in the editor) which copy the values of the input parameters to an area of temporary data from the calling block. The called FC refers to this temporary data area when accessing its input parameters. Similarly, outputs from the FC are also written into another temporary data area which the calling routine acccesses and then writes the output values to your output variables.
If you had a very simple program, say one FC called out of OB1, the temporary data area would only be used by the one FC and as it would never be overwritten by anything else, this temp data area would act as a permanent data area.
If you now make your program a bit more complex, say you call the FC twice in succession with different parameters, you should now be able to see that the temp data area will change depending on the parameter values and the two FC's will interact with each other.
If you have a practical program with lots of FCs being conditionally called, you can see that the temp data area will now contain essentially random values. I have seen cases, even in complex programs, where the temp data doesn't change and an incorrectly programmed block works for months, only to stop working when a change is made in what appears to be an unrelated area.
 
It is good you guys got this far.

tny said:
hi;
if temp vars are lost after fc ended, why does the output still remains set? i couldn't understand that, if you can explain i would be so pleasent..
Temporary variables are stored on a stack and the stack is used by other FCs or FBs. The FB or FC that runs previously to the current FC may modify the temporary variables on the stack. A FCs temporary variables are 'initialized' to the way the previous FB or FC left them when the routines returned.

The S7 requires that you understand the concept of a stack. AB doesn't. S7 requires that you understand the concept of a pointer. AB doesn't. You need to read the Berger books and pay special attention to the parts that explain how the S7 passes variables and allocates memory.
 
SimonGoldsworthy said:
Any variables that you wish to retain (using Set/Reset for example), must be declared as IN_OUT variables.
Any variables that are always evaluated (e.g. with an =) can be OUT variables.

Shout if you need further clarification.

Do I understand this correct; I can not use a S/R-function on a OUT-variable? I programmed this;

A #start
S #motor
AN #stop
R #motor

And '#motor' being an OUT-variable. I called this FC two times and this works fine.
 
Your understanding is correct. An OUT variable is always written to at the end of the FC, so if your logic does not evaluate it, you may get spurious results.
 

Similar Topics

Dear experts, I have a question about temp interface address, If i have a temp "temp75.temp78", and i found that this address in DB7, and this...
Replies
4
Views
1,322
Hi all, I would like to know if anyone has any good advice for connecting a generic PT100 temp probe to a Siemens S7-300. I have read some posts...
Replies
1
Views
3,755
hi all, i have a question about function's temp variables. i know that a temp variable must not be read before writing on it. so if i have to set...
Replies
11
Views
4,208
We have a project to communicate Siemens S7 plc using CP341 to Pyromat Plus 300 (Temp controller). We need to know the protocol used by this...
Replies
0
Views
1,855
gents, I am trying to configure communication with EMERSON PK300 controller through port A1 using generic ethernet communication module . I could...
Replies
0
Views
5
Back
Top Bottom