I am new to B&R automation studio and structured text.
I have seen two occasions that putting a comment on a certain line is failing the build.
I am using Automation Studio V6.7.1.5 SP of 14 aug 2026
This not allowed:
END_FUNCTION_BLOCK // Comment → this will fail the build. If one uses (* Comment *) then there is no problem
FUNCTION_BLOCK FB_Test
VAR_INPUT
var1 : BOOL
// var2 : INT → commenting a line out will make the build fail, the build will succeed if (* var2 : INT) is used
var3 : DINT
END_VAR
END_FUNCTION_BLOCK
The build not only fails but also does not indicate what and where the problem.
The error message is "cannot find C:\..\..\libXXX.a. No such file or directory.
It took quite sometime to find out what caused these problem. I am not used that line comments (‘//’) make build fail.
Questions:
In B&R documentation I cannot find any limitations about using ‘//’. So expect these are bugs. Can they be solved in next release? Or list the limitations in documentation and/or help.
Is there an option to have more logging then the default logging. Some kind of verbose logging option that I am not aware of? Or should I look in other file? I searched the complete tree structure of my project but I could not find any clues.
If there is currently no better logging available is it possible to improve this a better error messages, indicating, which file and/or line?
The behavior might be related to the different file types used in Automation Studio.
As far as I know, // line comments are supported in Structured Text source files (.st), but not necessarily in IEC declaration files (.var, .typ, .fun).
For declaration files, I would recommend using (* ... *) comments instead.
This could explain both of your examples without necessarily being a compiler bug.
However, I agree that the compiler should provide a more meaningful error message. Reporting a missing .a library instead of identifying the actual syntax error is certainly not helpful.
it looks like that there’s something wrong or undocumented, I agree (I can reproduce it).
So please reach out to your local B&R support team that they can open a CASE → please refer to this conversation.
A short background info:
from documentation, Automation Studio is (still) dedicated to IEC61131-3 Edition 2
The ‘//’ as official supported one line comment was defined by IEC61131-3 Edition 3, as far as I know. Before, only the ‘(* *)’ comment, independent of single- or multiline, was defined in IEC61131-3.
But: also from documentation, since Automation Studio 6.7, the usage of ‘//’ in declaration files should be supported, if the IEC compliance option “Allow extended IEC language conventions” is activated… which does not seems to be right, as already mentioned by you and confirmed in my small test.
So please reach out to your local B&R support team to raise that issue, as we can’t do this directly from Community, thanks in advance!
Best regards!
PS for local support:
at least in my test the error is thrown from the linker of the task instancing the library function, not from the compiler of the library itself … seems that the compiler / “syntax checker” let the one line comment in the function declaration file pass, so to reproduce the issue the library module has to be deployed and to be called by a task.
Hi Alexander,
Thanks for the quick reply. I send an email to our local support.
Also thanks for the extra information and screenshots.
I did some more testing this morning and also saw the problem in typ files with a different error message. Then in var files I did not see the problem.
One remark:
The help says ‘Starting with AS 6.7 C++ comments in declaration files (.var, .typ, .fun, .fub, .cls)’
C++ uses ‘//’ but also ‘/* comment */’ and not '(* comment *)’.
honestly i do not find this wording in online help. But it would be still ok since only //comment is C++ syntax but /* comment */ is plain old C syntax
it’s indeed written as “C++ comment” in the help, I screenshotted it above
But in the end I think the “story behind the story” means: not just IEC Rev.2 comments but also single line comments as in C++ should be supported.
