Function Block in Workbech that take a global variable vs function blocks in SCADAPack x70 Logic public variable

[AlbertoArdila]

Hi

The function blocks in Workbench can accept Global variables inside without be an input in the function block

I tried to do the same in SCADAPack X70 Logic. I created a Function Block with a public variable and put the FB in the custom Library. After, I create a new project, add the function block created from the library, create an elementary variable with a defined initial value and the same name that the public variable inside the function.

The problem is that when I run the program the public variable doesn’t take the value of the global variable  

How can I resolve this problem? , how can I link the global variable to the public variable in the FB?

Please see image attached

Thanks for the help.

[BevanWeiss · Accepted solution]

It was a bad idea for SCADAPack Workbench to support this, and largely came about through the ISaGRAF support for the same.

The concept isn't good from a software engineering stand-point, since it becomes an implicit dependency.

Hence in Logic Editor / ControlExport (and most other modern logic engines) such associations need to be explicit.

You would need to pass these parameters in.

I would not recommend using the Public variable interface to do this.

I wouldn't recommend Public variable interface for many things (only for optional output values really).

If you want to supply values through the Public variable interface, then outside of your DFB (in the application logic) you would need to MOVE or similar the appropriate value into that Public variable for the DFB instance in question (prior to executing the DFB instance).

There is possibly some way to circumvent this by using various system EF / EFB calls.  But this would not be generally recommended (an exception for this would be things that are more generic.. like wallclocktime kind of things).

i.e. in the SCADAPack x70 world you could have an Object defined with a fixed name, and within your DFB you would call OBJ_NameToID to get the ObjectID.  Then you could call OBJ_ReadField to get the .Value field from that object.

But you should NOT do this.  You should define an explicit interface to pass in the information the DFB requires to operate.

The more important the information is, the more explicit the passing in should be (i.e. if it's required for the block to operate, don't pass it in with a Public variable.. make it required as an Input)

NOTE: If you go down this path, and post any request for help about this, I will simply reply with "I told you NOT to do this"

[AlbertoArdila]

Hi Bevan Weiss

Thanks for the answer

In this case I go to use an explicit variable creating an input in the function block.

have a good day

[BevanWeiss]

Why do you keep marking your own posts as 'the solution'?

Do you consider that the people posting answers to your problems haven't appropriately solved your problem?

Just like StackOverflow it should be incredibly uncommon for you to mark a post of your own as the solution.  Unless the other answers really haven't addressed your problem (in which case it might go unsolved), or your own independent investigations have revealed the best solution, in which case you should provide a detailed post of that solution.

[AlbertoArdila]

Hi Bevan Weiss

It is my fault. 

The answer that you gave me is the solution. I replied to say thank you and after mark as solution but I didn’t know that it take that as my solution.

Thanks again.

[BevanWeiss]

When you start a topic, there is a button on every reply that people make

You can mark multiple posts as 'a solution'.  So you could go through the topics that you have already started and "fix-up" any mistakes that you have made in assigning 'solutions'.