Input vs. Output vs. InOut vs. Static vs. Temp

quadPLC

Member
Join Date
Feb 2010
Location
Milwuakee
Posts
51
I am developing for an S7-1200 in Total Integrated Automation v11 and I see these different local variable types in a function block.

It looks like they are all for conventions and dont throw errors if you use them wrong but can someone run down what each should be used for (especially static and temp).
 
Input - Data passed to the block that will be read only (cannot change its state in the block)

Output - Data passed from the block for use outside (cannot read its state before you condition it)

InOut - Data passed into the block that can be updated and sent out.

Stat - Data used as internal memory that remembers last call states

Temp - scratch data, unknown state until you condition it, used for intermediate logic in the block.
 
Output - Data passed from the block for use outside (cannot read its state before you condition it)
According to the IEC 61131-3 spec you can't read from output registers at all.

I find this to be an inconvenience because I must declare a temporary variable to write and read from and then assign the temporary variable to the output variable. It is a pain but I understand why this was done. If you read from output variables just after you assign a value to them and interrupt could occur and the value of the output variable could be changed from an interrupt. The specifications are written so interrupts or multitasking can't screw up the results.
 
Last edited:
According to the IEC 61131-3 spec you can't read from output registers at all.

I find this to be an inconvenience because I must declare a temporary variable to write and read from and then assign the temporary variable to the output variable. It is a pain but I understand why this was done. If you read from output variables just after you assign a value to them and interrupt could occur and the value of the output variable could be changed from an interrupt. The specifications are written so interrupts or multitasking can't screw up the results.

Do you mean real outputs or fb or fc outputs. I cant see that statement be valid when talking about fb or fc outputs.
 
Do you mean real outputs or fb or fc outputs. I cant see that statement be valid when talking about fb or fc outputs.
I was talking about FCs. I am not sure about FBs since the inputs and outputs are handled differently in FB than FCs. I will find the reference next week. However, I was told by out compiler writer that the specification says you can't read from output variable and can't write to input variables.
 
Good evening everyone.

This is explained in "Programming with step 7".

The sections are here.
27.2.1 Distribution of the Memory Areas
27.2.3.3 Local Data Stack
27.3.4.7 Assigning Data Types to Local Data of Logic Blocks
27.3.4.8 Permitted Data Types when Transferring Parameters

quadPLC, I recommend you to use TEMP(L-Stack) rather than STAT(Instance DB). TEMP can not be overwritten from another logic blocks (OBs, FCs, FBs).
 
TEMP can not be overwritten from another logic blocks (OBs, FCs, FBs).
Yes it can but it takes a little effort/thinking to do. All one needs is a pointer to a variable on the stack. Then simply add a negative offset to the pointer to access variables from the calling subroutine. It isn't wise or easy but it can be done. Likewise, STAT variables can't be accesses unless one 'opens' the DB. This is not likely to be done by accident either.

STAT variables are necessary for FBs to remember their state between calls.
 
Good evening everyone.

This is explained in "Programming with step 7".

The sections are here.
27.2.1 Distribution of the Memory Areas
27.2.3.3 Local Data Stack
27.3.4.7 Assigning Data Types to Local Data of Logic Blocks
27.3.4.8 Permitted Data Types when Transferring Parameters

quadPLC, I recommend you to use TEMP(L-Stack) rather than STAT(Instance DB). TEMP can not be overwritten from another logic blocks (OBs, FCs, FBs).

??? :unsure::confused:
 
I was talking about FCs. I am not sure about FBs since the inputs and outputs are handled differently in FB than FCs. I will find the reference next week. However, I was told by out compiler writer that the specification says you can't read from output variable and can't write to input variables.

In FB's you read the OUTs as these relate to the Instance DB in any case.
 
Good morning, PeterW.

I'm sorry of my insufficient comment.

I would like to say, "Reading manual helps us to reach conclusion." So, I quoted the manual and section title.

I also think narrow variable scope is better.
So, I recommended TEMP rather than STAT.
I know FN and FP cannot be used without static memory.
Of course, I use them (STAT, Shared DB or M).

Programming Step 7 is here.
http://support.automation.siemens.c...tion=cssearch&searchinprim=&nodeid99=&x=0&y=0
 
Good morning, PeterW.

I'm sorry of my insufficient comment.

I would like to say, "Reading manual helps us to reach conclusion." So, I quoted the manual and section title.

I also think narrow variable scope is better.
So, I recommended TEMP rather than STAT.
I know FN and FP cannot be used without static memory.
Of course, I use them (STAT, Shared DB or M).

Programming Step 7 is here.
http://support.automation.siemens.c...tion=cssearch&searchinprim=&nodeid99=&x=0&y=0

TEMP is scratch data area, to recommend TEMP over STAT depends on what you want to do with the data, both have their uses so I cannot see how anyone can blanche recommend TEMP.

You do realise that TEMP data does not remember previous scan logic, you must condition it before you use it in the same block in the same scan.
 
TEMP is scratch data area, to recommend TEMP over STAT depends on what you want to do with the data, both have their uses so I cannot see how anyone can blanche recommend TEMP.

You do realise that TEMP data does not remember previous scan logic, you must condition it before you use it in the same block in the same scan.

Good afternoon, PeterW.

I have read some S7 manuals, I could not find advantages to use STAT. Instance DB can be replaced by Shared DB and UDT.
I prefer FC than FB. FC is easy to reuse because it does not own its static value (Re-entrant). Therefore, I have few chances to use STAT. Static data (for FP) can be included in UDT, and FC takes UDT as IN_OUT parameter.
 
One advantage of using FB+STAT over FC+IN_OUT/UDT is that the FB will be considerably smaller and thus will execute in less time.

ug1.JPG
 
One advantage of using FB+STAT over FC+IN_OUT/UDT is that the FB will be considerably smaller and thus will execute in less time.

Good evening, L D[AR2,P#0.0].
I'm grad to meet you! I think you are a great engineer.

I'm sorry I can not open your project, because I don't have Step7 environment in my home PC. If you already found the reason why "FB is much smaller than FC", Please tell me.

Best regards.
 

Similar Topics

How can I use 1 button and 1 light using only b3
Replies
5
Views
260
Hello The plant is running and there is no shutdown nowadays therefore I can add 1734- AENTR and its card while PLC is in Run? I do not wanna...
Replies
8
Views
352
Hi i would like to ask! Im using Omron CP1E PLC May i know how to use one input to trigger two outputs alternatively? Meaning press X0 on, Y0...
Replies
11
Views
401
Hi, I tried today to get RD3A and WR3A instructions to work on the PLC and it didn't work, but it worked in simulation. I followed the clone...
Replies
18
Views
1,420
Hello! I have a FB with inputs, outputs and inputs-outputs. The build finishes with error, if one of input-output isn't connected. I need an extra...
Replies
3
Views
442
Back
Top Bottom