B&R Automation Studio: STRING Return Type in Functions Fix

Problem Details

You want a one-line call in Structured Text such as myString := BOOL_TO_STRING(myBool); inside a B&R Automation Studio user library. The declaration editor and the compiler will not accept a user-defined function whose return type is STRING. Numeric and boolean return types (BOOL, USINT, DINT, REAL, LREAL) are accepted; the string return is rejected.

The confusing part is that B&R's own runtime libraries expose conversion helpers that appear to hand back a string in an expression. That leads engineers to assume the same construct is available to user code. It is not, and the workaround is structural rather than a setting you can toggle.

Root Cause

A function in the IEC 61131-3 model returns a single value by value. Value-returning semantics require the compiler to know the exact size of the returned object and to allocate temporary storage for it in the caller's expression evaluation. A STRING in B&R is a fixed-length character array whose length is part of the declaration (STRING[80], STRING[255], ...), not a managed object with a uniform footprint. There is no single, size-agnostic string type the compiler can return by value into an arbitrary expression.

Several of the built-in "look-alike" conversion helpers are not ordinary compiled functions at all. They are resolved by the language front end and expanded during parsing/code generation, closer to a macro or built-in operator than to a library function that user code can imitate. Because they are privileged constructs of the toolchain, they can produce a string result in an expression while user libraries cannot.

Practical consequence: the restriction is a property of the compiler front end, not a project option, a library attribute, or a runtime version issue. There is no supported way to declare a user function with a STRING return type. Design around it.

Solution 1 — Function With a Pointer Output

Keep the callable as a FUNCTION, but pass the destination string in by address. The function writes into caller-owned memory and returns a status value instead of the text.

Declaration (.fun in the user library):

FUNCTION fcBoolToString : BOOL
	VAR_INPUT
		bValue      : BOOL;
		pDest       : UDINT;      (* address of target STRING *)
		nDestSize   : UINT;       (* usable bytes incl. terminator *)
	END_VAR
END_FUNCTION

Implementation (Structured Text):

FUNCTION fcBoolToString
	IF (pDest = 0) OR (nDestSize < 6) THEN
		fcBoolToString := FALSE;
		RETURN;
	END_IF

	IF bValue THEN
		brsstrcpy(pDest, ADR('true'));
	ELSE
		brsstrcpy(pDest, ADR('false'));
	END_IF

	fcBoolToString := TRUE;
END_FUNCTION

Call site:

VAR
	sFlag : STRING[10];
	bOk   : BOOL;
END_VAR

bOk := fcBoolToString(bMotorRun, ADR(sFlag), SIZEOF(sFlag));

Solution 2 — Function Block With VAR_IN_OUT

The cleaner IEC-conformant option. VAR_IN_OUT passes the string by reference and the compiler enforces the type, so no manual address arithmetic and no size parameter are required.

Declaration (.typ/.fun in the user library):

FUNCTION_BLOCK fbBoolToString
	VAR_INPUT
		bValue : BOOL;
	END_VAR
	VAR_IN_OUT
		sDest  : STRING[80];
	END_VAR
	VAR_OUTPUT
		bDone  : BOOL;
	END_VAR
END_FUNCTION_BLOCK

Implementation:

FUNCTION_BLOCK fbBoolToString
	IF bValue THEN
		sDest := 'true';
	ELSE
		sDest := 'false';
	END_IF
	bDone := TRUE;
END_FUNCTION_BLOCK

Call site (cyclic program):

VAR
	BtoS  : fbBoolToString;
	sFlag : STRING[80];
END_VAR

BtoS.bValue := bMotorRun;
BtoS(sDest := sFlag);

Solution 3 — Inline the Conditional

For a single conversion in one place, the library round-trip is not worth it. Three lines of ST are self-documenting and generate less code than a function block instance:

IF bMotorRun THEN
	sFlag := 'true';
ELSE
	sFlag := 'false';
END_IF

Use this when the mapping is local. Move to a library only when the same conversion appears in multiple tasks, or when the text form must be centrally controlled (for example 'TRUE'/'FALSE' for a JSON or CSV payload versus 'ON'/'OFF' for an HMI label). Centralizing avoids the classic defect where one task emits 'true' and another emits 'True' into the same interface.

Option Comparison

Implementation and Verification

1. Create a user library in the Logical View. Add the function or function block declaration to the library's declaration file — the return type field must stay BOOL/UDINT/void; do not attempt STRING.
2. Write the implementation in the matching ST source file. Build the library alone first to confirm the declaration is accepted before wiring it into application code.
3. Add the library reference to the task and declare the destination string as a local or global STRING[n], sized for the longest literal plus terminator.
4. Build the configuration. A rejected STRING return type surfaces as a declaration/parse error on the function header, not as a link error — if you see a link error instead, the library reference is missing from the task, not the return type.
5. Transfer to the target and open a Watch window on the destination string plus the source BOOL.
6. Force the BOOL to TRUE and confirm the string reads true; force to FALSE and confirm false.
7. For the pointer variant, add an explicit negative test: call it once with a deliberately undersized buffer and confirm the return value is FALSE and the buffer is untouched.
8. Watch the variables declared immediately after the destination string in the same data module for the first few cycles. Unexpected changes there indicate the copy overran the buffer.

Extending the Pattern

The same two mechanisms cover every user-defined "returns text" helper — case conversion, enum-to-label lookup, fixed-point formatting, and building JSON or CSV fragments from process variables. Standardize on one style across the library so call sites look consistent:

Where the destination length varies between call sites, prefer the pointer form with an explicit size argument, or declare the VAR_IN_OUT at the largest length used in the project and document that minimum in the library header.

FAQ