Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
I have a problem about Initialization process. My project has 3 POUs and calling sequence as shown below.
In this example, all POUs are initialized, before PLC switches run position. So, C_init.X and C_init.Y gets always 0. In fact, the have to be equal GVL.X and GVL.Y variables. To prevent this, I want to initialize, manually, "MVB_Set_Parameters" with some global variable conditions in Main (PRG).
It can be possible to do this? Can you please help me?
FB_Init (under MVB_Set_Parameters) : Initialization function
//FB_Init is always available implicitly and it is used primarily for initialization.//The return value is not evaluated. For a specific influence, you can also declare the//methods explicitly and provide additional code there with the standard initialization//code. You can evaluate the return value.METHOD FB_Init: BOOLVAR_INPUT bInitRetains: BOOL; // TRUE: the retain variables are initialized (reset warm / reset cold) bInCopyCode: BOOL; // TRUE: the instance will be copied to the copy code afterward (online change) Condition:BOOL; X:INT; Y:INT;END_VAR
FBInit can not initialize FUNCTIONBLOCK inputs since they are INPUTS and thus they are read only and BY VALUE from point of view of method FBInit Method.
Do you mean this as a recommendation, or as a statement of limitations of the compiler?
I do not think the compiler enforces VAR_INPUT to be read-only from within the function block or its FB_Init. VAR_INPUT variable can also be of the "REFERENCE TO" or "POINTER TO" kinds, so inputs are not necessarily BY VALUE. Having FB_Init write to the inputs of a function block is technically possible and valid I think.
Everything I do is structured text only, so maybe things I do in ST would not work for function blocks intent to be used in "visual" languages. I basically use VAR_INPUT as "public members" (as opposed to VAR which I use as "private members", although they are still accessible, just hidden in the IDE's drop-down list).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not think the compiler enforces VAR_INPUT to be read-only from within the function block or its FBInit. VAR_INPUT variable can also be of the "REFERENCE TO" or "POINTER TO" kinds, so inputs are not necessarily BY VALUE. Having FB_Init write to the inputs of a function block is technically possible and valid I think.
I have tested your idea in 3.5.17.10;
The situation is rather complex so bear with me.
1) If the FB is instantiated and NOT called from code, any input can written from the inside of the FB (yes this is valid operation, but I personally think this is NOT a good practice as it makes for code very confusing code due to at least 2 reasons:
1) An instance is "expected" to be called during runtime,
2) If the instance is called during runtime, inputs of the instance are continuously written by the caller, so they are regarded as read-only from within the FB (but technically they are writable but overwritten)
3) If the instance of the FB is NOT called, inputs can written from within the FB body but this is perceived as counter intuitive and should be avoided.
In other words, should you do it just because you can? In this case I'd say no unless you show me some good practical usage* for this. I am looking forward to your suggestions.
PS I deliberately did not mention usage of pointers, interfaces or references (I regard these as "pointers" in general) with which many more tricks can be done. Avoid using them in your example ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think writing to inputs to give them an initial value from a FB_Init is fine in all cases. Of course, thereafter, if the inputs are cyclically fed with values and the inputs are also written to from code, there is going to be a problem.
I use structured text as a "normal" programming language. I have implemented my own cyclical execution framework (my function blocks have no body, and that empty body is never called). My function blocks cannot be used in a ladder diagram, which is not a tradeoff for me because the ladder diagram that would express the systems I design would probably cover entire football fields.
I use VAR_INPUT not as a way to connect my function blocks together and have their code called, but rather as writable public member variables. I make heavy use of this, with most of these VAR_INPUT variables being structures.
I would agree, however, that when relying on the native execution model, writing to inputs would probably very rarely be a good idea (except, perhaps, for setting initial values).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to help out our friend with useful feedback. Since I dont know his knowledge level of ST so I thought not to bother with references or pointers via VAR_INPUT.
Have you got some tips for him?
Last edit: hermsen 2022-07-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please note both the main program and the function block have no body. The inputs are set once at the beginning, not cyclically : I do not know if this fits your intent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
I have a problem about Initialization process. My project has 3 POUs and calling sequence as shown below.
In this example, all POUs are initialized, before PLC switches run position. So, C_init.X and C_init.Y gets always 0. In fact, the have to be equal GVL.X and GVL.Y variables. To prevent this, I want to initialize, manually, "MVB_Set_Parameters" with some global variable conditions in Main (PRG).
It can be possible to do this? Can you please help me?
more posts ...
Changed the anwser after a discussion with @fajean.
Yes the FB_Init can write the value's in the input parameter but calling the FB with input parameters will overwrite the initial value cyclically.
My suggestion
Tip: Just use one program and rewrite MVB_Config into a Function Block and the give in an initalisation method. That way the program becomes modular.
Last edit: hermsen 2022-07-26
You write :
FBInit can not initialize FUNCTIONBLOCK inputs since they are INPUTS and thus they are read only and BY VALUE from point of view of method FBInit Method.
Do you mean this as a recommendation, or as a statement of limitations of the compiler?
I do not think the compiler enforces VAR_INPUT to be read-only from within the function block or its FB_Init. VAR_INPUT variable can also be of the "REFERENCE TO" or "POINTER TO" kinds, so inputs are not necessarily BY VALUE. Having FB_Init write to the inputs of a function block is technically possible and valid I think.
Everything I do is structured text only, so maybe things I do in ST would not work for function blocks intent to be used in "visual" languages. I basically use VAR_INPUT as "public members" (as opposed to VAR which I use as "private members", although they are still accessible, just hidden in the IDE's drop-down list).
I do not think the compiler enforces VAR_INPUT to be read-only from within the function block or its FBInit. VAR_INPUT variable can also be of the "REFERENCE TO" or "POINTER TO" kinds, so inputs are not necessarily BY VALUE. Having FB_Init write to the inputs of a function block is technically possible and valid I think.
I have tested your idea in 3.5.17.10;
The situation is rather complex so bear with me.
1) If the FB is instantiated and NOT called from code, any input can written from the inside of the FB (yes this is valid operation, but I personally think this is NOT a good practice as it makes for code very confusing code due to at least 2 reasons:
1) An instance is "expected" to be called during runtime,
2) If the instance is called during runtime, inputs of the instance are continuously written by the caller, so they are regarded as read-only from within the FB (but technically they are writable but overwritten)
3) If the instance of the FB is NOT called, inputs can written from within the FB body but this is perceived as counter intuitive and should be avoided.
In other words, should you do it just because you can? In this case I'd say no unless you show me some good practical usage* for this. I am looking forward to your suggestions.
PS I deliberately did not mention usage of pointers, interfaces or references (I regard these as "pointers" in general) with which many more tricks can be done. Avoid using them in your example ;-)
I think writing to inputs to give them an initial value from a FB_Init is fine in all cases. Of course, thereafter, if the inputs are cyclically fed with values and the inputs are also written to from code, there is going to be a problem.
I use structured text as a "normal" programming language. I have implemented my own cyclical execution framework (my function blocks have no body, and that empty body is never called). My function blocks cannot be used in a ladder diagram, which is not a tradeoff for me because the ladder diagram that would express the systems I design would probably cover entire football fields.
I use VAR_INPUT not as a way to connect my function blocks together and have their code called, but rather as writable public member variables. I make heavy use of this, with most of these VAR_INPUT variables being structures.
I would agree, however, that when relying on the native execution model, writing to inputs would probably very rarely be a good idea (except, perhaps, for setting initial values).
I am trying to help out our friend with useful feedback. Since I dont know his knowledge level of ST so I thought not to bother with references or pointers via VAR_INPUT.
Have you got some tips for him?
Last edit: hermsen 2022-07-25
Expanding on h-hermsen's final tip, consider this idea:
The main program :
The helper function block :
The helper function block's FB_Init :
Please note both the main program and the function block have no body. The inputs are set once at the beginning, not cyclically : I do not know if this fits your intent.
Dear fajean and h-hermsen,
Thanks for your quick recommendations. I will try them.