jubnzv / iec-checker Goto Github PK
View Code? Open in Web Editor NEWStatic analysis of IEC 61131-3 programs
License: GNU Lesser General Public License v3.0
Static analysis of IEC 61131-3 programs
License: GNU Lesser General Public License v3.0
Hi,
I'd like to ask why you are excluding some user-defined types and OO features since they are a big part of the IEC61131-3 third edition norm? Therefore, at this point I would think it is beneficial to list exactly which KEYWORDS are excluded from your check.
Excluded OOP KEYWORDS: ABSTRACT, PRIVATE, PUBLIC, METHOD, PROPERTY, GET, SET, IMPLEMENTS, EXTENDS, REFERENCE, REF= .. etc
Excluded DUT's: TYPE .. etc.
Maybe, in due time, these KEYWORDS can also be introduced into the checker?
With kind regards,
Aliazzz
The use of hardcoded physical addresses should be avoided.
So, we have to report any physical address in the code, except those that are used when initializing variables:
PROGRAM l10
VAR
a AT %MW10.2.4.1 : INT;
END_VAR
%MW10.2.4.1 := 42; (* PLCOPEN-N1 *)
a := 42; (* ok *)
END_PROGRAM
This could be implemented as a simple pass on AST.
I wonder if it might be possible to explore adding parsing support for SEL-styled XML files which are the standard export format for the SEL RTAC platform. The SEL RTAC uses the CODESYS logic engine to support 61131-3 development, so any syntactical differences encountered would likely apply to both the RTAC and CODESYS, leading to better support for both platforms as a whole.
I believe that this would help expand the adoption of this tool to parties interested in "linting" their RTAC logic configurations and developed libraries. Additionally, I think it would help to improve open-standards for development style by providing a more consistent base from which engineers can build upon.
I think for "flat" POUs and DUTs, the development of the parser would be quite simple (for the most part) as the files tend to exhibit the standard "interface/implementation" keyword-marked sections.
<?xml version="1.0" encoding="utf-8"?>
<RTACModule>
<POU>
<ExportSource>
<Schema>32</Schema>
<DeviceMOT>3530</DeviceMOT>
</ExportSource>
<Name>Example</Name>
<POUKind>FunctionBlock</POUKind>
<Content>
<Interface><![CDATA[FUNCTION_BLOCK Example
VAR_EXTERNAL
global_var : INT;
END_VAR
]]></Interface>
<Implementation><![CDATA[global_var := 42;]]></Implementation>
</Content>
</POU>
</RTACModule>
Furthermore, I think that it would be relatively easy to differentiate "SEL-styled" XML from "PLCOpen" XML due to the usage of the root XML tag being RTACModule
.
I do foresee challenges in the implementation regarding object-oriented structures (namely "class" FUNCTION_BLOCKs) in the various structures that are required to define properties, methods, actions, etc.
If I'm honest, I think a lot of this could be done on the Python side, making the implementation relatively easy with some regex, but to be truly open, I think that it would be ideal to implement in the OCaml (which is not a language I'm familiar with, but would be more than willing to help contribute towards).
It seems to be incompatible with the code splitting of B&R libraries.
B&R has separate files for variable declarations (*.fun
) and source code (*.st
) of functions and function blocks.
*.fun
file for all POUs per library*.st
file can contain the source code of any number of POUs*.st
files can also be created to separate POU implementations from each otherHere's an example:
https://github.com/tkucic/brOscatLib/tree/main/oscatBasic
We should set maximum supported versions of dependencies in dune-project
to avoid backward compatibilities problems in the future.
I am trying to install the IEC checker on ubuntu. As mentioned, I installed Opam first by following the instructions from [https://ocaml.org/docs/install.html] Installation is done successfully. Screenshots are attached.
After successful installation when I run the command
opam install --deps-only .
to install the dependencies. It says the required argument PACKAGES is missing. Please help me resolve this issue.
Hi jubnzv, your 'dead-code.st' gives me an unexpected result on windows.
Expected result for 'dead-code.st':
Report for test/st/[dead-code.st](http://dead-code.st/):
Report for test/st/dead-code.st:[PLCOPEN-L17] 17:6 Each IF instruction should have an ELSE clause
[UnreachableCode] 25:7 Code block will never be reached
[UnreachableCode] 20:7 Code block will never be reached
[UnreachableCode] 9:10 Code block will never be reached
My result for 'dead-code.st':
Parsing tests\st_examples\[dead-code.st](http://dead-code.st/) ...
Running check for function DEAD_CODE_AFTER_RETURN
Running check for program DEAD_CODE_IN_THE_LOOPS
15:5 UnusedVariable: Found unused local variable: A
17:6 PLCOPEN-L17: Each IF instruction should have an ELSE clause
19:10 PLCOPEN-L10: Usage of CONTINUE and EXIT instruction should be avoid
24:14 PLCOPEN-L10: Usage of CONTINUE and EXIT instruction should be avoid
4:12 PLCOPEN-CP3: Variable SOME_VAR shall be initialized before being used
15:14 PLCOPEN-CP3: Variable I shall be initialized before being used
15:5 PLCOPEN-CP3: Variable A shall be initialized before being used
20:7 PLCOPEN-CP2: All code shall be used in the application
25:7 PLCOPEN-CP2: All code shall be used in the application
9:10 PLCOPEN-CP2: All code shall be used in the application
The following snippet raises false positive for CP1:
PROGRAM l10
VAR
END_VAR
%MW10.2.4.1 := 42; (* False positive PLCOPEN-CP1 *)
END_PROGRAM
Actually, this warning should be reported only when accessing a direct located struct member, as it is specified in the example from the PLCOpen document:
STRUCT EXAMPLE_STRUCT
X : DINT
Y : BOOL;
Z : STRING[40];
END_STRUCT;
VAR
instance : EXAMPLE_STRUCT AT %MW500;
END_VAR
// Write the first character of Z:
%MW504 := 'E';
The current implementation of the test suite in Python seems too complicated.
It could be rewritten in OCaml using cram tests and alcotest/ounit2.
We should use automated release generation for the project for Linux and Windows.
The most challenging step here is Windows support. Currently, I use a Cygwin-based OCaml environment, that contains opam
packages built with MinGW to build the Windows release manually. Probably, we should find another way to build the project on Windows that could be integrated in the CI.
During some early testing, I realized that the OCaml file would need to be placed in a specific location for the Python scripts to be able to reference it. From poking around in the .py files, it looks like the default location for the binary is: ../output/bin/iec_checker
(just like what's shown in the usage example of the main README ). It seems like this could be added as an optional argument to the Python script to allow the user to specify a file path to the binary.
I think that with this added argument, it would be pretty easy for a user to execute:
$ python checker.py <files> -b <path/to/my/copy/of/the/binary/file>
or
$ python checker.py <files> --binary <path/to/my/copy/of/the/binary/file>
What do you think?
If you're not opposed, I could implement the feature in a pull request for your review. I would imagine it wouldn't take much time to perform. Would you be open to such a contribution?
Hi there!
First of all, let me say that this project looks remarkable! I'm very impressed, and I think I'm going to try to put this project to work if at all possible during my regular development.
My problem arose when I was trying the online demo with the "Elevator" example. I added the keyword "PRIVATE" to the FB declaration header as shown here:
and after running the linter, I saw a ParseError. I would have expected the linter to accept the PRIVATE keyword specifier, is this unsupported, or is there something else that is causing trouble for my test?
Thank you!!!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.