In the past, we have routinely used the "add all instance paths" function to automatically add variables to VAR_CONFIG lists. My recollection is that compiling a project did not require VAR_CONFIG to be fully populated, and, once successfully compiled, instance paths could be added. Errors related to missing declarations, if I recall correctly, were thrown when downloading to the PLC, they did not prevent a successful compile. At some point, it stopped working. Missing declarations in a VAR_CONFIG...
If the relationship between level and volume is amenable to it, one thing you can do is to use software that can perform a regression to get a a formula that approximates volume as a function of the level (Excel graphs can do that). Then, instead of a lookup table, you just perform a direct calculation. It makes for more concise code. Obviously, you need a different formula for each tank geometry, but the same is true with lookup tables (or at least their content).
I am the guy from the Stackoverflow answer. Let me attempt to give you a few more breadcrumbs. You are likely to want to achieve any combination of these goals. Make your control logic independent from your hardware Avoid hard-coded hardware addressing. Allow several instances of whichever device you control (e.g. motor) Make your code portable (for me, this means CODESYS and TwinCAT). I have found only one sane way to check all these boxes. This way involves not trying to achieve all these goals...
I am the guy from the Stackoverflow answer. Let me attempt to give you a few more breadcrumbs. You are likely to want to achieve any combination of these goals. Make your control logic independent from your hardware Avoid hard-coded hardware addressing. Allow several instances of whichever device you control (e.g. motor) Make your code portable (for me, this means CODESYS and TwinCAT). I have found only one sane way to check all these boxes. This way involves not trying to achieve all these goals...
Are you trying to achieve the equivalent of generics (i.e. have a "container" function block that contains elements of an arbitrary type, but all elements of the same type for a given instance of the container) or mixed types (i.e. elements of different types within the same container)?
Maybe I am making things look more complicated than they are. Variables defined as "REFERENCE TO" are "direct reference to the same tag or structure just with a different name". I have not used AB environments, but maybe it is not so different after all? As for the rest, what one considers "simple" is always defined in terms of what they know and prefer, as well as the problem to be solved. My "simple" is likely, for good reasons, not the same as yours.
*Perhaps in Codesys you could have the project in the version control so that it does not have any IO (only "AT %I" and "AT %Q"). * This is exactly what I was suggesting, the "project" in your version control being a library, so that it can be referenced from the actual (machine-specific) project. This library can be pre-compiled and versioned (or not). The machine-specific project contains I/O components (fieldbuses, terminals, etc.) and the mappings. That way, if you have an update to the control...
You can put your control logic in a library (i.e. using "AT %I" and "AT %Q" variables as anchor points for mapping, or whipping your own pointer-based strategy to achieve the indirection), and then use a VAR_CONFIG list to map hardware addresses to that software, or use the mapping GUI. Out of curiosity, what method in TwinCAT are you referring to? I am very eager to find out about something I do not know, for the time being we feel TwinCAT is limited compared to CODESYS, because to my (limited)...