TIA Portal v18: Function Block "Static" or "InOut"?

[Mas01]

Hi

Yes, I'm stuck again.

Trying to define a Function Block. What I've put in there so far has been a straight copy/paste from the code (and that includes the global tags being copied over).

Now I'm trying to define the parameters (see pic) and remove any explicit references to global tags defined elsewhere.

The only OUTPUT is the INTeger value 'Needle' over on the right hand side.

Anyone know if I'm correct with the notes I've written on the picture? Am I declaring them properly?

Hope that makes sense - happy to expand if unclear.

Thanks in advance.

 

[Mas01]

p.s. I realise I need to make the tag names start with # for 'internal' declarations.

 

[Mas01]

Cancel that question. I THINK I've got it sorted...(it compiles, at least)

 

[parky]

Think of them this way, Input is what it says i.e. data passed to the function block
Output data passed back out of the function block i.e. some result of some logic or calculation, IN/OUT means both i.e. you pass data to the FB & after modification you pass it back out to the global program.
Temp is just an internal variable only to be used internally in the FB i.e. perhaps as a temporary store or a pointer in an internal loop. (sorry cannot remember what static is a few years since I used TIA), but to sum it up
If you are requiring to do some maths or logic with two variables & returning a result then you need two IN's one OUT, (maybe some temps for temporary store).
If you need to modify a variable that is passed i.e. an IN & pass it back out once modified then it has to be an IN/OUT.

 

[mk42]

The system will more or less take care of the # for you. It isn't actually PART of the tag name, its just an identififier that it's local, not global. If you create a tag called Needle, you can type #Needle in the code and it'll use it. Alternately,you can just type Needle, and as long as there isn't a DB called Needle, then the internal tag will be the top of the dropdown, and it'll know what you mean either way. As you may have noticed, you need quotes around anything with spaces in it, but best practice is to avoid spaces so you don't have to do that.

Your inputs and output make sense to me. The tags that are completely internal to the block wouldn't be inout. Those would be Static, if you want to remember the value in the future, or temp, if you can forget the value once the block is done executing. I think CA_TOL_DEV_Total, as an example, is a great candidate for being a TEMP, as are a lot of the uncircled ones. They are written and immediately read, then never looked at again.

 

[Mas01]

Think of them this way, Input is what it says i.e. data passed to the function block
Output data passed back out of the function block i.e. some result of some logic or calculation, IN/OUT means both i.e. you pass data to the FB & after modification you pass it back out to the global program.
Temp is just an internal variable only to be used internally in the FB i.e. perhaps as a temporary store or a pointer in an internal loop. (sorry cannot remember what static is a few years since I used TIA), but to sum it up
If you are requiring to do some maths or logic with two variables & returning a result then you need two IN's one OUT, (maybe some temps for temporary store).
If you need to modify a variable that is passed i.e. an IN & pass it back out once modified then it has to be an IN/OUT.

As ever, cheers.
The penny's dropped w.r.t. IN/OUT , clear explanation.

 

[Mas01]

The system will more or less take care of the # for you. It isn't actually PART of the tag name, its just an identififier that it's local, not global. If you create a tag called Needle, you can type #Needle in the code and it'll use it. Alternately,you can just type Needle, and as long as there isn't a DB called Needle, then the internal tag will be the top of the dropdown, and it'll know what you mean either way. As you may have noticed, you need quotes around anything with spaces in it, but best practice is to avoid spaces so you don't have to do that.

Your inputs and output make sense to me. The tags that are completely internal to the block wouldn't be inout. Those would be Static, if you want to remember the value in the future, or temp, if you can forget the value once the block is done executing. I think CA_TOL_DEV_Total, as an example, is a great candidate for being a TEMP, as are a lot of the uncircled ones. They are written and immediately read, then never looked at again.

Yes, you're right - there's a few tags in there that are OUT from one block and IN to another. They're better off being TEMPS. Cheers.

 

[Mas01]

Q: Is there a way to copy a FB from one Project to another?

I ask because I created a scratch project as a safe place to develop the FB.

Now I'm happy the FB's working, I want to use it in a different project.

I tried copy/paste, but when the new project opens up, the buffer content is lost.

 

[cardosocea]

Yes, you're right - there's a few tags in there that are OUT from one block and IN to another. They're better off being TEMPS. Cheers.

Temp is not the same as static... if all you have is Temp variables, you can create an FC. If you have Static (keep values between cycles), then it's an FB you want.

 

[parky]

I think you may be getting a little mixed up when we say in/out that is only for your FB block not the built in functions like ADD DIV etc. the parameters passed to your function block in or out or both are the ones that need to be in or out or both, any intermediate (internal to your block) passed to say an ADD function will normally be temps, for IN/OUT variable means for example if you pass a var called Current_Position, & your FB modifies it & needs to be passed back to the main program then it will need to be an IN/OUT variable.
You can use global variables in FB's instead of passing via the interface however, the idea of creating a function block is it can be re-used as the same instance many times, an example of this is say a valve that has two limits, perhaps a manual/auto selection, two limit sensors & alarms you create the block once, call the instance & pass the valve signals to it and return the results back out, then call the block as many times as you like just with different valve in/outs etc. there are two ways of using an FB one is a seperate instance for each call (this produces the code as many times as you have calls (memory intensive as it creates the same code over & over again), creating one instance & passing the parameters to each call when compiled only has one bit of code i.e. a single subroutine so if using individual instances & the code is 30 bytes long & call it 10 times that's 300 bytes plus the overhead of passing the data 30 times, however, if it is the same instance called 30 times it's only 30 bytes plus the overhead of passing the data for 30 calls. Hope that makes sense.
In reality, if you only need this block to be called once then you could just make it without passing any variables just use global variables directly within the FB but it does mean you can save that FB in a library for future projects where you may need it without having to modify internal code i.e. change the variables to global ones in the new project.

 

[mk42]

Temp is not the same as static... if all you have is Temp variables, you can create an FC. If you have Static (keep values between cycles), then it's an FB you want.

This is a great point; if all your stats turn into temps, then your FB might be better as an FC.


There's an addin on the support site that can do the transformation, if that's a path you want to go.


https://support.industry.siemens.com/cs/us/en/view/109773999

 

[drbitboy]

[expanding on what others have said, and the penny dropped, but I started this before I saw all that]

If you need a value to persist between subsequent calls to the FB, then make it either Static or InOut.

The easiest way to categorize the various classes is by how they behave at the external boundaries (interface) of the FB, specifically where the initial value comes from and where the final value goes to:

• Input arguments
  • External Input pin => argument => nowhere
  • The initial value comes from outside the function, from the external variable assigned to the input argument's pin
  • Changing the value inside the function (if allowed) has no effect on that external variable's value outside the function
• Output arguments
  • Internal => argument => external Output pin
  • The initial value comes from inside the function e.g. a constant like zero, or the sum of two input arguments.
  • The value of the function output variable that is outside the function and written to by the function has no effect on the initial value inside the function.
  • The function must write at least an initial value to all output argument variables.
• InOut arguments
  • External pin => arg => external pin
  • The initial internal value comes from outside the function, from the external variable assigned to the InOut argument's pin
  • The internal value, whether changed or not, is written back to the external variable assigned to the InOut argument's pin
  • InOut functionality can be replicated by putting the same external variable on both an Input pin (so the value is initially read from that external source at the start of each call) and an Output pin (so the value is written to that same external source at the end of each call).
    • You typically would not do this since the InOut class is available.
• Temporary variables
  • internal/default => variable => nothing
  • The initial value is always assigned, if present, from the Default column
  • If nothing is present in the Default column, the initial value may be essentially random i.e. whatever the bits are at the memory location temporarily assigned for the variable at the time of the call.
  • If the function is called from multiple places in the external program with different (or same) Inputs, Outputs, and InOuts, then the initial value of the temporary variable in each call instance is independent of the other calls.
  • The total on your first branch could be a temporary value, because it is an intermediate value used only internally.
• Static variables
  • Previous call => variable => Next call
  • The value of a static variable is persistent i.e. it will not change between instances of the call.
  • If the function is called in multiple places in the external program with different (or same) Inputs, Outputs, and InOuts, then the initial value of the static variable in each call instance will be whatever the value was as the end of the previous call instance, even if it was called with different Inputs, etc., during the same scan cycle.
  • The initial value for the first call instance to the routine, comes from the Default column, if present.
    • If nothing is present, I suspect it will be given a value of 0 (or empty string, etc.).
    • That default value will never be written again in any later call references.
  • If you want data to be specific to each of multiple call instances, then use an InOut, so the persistence between call instances is maintained externally, not a Static, which maintains persistence internally.
• Constants
  • Internal/default => constant => nowhere
  • These are sort of like Static, but the value cannot change. Ever.
  • The divisor 2.0 on your first branch, that calculates the midpoint between the inputs, could be a Constant e.g. "#Two".

CAVEAT

There may be subtleties, as well as outright mistakes, in what I wrote here relative to the actual implementation, but that is the gist.

The details of the implementation if Input, Output, and InOut arguments is not important. E.g. scalar (non-array) values could be copied into (Inputs) FB-local memory at the start, and from (Outputs) FB-local memory at the end, and arrays and InOuts could be passed by reference, which means the FB gets a memory pointer to the external variables and operates on those external memory locations directly.

 

[Mas01]

Wow thanks so much for the detailed replies. I'd be completely lost without this kind of help.

I Reckon I'll be using this FB at least 20 times in the code.

Basic question...when I create each new instance of the FB, presumably I need to give each one a unique name, right? Otherwise I'm asking for trouble. Is that right?

 

[parky]

No, unless it has an instance DB not sure why siemens did that seems to go against what others have done I'm a little rusty on siemens but the idea is to reduce memory usage so you only have one instance i.e. same name and call it many times, populating it with the required variables, if it is to use exactly the same variables then you only need one call & the Enable pin (EN) put logic on that to trigger the call when it is required.
I will post examples although not in TIA as I don't have it on this PC but it will give you an idea.

 

[L D[AR2P#0.0]]

You can open another project (read only) in the reference project section and copy/paste blocks from there.