This is the third episode of the Tutorial on B&R Automation Studio. In this episode, we will talk about B&R’s Automation Studio’s Variable Scope concept with some brief verification, and also the Logger function.
Let’s get started!
Reference Link
Scope of variables
In B&R programs, there is a concept called Scope, which allows you to build up the extent to which the relevant parts (e.g., variables, structures, FBs, etc.) can be shared. However, as the project becomes more complex, global access becomes a hotbed for bugs. So, think carefully about the Scope of your variables and restrict access to them.
Task-local variables
Task-local variables are not defined globally and cannot be used in other POUs of the project, and yet local variables do not conflict with global variables. In other words, locally declared variables are valid within the program, but global variables are valid outside the program.
It is important to note that if a program is allocated more than once to a single CPU, the memory required for a local variable with a Task will be multiplied by the number of allocations.
Package-local variables
Package-local variables can only be shared and used in the POU of the corresponding Packages.
Package-local variables conflict with global variables of the same name or variables of the same name in other packages.
Global variables
Global variables are variables that have a scope that is valid for the entire project, i.e., they can be accessed from each Package or POU within a Package.
If a program is allocated to the CPU multiple times, the global variables for all its memory allocated objects are allocated only once. In other words, the memory required for global variables does not depend on the number of program and Task allocations.
Nested packages
In Automation Studio 3.0 and later, programs can be partitioned by Nested.
This structure also determines the scope of variables, data types, and libraries declared within Packages and allows for encapsulation of data;
variables and data types declared in Packages are visible only within that Packages and Subpackages. (except when the declaration file is declared as “global” (Public))
Managing global declarations
The names of data types, variables, FBs, and FCs with global scope must be unique throughout the system. This is checked each time the project is built.
This means that variables with the same name cannot exist in more than one Global variable List.When the project is being built, if the system determines that a name conflict exists (e.g., the same name data type is declared in multiple files), an error message will be printed.
Implementation
We will now actually try out the Variable Scope.
Test with Task-local variables
First we will try the Task-local variable: open Packages>Program>Variables.
Thus, Main.st can only access iCounter and bInited.
Test with Task-local variables In Other Program
Now we will add another program in the same Packages.
Open Variables.var in the newly added Program1.
Define some Task-local variables in Variables.var.
Next, we will open Program1>Main.st.
Click the Add new variable button in the red frame.
You can access the three variables just defined in Variables.var.
But since it is Task-local Variables that were just defined, we will try to verify that the variables in Program1>Variables.var can be accessed from Program>Main.st as or not.
Program>Main.st cannot access Task-local variables in another Program.
Test with Package-local variables
Now we will insert the Package-Local variable into a project, selecting .var in the Toolbox.
Add Variables.var to the Packges Folder.
Declare Some Package-local variables in Package::Local.var file.
Packages>Program>Main.st will have access not only to your own Task-local variables, but also to the Package-Local variables you have just defined.
Program1>Main.st in the same Packages will have access not only to your own Task-local variables, but also to the Package-Local variables you just defined, which is a feature of Package-Local variables. In other words, you can access Variables.var directly under that Package’s Folder anywhere in the same Packages program.
Test with Different Packages
Now let’s verify that Packages can access the Packages Local variable in Package1.
As shown in the figure below, Package1 does not have access to the Package Local variable. By using Package Local variables, you can encapsulate your program in your own Package.
Test with Global Variables
Finally, let’s test the Global variable: when the Project was created in Default, a Global variable File named Project>Global.var was already created.
Define some Global variables in that Global.var File.
As you see,Variables defined in Global.var can be accessed from Package>Program>Main.st.
So what about another program with the same Packages?As you see,Package>Program1>Main.st also has access to Global.var variables as well.
Of course, you can also access the Global.var for Programs in other Packages. This is the feature of the Global variable that allows any Program in any Packages to access the Global variable.This feature is useful, but it also makes debugging difficult if you use a lot of Global variables.
Insert a new Global variable File
Multiple Global Variable Files can exist within a project. By adding a .var File directly under the project, the variables defined in the .var File become Global variables.
Define an easy-to-understand name for the var File.
We said earlier that “the names of globally scoped data types, variables, FBs, and FCs must be unique throughout the system. To verify this specification, we define GVL_Nodes.var as a variable with the same name as Global.var.
As you see,The program also appears to have access to both Global.var and Global_Nodes.var variables.
But when I actually build the project, I get an error about duplicate variable names.
Done!We verified this point – “the names of globally scoped data types, variables, FBs, and FCs must be unique throughout the system.
Logger
Finally, we will introduce the Logger function of Automation Studio, which allows you to check how the CPU is operated and now error information.
To use the Logger function, open Open>Logger.
The Logger screen appears, allowing the user to check the current CPU status.
Visable
The left Modules screen has a Visible CheckBox that allows you to configure what type of Logging Message will be displayed in the Logger.
Display Severity
Error, Warnings, Information, and Success in the red frame can also be toggled to show or hide the corresponding Severity by clicking on it.
For example, removing the Informations item hides all Informations Messages in the Logger.
Save the Data
If you are a Machine Builder, you may need to remotely maintain your customer’s equipment. If you want to retrieve CPU information at that time, you can save the current Logger data by going to Logger>Right click>Save Data.
Sets the location where the Logger File is saved.
A File with a .logpkg extension will be output.
The content is an XML base character File.
Refresh
If you want to refresh the current Logger File, just click the Refresh button in the red frame.
Delete the Data
To delete the Logger File, click Delete Data in the red frame.
View the Info
Finally, the Info button provides detailed information on the corresponding Logger Message.
