References and pointers

An address instead of a value

Everything so far has dealt in values: you copy a number into a variable. Pointers and references deal in addresses: a variable that holds where another variable lives in memory.

REF_TO

The third edition of the standard added the reference, a type-checked pointer:

VAR
  pTank : REF_TO T_Analog;
  LT101 : T_Analog;
END_VAR

pTank := REF(LT101);

IF pTank <> NULL THEN
  pTank^.Value := 42.0;
END_IF;

• REF(x) takes a reference to x.
• ^ dereferences it: "the variable this points at".
• The NULL check before any use is not optional.

POINTER TO and ADR

The older form, found in CODESYS, TwinCAT and others, and more dangerous because nothing checks the type:

VAR
  p : POINTER TO REAL;
  x : REAL;
END_VAR

p  := ADR(x);
p^ := 3.14;

ADR hands you a raw address. Nothing stops you pointing a REAL pointer at an INT, reading meaningless bytes, or writing past the end of an array and corrupting the variable next door.

Aliasing

This is the real problem: one memory location with two names.

p := ADR(Setpoint);
p^ := 80.0;        (* Setpoint is now 80, and no line mentions Setpoint *)

You search the whole project for Setpoint := and find nothing, while the value keeps changing. Search does not help, code review does not help, and the watch table tells you the value moved but not who moved it. That is hours of diagnosis on a stopped plant.

Three reasons to keep them out of plant code

1. They destroy readability. The strength of ST is that a line says what it does. A pointer breaks that: what changes is only knowable by following an address at runtime.
2. They switch off the checks. The compiler stops you assigning an INT to a BOOL and catches an index outside its range. A raw pointer asks you to give that protection up voluntarily.
3. They stop controllers. An uninitialised pointer, a reference to a local that no longer exists, an address outside the permitted area: either the CPU faults with an access violation, or other data is silently corrupted. The second is worse.

Add that pointers do not travel between vendors. The syntax and the semantics differ, so pointer-heavy code is locked to one platform.

Where they do belong

• Inside a library you write once, test hard, and expose behind a clean interface.
• In handling a large data block from a comms link where copying genuinely costs, after measuring that copying is the bottleneck.
• Talking to devices or protocols that dictate a memory layout.

In station logic, in a motor program, in a sequence, in alarm handling: no.

What to use instead

• VAR_IN_OUT when a block must update something large the program owns. The intent is explicit and the compiler stays on your side.
• A function block with instances when you want the same logic over different data.
• An array and an index when you want to pick an element at runtime. An index can be clamped and range-checked; an address cannot.

The rule

If you find yourself needing a pointer inside process logic, it is usually the design that needs changing, not the memory.