Is there support for overlaying variables, e.g. access an already-declared variable with an overlaid declaration of a different data type? For example, address the individual bits of a variable of a Byte data type with an Array of Bool. (Possibly similar to e.g. Siemens S7 construct using “AT”).
PLCnext Engineer allows “partial access” to ANY_BIT variables, based on the IEC 61131-3 standard.
Partial Access to ANY_BIT Variables ');\n mywindow.document.close(); \n mywindow.focus();\n setTimeout(function () {\n mywindow.print();\n mywindow.close();\n }, 1000)\n return true;\n}\r\n\r\n\r\n Is that what you mean?
PLCnext Engineer allows “partial access” to ANY_BIT variables, based on the IEC 61131-3 standard.</p>[https://engineer.plcnext.help/2023.6_en/Variables_AnyBit_Access.htm</a></p>Is that what you mean?</p>
Well… Yes and no. Same idea, but instead of explicitly pointing to the chosen parts each time the value is needed the idea is to have one variable be located “on top” of another one:
e.g.:
Variable A is a DWORD
Variable B (the overlay) is defined as a STRUCT of various BOOL, SINT etc that is stored in the same place as A.
Thus the content of A can be directly accessed through the components of B.
OK, so Variable B is a pointer to a STRUCT, and that pointer references the memory address of Variable A.
In that case - no, PLCnext Engineer does not support pointers or references.
OK, so Variable B is a pointer to a STRUCT, and that pointer references the memory address of Variable A.</p>In that case - no, PLCnext Engineer does not support pointers or references.</p>
Ok. Thanks for your quick response!
Probably MEMORY_COPY FC can be useful in some cases. It will require additional memory and compute resources, but can provide some approach to “AT” functionality…
Hi Martin, are we able to make this a feature request?
In our office, we’ve run into this situation a number of times. We would love the ability to use the “AT” directive (similar to S7) within the IEC data list and FB interface definitions.
An additional detail: it would be great to be able to set attributes such as “Retain” on the children definitions. In my opinion, attributes of the children should override the attributes of the parent where there is a conflict.
Best regards,
Josh.
Hi Josh,
It depends on the use case of the “AT” directive.
* We won't have it for directly represented variables because in our system these direct addresses simply don't exist.
* For relative addressing of elements in a structure we already have this requirement but plan to release it in a different way: using UNION datatypes. UNION datatypes can point on the same location within a struct from multiple child elements.
Example where a and b have the same start address within MyStruct:
struct MyStruct {
union {
int a;
bool b;
}
int c;
}
The requirement for setting attributes of single UDT elements will be brought into discussion with PnE and firmware development and will assess. Regards, Declan
Thanks for the reply Declan.
I agree that unions would also overcome our challenges, provided that the capability to set attributes upon the UDT elements is also introduced.
Upon reflection, the Union and AT directives seem to be very similar, but strictly speaking I suppose the former applies to declarations only, whilst the latter applies to definitions only. For now, I can think of one illustrative example with different outcomes:
Situation 1: An application developer would like several instances of a structure (multiple of the superset); they require higher fidelity access to each, so they use a union in the declaration. Now every instance shares the same union symbols/references as desired. Finally, the relevant data list has dynamically updated tree-style listings for every structure instance; child attributes are settable by expanding each tree.
Situation 2: An application developer would like several instances of a structure (multiple of the superset); BUT they require higher fidelity access to ONLY SOME instances, so they use the AT directive in a data list to treat the exceptions. Now only the relevant instances have child symbols/references. The data list didn’t need to dynamically update in this case, and it (potentially) remained flatly structured; child attributes are settable directly on the “AT” elements.
Personally, I think Situation 1 provides the most immediate value, and would be happy to use it this way. Working in text is frequently quicker/more flexible than being constrained to work in a table. In fact, it would be nice to provide attribute hints in the UDT to reduce the burden of using the table, but that’s probably for a different discussion .
Thanks for your time,
Josh