Description
The system data type "ResolvedSymbol" is required to execute the "Symbolic access during runtime" function. The system data type is also used for the "CountOfElements" instruction. It saves references to tags in the PLC program as well as status information for generating the references. The system data type must be in an optimized memory area.
As of FW version 3.0, the system data type "ResolvedSymbol" can be declared as an element of a PLC data type.
Structure of the system data type
The system data type "ResolvedSymbol" has the following visible elements:
|
Parameter name |
Data type |
Description |
|---|---|---|
|
resolved |
BOOL |
Provide information on whether the symbol was successfully resolved:
|
|
status |
INT |
The element "resolved" indicates whether a symbol was successfully resolved. If the symbol was successfully resolved, the parameter "status" has the value "0" and the "ResolvedSymbol" structure contains reliable information.
In addition to these two parameters, the system data type contains internal parameters that save the information on data type, length and address of the tags. However, you cannot access these parameters.
If the resolution of the symbol was faulty, the "status" parameter returns the following values:
|
Error code (W#16#...) |
Explanation |
|---|---|
|
8021 |
The WSTRING for the symbolic tag name is empty. |
|
8022 |
The WSTRING for the symbolic tag name contains invalid characters. |
|
8023 |
The data type declaration of the referenced tag is missing. |
|
8024 |
The reference points to a tag that no longer exists. It may have been overwritten by a loading in "RUN". |
|
8054 |
The data type of the referenced tag is not supported. |
|
80B4 |
The project is inconsistent. |
Invalid references in the system data type "ResolvedSymbol"
The references in the SDT "ResolvedSymbol" can become invalid if the referenced tags are overwritten by a loading process in "RUN" mode. The references may point to tags that no longer exist. An error code at the "status" parameter indicates invalid references.
The following example shows how you can use an IF instruction in SCL to interrupt the execution of a Move instruction in case of an error and resolve the symbol once again:
Before calling the "MoveResolvedSymbolsToBuffer" instruction, a check is performed to determine whether the symbol was resolved successfully and "MoveResolvedSymbolsToBuffer" can be executed.
Even if a symbol was resolved successfully, errors can occur when executing "MoveResolvedSymbolToBuffer", for example, when a tag is overwritten by a loading in RUN mode. In this case, the return value "err" provides the number of failed copy processes.
If a failed copy process is recognized, the subsequent IF instruction sets "EnableMove" to FALSE so that "MoveResolvedSymbolsToBuffer" is no longer executed.
Afterwards, a check is performed with a FOR instruction to determine which symbols supply an error code. For these symbols, the error code is copied to the "status" parameter.
At the same time, the "resolved" parameter is set to FALSE. Now you have to resolve the symbol with the asynchronously operating "ResolveSymbols" instruction again.