TEMP Variables in FC

Héllow,

I have a little problem, driving me crazy:

I have an FC with folowing Temp variables:
count1 Int 0.0
count2 Int 2.0
chiller Word 4.0
priority Word 6.0
temp1 Bool 8.0
pulse1 Bool 8.1
temp2 Bool 8.2
pulse2 Bool 8.3

The program works perfectly (in S7-PLCSIM)

Now i need an extra Int, so i add
count3 Int 10.0

(program stays the same) and the program does'nt work... (in S7-PLCSIM)

the program loads a DB and a DI, could it be it overrides this variables? (i tought that temp variables were stord in the L-stack?)

Or is there a problem with S7-PLCSIM?

Thanks,
Ivan.

Can you post the source code of the block ?
What exactly do mean by "doesn't work"
Are you sure you are evaluating all temps before using them ?

The entire program is a little complicated, but this is the part that goes wrong:

CLR
A I0.0 // if extra chiller needed
AN M 20.1 // start pulsgenerator
L S5T#5S // ***
SE T 11 // This pulse generator gives 1 pulse
A T 11 // and continues to give pulses every X minutes
= M 20.1
FP #pulse1 // ***
JC up

....
rest of program
....

up: L DB70.DBW12
+ 1
T DB70.DBW12
JU end


I have found where it goes wrong:

M20.1 gives a signal:
- - - - - _ - - - - - _ - - - - - (5 seconds high, the 1 pulse to 0)
by putting a edge detection it generates:
_ _ _ _ _ - _ _ _ _ _ - _ _ _ _ _ (1 pulse every 5 seconds)

so wen i say " it works" i mean that i get the signal from the edge detection, (so 1 pulse every 5 seconds)
--> so it ads +1 to DB70.DBW12 every 5 seconds.

when i add an extra int
the edge detections doesnt work
--> so it ads +1 to DB70.DBW12 every program cycle.

when i replace the #pulse1 by M20.3 it works perfectly...
So wen i add the extra int, it somhow changes the value of the pulse1 variable to 1...

Verry strange...

Now by using M20.3 the problem is solved, so ill use M20.3...
But if somone has an explenation for this stange behaviour?

_____________________________________________________________
Extra Question:
_____________________________________________________________
I use this for doing the following:
If i get a signal from I0.0 then i need to add 1 machine...
while I0.0 is TRUE i need to ad an extra machine every 5 seconds...

So if there is a more simple solution for doing this, it would be helpfull...

Thanks,
Ivan

As Simon asked, could you post the source of the block.

What makes me worried, you mentione TEMP variables, then you say they are called Count ???

Count would indicate that you need to remember the last state ???

TEMP variables are used only inside the block that they are created in, they DO NOT REMEMBER what state they were in the last time the block was called, you HAVE to preset them before you use them.

So a TEMP variable called Count does not make sense, unless you pass the info to an outside variable which is read back before you use it.

Also DI.... Instance Data Blocks belong with FB's, not FC's, therefore are irrelevant. You can access and change data in Instance DB's at any time but in terms of TEMP's and FC's they don't effect each other unless you code it to.



EDIT.... Pulse 1 CANNOT be a TEMP, it sounds like you are expecting the TEMP's to remember the last scan condition, they cannot.

As Peter says, you are using temps as if they are remembered between calls - they are not. You could convert the block to a FB and move the temps to stats.

It is quite common for this type of error to occur as small projects are developed and get bigger. With a small project, it may just work out that the local data for some blocks actually gets remembered between calls so everything works. As you develop the project and more calls are performed, eventually another block will overwrite the local data area that is being remembered by another block - a classic symptom is that another block that has been working for some time (in some cases for years), will suddenly stop working - the result is usually a lot of head scratching !

Thanks L D[AR2,P#0.0]and PeterW,

The counts i read in from a db, before i edit them and writ them back,
the pulse1 is only used once just afte the "FP" detection to do a conditional jump on a positive edge.

so normally they doesn't need to be remembered....

Ivan.

Hi,
#pulse1 must be a static variable, otherwise the FP instruction does not work properly.

ivanverdonck said:

A T 11 // and continues to give pulses every X minutes
= M 20.1
FP #pulse1 // ***
JC up

Click to expand...

This is the part where it all goes wrong. A FP placeholder can never be a TEMP variable.
It would be the same as writing FP M40.0 and then S/R M40.0 several times in other FC's.
TEMP = local data, local data shared by all FC/FB's.

One of the first things they warn u about on the S7-training......

ivanverdonck said:

Thanks L D[AR2,P#0.0]and PeterW,

The counts i read in from a db, before i edit them and writ them back,
the pulse1 is only used once just afte the "FP" detection to do a conditional jump on a positive edge.

so normally they doesn't need to be remembered....

Ivan.

Click to expand...

The FP remembers the last state of the RLO, then compares it to the current state.
So for the scan when M20.1=true and #pulse1=false then it makes the RLO=true.
Thinking it only needs to be remembered for that one scan is......well not how it works.

When you use TEMP vars, then each scan the #pulse1 bit can be reset in another FC/FB, thus every scan it'll trigger and make the jump.

Carefull what you use for FP/FN........

jacekd said:

Hi,
#pulse1 must be a static variable, otherwise the FP instruction does not work properly.

Click to expand...

Then he would need to make it a FB, since FC's don't got STAT's. (last time I checked)

Jeebs said:

Then he would need to make it a FB, since FC's don't got STAT's. (last time I checked)

Click to expand...

Right. Certain things seems to be so obvious... But, yes, you made a good point.

Thanks!

I now see where i made a mistake...

problem solved!
and explanation found!

And now I'll try to never make the same mistake again!

Thanks,
Ivan.

I think everyone makes that mistake at least once.

Oh well, chances are you won't make this mistake again or find it alot faster next time....