FC16 for S7

tulip

Member
T
Join Date
Oct 2005
Location
ist
Posts
236
I wrote a S7 block.There are two buttons for inputs(First for ONCE and the other for DECIMAL showing).When each Triggered I1.5 it will count step by step from 0 to 9,and When each triggered I1.4 it will be count Step by step from 0 to 4.But when I continuously pressed one of buttons then it is continuously count.I could not understant.Please can you examine this FC.Thanks in advance

FC parameter assignment:

FU01=I1.5
FU10=I1.4
MAX=4
MINU=M0.0 (always 0)
NR=MB20
------------------------
FUNCTION FC 16 : VOID
TITLE =
//FUNKT-NR
AUTHOR : _9509
NAME : FNR4_LCD
VERSION : 0.0

VAR_INPUT
FU01 : BOOL ; // FU01
FU10 : BOOL ; // FU10
MAX : INT ; // MAX
MINU : BOOL ; // MINU
END_VAR
VAR_OUTPUT
NR : BYTE ; // NR->
END_VAR
VAR_TEMP
TEMP1 : BOOL ;
TEMP2 : BOOL ;
END_VAR
BEGIN
NETWORK
TITLE =
OPN DB 254;
A #FU01;
A #FU10;
JC M012;
A #FU01;
FP #TEMP1;
JCN M008;
JU M010;
M008: A #FU10;
FP #TEMP2;
JCN M006;
JU M005;
M012: BEU ;
M010: L DBW 30;
INC 1;
T DBW 30;
L 9;
<=I ;
JC M006;
L 0;
T DBW 30;
JU M006;
M005: L DBW 32;
INC 1;
T DBW 32;
L #MAX;
<=I ;
JC M006;
L 0;
T DBW 32;
M006: L DBW 32;
SLW 4;
L DBW 30;
OW ;
T #NR;

END_FUNCTION
 
Hi

Doesnt look like you have used a one shot to prevent the button counting more than once for a single press. 'Flank' in siemens speak.

However STL is my best strength
 
One-shots are being used (FP instruction) but the storage area specified is the temp area of the FC which will not work. Either re-code using an FB and use the stat area, or, use an INOUT variables for the edge store and assign a non-temp variable.
 
So to help me, is it the case that all the temp variables are essentially scratch variables that are thrown away once the FC code completes
 
"Thrown away" is misleading. The temp area is allocated at each block call from a stack. Depending on the way your blocks are called, it may just so happed that in some cases the stack area allocated for a block is not overwritten by any other blocks - in which case the temp area will "work" as a retained area. A typical symptom will be that a new block call is added to a program that has been running for years and functionality in an unrelated area will change behaviour due to a change in the way the temp data area is allocated and used.
 
OK I understand that. What you are saying is that if you are 'lucky' you will access the same stack data and therefore get away with it.

So best practice would be to only use temps as scratch pad (which i do) or to define them before use

Apologies for hijacking the thread by the way
 
cjd1965 said:
OK I understand that. What you are saying is that if you are 'lucky' you will access the same stack data and therefore get away with it.

So best practice would be to only use temps as scratch pad (which i do) or to define them before use

Apologies for hijacking the thread by the way
Click to expand...

If by define you mean condition, then yes.

In the same manner in an FC where you have defined an OUT, if you were to use it before conditioning (retain the output for instance) it possibly will not work.
 
I arranged a block according to FB,DB and tested.Result wonderful.Thanks for your efforts.....
 
Yes, bu define i really meant assign.

(Temp1=xxxx)

Cheers


PeterW said:
If by define you mean condition, then yes.

In the same manner in an FC where you have defined an OUT, if you were to use it before conditioning (retain the output for instance) it possibly will not work.
Click to expand...
 
Back
Top Bottom