IIecVarAccess5.VarAccSetValue3 (METH) ¶ METHOD VarAccSetValue3 : XWORD InOut: Scope Name Type Return VarAccSetValue3 XWORD Input pNode IBaseTreeNode pVariableInformation POINTER TO VariableInformationStruct pSrc POINTER TO BYTE dwSize XWORD pResult POINTER TO RTS_IEC_RESULT

IVariableInformation5 (ITF) ¶ INTERFACE IVariableInformation5 EXTENDS IVariableInformation4 TODO: Remove here and move to the SymbolicVarsBase. it was never “published” as it was always marked with “exclude on compile”. Properties: User AccessRights , inherited from IVariableInformation ArrayOfArrayNesting , inherited from IVariableInformation3 BitAccess , inherited from IVariableInformation BitOffset , inherited from IVariableInformation ClientAddressResolution , inherited from IVariableInformation2 CompleteAccess , inherited from IVariableInformation DontModifyOffset , inherited from IVariableInformation ExecutableMember , inherited from IVariableInformation4 MethodCallIndex , inherited from IVariableInformation4 MonitoringOffset , inherited from IVariableInformation MonitoringSize , inherited from IVariableInformation2 Offset , inherited from IVariableInformation SplitHugeVariables , inherited from IVariableInformation SymbolicName , inherited from IVariableInformation VariableType , inherited from IVariableInformation Methods: IncrementOffset , inherited from IVariableInformation Structure: User (Property)

IVariableInformation5.User (PROP) ¶ PROPERTY User : RTS_IEC_HANDLE

IecVarAccSymbolSetDescription (STRUCT) ¶ TYPE IecVarAccSymbolSetDescription : STRUCT InOut: Name Type pszSymbolsSetName POINTER TO STRING dwSymbolsSetBit DWORD

InterfaceIds (GVL) ¶ !!! Attention !!! When defining new interface IDs, check libraries using this one for ID collisions. good candidates are the Collections_Itfs and the SymbolicVarsBase libraries, where we actually already have collisions. The ITFID_IIecVarAccessX additionally have to be registered in the file svn://server04/CodesysSpV3/trunk/CodesysSpV3/Components/CmpItf.h as they are called by the runtime. InOut: Scope Name Type Initial Comment Constant ITFID_IIecVarAccess3 DWORD 16#33 ITFID_IIecVarAccess4 DWORD 16#48 ITFID_IIecVarAccess5 DWORD 16#4F ITFID_IIecVarAccess6 DWORD 16#6B ITFID_IIecVarAccess7 DWORD 16#6C ITFID_IIecVarAccess8 DWORD 16#70 ITFID_IIecVarAccess9 DWORD 16#72 Adds explicit client offset, since V3.5.7.0 ITFID_IIecVarAccess10 DWORD 16#77 Adds namespace node flags, since V3.5.8.0 ITFID_IIecVarAccess11 DWORD 16#79 Adds attributes to type nodes, since V3.5.9.0 ITFID_IIecVarAccess12 DWORD 16#A0 Adds GetBorders for subrange to type nodes, since V3.5.11.0 ITFID_IIecVarAccess13 DWORD 16#A4 Adds Users to the symbol access, since V3.5.13.0 ITFID_IIecVarAccess14 DWORD 16#A5 Adds ITFID_IIecVarAccess15 DWORD 16#C8 Adds ITFID_IIecVarAccess16 DWORD 16#CA Adds ITFID_IIecVarAccess17 DWORD 16#CF Adds IsReference, since 4.4.0.0 ITFID_IIecVarAccess18 DWORD 16#D0 Adds FindChildByName, since 4.5.0.0 ITFID_IVariableInformation DWORD 16#1001 ITFID_IGetTopLevelNode DWORD 16#1002 ITFID_IVariableInformation2 DWORD 16#1003 This ID accidentally collides with ITFID_ICollectsSecondOffset and ITFID_IBaseTreeNode ITFID_IVariableInformation3 DWORD 16#1104 ITFID_IVariableInformation4 DWORD 16#1106 ITFID_IVariableInformation5 DWORD 16#1107

NamespaceNodeFlags (ENUM) ¶ TYPE NamespaceNodeFlags : The node type of a branch node. Several flags may be set concurrently. Not all of the flags defined here are actually generated yet by the code generator. NOTE : Due to CDS-54976 we could not add new flags here, so they’ve been moved to NamespaceNodeFlagsEx! InOut: Name Initial Comment None 0 Uninitialized variable. NodeTypeMask 16#FF The node type mask - 6 Bits for possible node types and flags NodeTypeBranchNode 16#1 This node is part of the path. It is usually combined with one of the BranchNodeInfo flags below. NodeTypeLeafNode 16#2 This node denotes a variable. Combine with the * VariableFlag below. BranchNodeInfoMask 16#FF00 The bits in this mask define a namespace node not directly corresponding to the POU. Apart from the BranchNodeImplicitRootNode flag, a branch node may have several of this flags set, for example, when a variable has an explicit namespace which equals the application name or library namespace. BranchNodeImplicitRootNode 16#100 The implicit root node (not user visible except when directly using IecVarAccess) In some of the cases when the implicit root node only has a single child, it is not exported to the IecVarAccess tables. It is never exported to the XML, as the ;NodeList elements represents the root node there. BranchNodeApplicationName 16#200 An application name. (May appear on several levels, as apps may be nested.) BranchNodeLibraryNamespace 16#400 A library namespace. (May appear on several levels, as libraries may be nested.) BranchNodeExplicitNamespace 16#800 A path component explicitly specified via {attribute ‘namespace’ := ‘foo.bar’} BranchNodeMemberAccess 16#1000 In the future, we might we allow non-top level nodes like foo.bar.baz to be exported directly, probably combined with one of the flags below. SigTypeNodeMask LWORD#4294901760 The bits in this mask define the type of POU which generated the current node. A single one of this flags will appear at a variable node telling which kind of signature this variable originated from. (Currently not exported to IEC.) One or more of this flags will appear at branch nodes which contain variable nodes, declaring which kind(s) of signature(s) the contained variables originated from. (Due to namespaces set via properties, several variables of different sources may appear below the same branch node.) SigTypeGvl 16#10000 A global variable list SigTypeProgram 16#20000 A program SigTypeFB 16#40000 FBs may actually export var_static, and in the future when we allow non-top-level nodes to be exported. SigTypeStruct 16#80000 For future extension, when we allow non-top-level nodes to be exported. SigTypeMethod 16#100000 For future extension, when we allow non-top-level nodes to be exported. SigTypeAction 16#200000 For future extension, when we allow non-top-level nodes to be exported. SigTypeProperty 16#400000 For future extension, when we allow non-top-level nodes to be exported. SigTypeTransition 16#800000 For future extension, when we allow non-top-level nodes to be exported. SigTypeFunction 16#1000000 Functions may also define static variables which may be exportable. ExportedVariableTypeMask 16#FF00000000 Information about the type of the exported variable. ExportedVariableFlag 16#100000000 Denotes a “normal” exported variable. ExportedStaticVariableFlag 16#200000000 The variable is a “static” variable which is exported e. G. from an FB which is used in the program. ExportedPropertyVariableFlag 16#400000000 The variable represents a property. ExportedVariable ExportedVariableFlag + NodeTypeLeafNode The variable node represents a normal exported variable. ExportedStaticVariable ExportedStaticVariableFlag + NodeTypeLeafNode The variable node represents an exported static variable. ExportedPropertyVariable ExportedPropertyVariableFlag + NodeTypeLeafNode The variable node represents an exported property with monitoring type ‘call’. NodeFlagsMask 16#FF0000000000 The node property flags mask, those bits show some special properties of the nodes. NodeFlagHidden 16#100000000000 This node is hidden, it should not be shown while browsing using the IecVarAcces or CmpIecVarAccess interfaces. (It can still be found by it’s node path, and queried using the IBaseTreeNode interfaces.) It is not exported to XML. As an implementation artifact, hidden nodes currently must always be sorted after the visible nodes. This must be guaranteed by naming the nodes accordingly. This is an implementation detail and may change in future versions.

NamespaceNodeFlagsEx (GVL) ¶ Due to CDS-54976 we could not add new flags to NamespaceNodeFlags, so they’ve been moved to NamespaceNodeFlagsEx! Due to problems with the M4 export, we need to use strange naming. But the usage of those interfaces from IEC is only a corner case, so we can live with that. InOut: Scope Name Type Initial Comment Constant NamespaceNodeFlagsEx_ExportedExecutableVariableFlag NamespaceNodeFlags 16#800000000 The variable represents an executable member. NamespaceNodeFlagsEx_ExportedExecutableVariable NamespaceNodeFlags 16#800000002 The variable node represents an exported executable variable.. NamespaceNodeFlagsEx_NodeHasExecutableChildren NamespaceNodeFlags 16#200000000000 This node has executable children. Some interfaces (e. g. PLCHandler) need to take special precautions for clients which cannot cope with executable children. This flag is mainly for optimization purposes, as it allows to skip the workarounds on nodes without executable children.

RtsBrowseInfo (STRUCT) ¶ TYPE RtsBrowseInfo : STRUCT InOut: Name Type hNode IBaseTreeNode hType ITypeDesc nArrayIndex DINT nStructIndex DINT

VariableInformationStruct4 (STRUCT) ¶ TYPE VariableInformationStruct4 : STRUCT WARNING! If you pass this struct to the IecVarAccess or CmpIecVarAccess, it MUST be initialized with IIecVarAccess9.VarAccInitVarInfo() or IecVarAccInitVarInfo() before usage, and it MUST be cleaned up with IIecVarAccess9.VarAccExitVarInfo() or IecVarAccExitVarInfo(). Weird side effects including crashes and memory leaks will result if you do not adhere to this rule. The new member wMethodMemberIndex nicely fits into an existing gap within the VariableInformationStruct3 struct. Depending on the architecture and global pack mode settings, we either have 3 bytes or 7 bytes gap. wMethodMemberIndex uses 2 bytes, thus a further byte is available for further use. The resulting struct size, which is also stored in the member wStructSize, is unchanged compared to the VariableInformationStruct3 struct. This allows us to implement executables without dynamic allocation in the runtime. Access is additionally guarded by VIF_EXECUTABLE_MEMBER. InOut: Name Type Comment wStructSize WORD wFlags WORD dwOffset XWORD byBitOffset BYTE wMethodMemberIndex WORD xwMonitoringOffset XWORD xwMonitoringSize XWORD dwArrayOfArrayNesting DWORD hBrowseInfo RTS_IEC_HANDLE aBrowseInfoPool ARRAY [0..27] OF BYTE OBSOLETE: Only for backward compatibility. Not used anymore because data is stored in hBrowseInfo pool.

VariableInformationStruct5 (STRUCT) ¶ TYPE VariableInformationStruct5 : STRUCT WARNING! If you pass this struct to the IecVarAccess or CmpIecVarAccess, it MUST be initialized with IIecVarAccess9.VarAccInitVarInfo() or IecVarAccInitVarInfo() before usage, and it MUST be cleaned up with IIecVarAccess9.VarAccExitVarInfo() or IecVarAccExitVarInfo(). Weird side effects including crashes and memory leaks will result if you do not adhere to this rule. The new member wMethodMemberIndex nicely fits into an existing gap within the VariableInformationStruct3 struct. Depending on the architecture and global pack mode settings, we either have 3 bytes or 7 bytes gap. wMethodMemberIndex uses 2 bytes, thus a further byte is available for further use. The resulting struct size, which is also stored in the member wStructSize, is unchanged compared to the VariableInformationStruct3 struct. This allows us to implement executables without dynamic allocation in the runtime. Access is additionally guarded by VIF_EXECUTABLE_MEMBER. InOut: Name Type Comment wStructSize WORD wFlags WORD dwOffset XWORD byBitOffset BYTE wMethodMemberIndex WORD xwMonitoringOffset XWORD xwMonitoringSize XWORD dwArrayOfArrayNesting DWORD hBrowseInfo RTS_IEC_HANDLE User HandleStore varInstance HandleStore aReserved ARRAY [0..11] OF BYTE Not Used: Only for backward compatibility.