jubnzv / iec-checker Goto Github PK

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 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 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 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.

Background:

OS: Windows 10 - x64

Python Version: 3.9.0

Contribution Concept:

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?

Request:

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.

Benefit:

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.

Concept and Challenges:

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.

• it's always one *.fun file for all POUs per library
• a *.st file can contain the source code of any number of POUs
• several *.st files can also be created to separate POU implementations from each other
• Object-oriented features do not exist at all until today, therefore the location of these cannot be specified

Here's an example:
https://github.com/tkucic/brOscatLib/tree/main/oscatBasic

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.

The current implementation of the test suite in Python seems too complicated.
It could be rewritten in OCaml using cram tests and alcotest/ounit2.

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!!!

We should set maximum supported versions of dependencies in dune-project to avoid backward compatibilities problems in the future.

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