IEC61131-3 3 ed. parser for Structured Tex. Almost all IEC syntax constructions are supported excluding some user-defined types and OO features. about iec-checker HOT 4 CLOSED

Hi, Aliazzz,

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?

Maybe, in due time, these KEYWORDS can also be introduced into the checker?

I agree, OOP is an essential part of third edition and it would be nice to support it in checker.
But first things first. I started this project not so long ago, and I work on it in my spare time. Now I am interested in implementing more checks in control flow and data analysis, debug them well and write tests for currently supported subset of language. Then I will gradually add more features from third edition.

This is because the implementation of features introduced in 3rd edition may differ depending on the IDE and vendor. For example, the company where I work uses its own proprietary IDE that implements some OOP constructions different from, say, codesys. This makes support of these features a bit tricky, since they should be configured by the user.

Therefore, at this point I would think it is beneficial to list exactly which KEYWORDS are excluded from your check.

I'll take this. For now you will get ParserError warnings when parser got unexpected keyword.

P.S. Did you manage to compile the project? It should works with demo programs in test directory.

from iec-checker.

Hi!

Thank you for the clear anwser.

My personal experience is that withs some manufacturer dependent IDE's tend to implement only a sparse or very weak form of the norm only for them to say that they are norm "compatible" while in fact their implementation of the norm is only sub par.
Anything that extends the norm could be implemented even further down the road as just any other manufacturer dependent implementation.

I have not tried your example yet apart from reading through the sources but count on it I will do that soon.
plus, a syntax check is only the first step into extensible static code analysis (branches, coding quality etc etc) of which your general direction is headed?

from iec-checker.

a syntax check is only the first step into extensible static code analysis (branches, coding quality etc etc) of which your general direction is headed?

Right now I'm working on representation of the control flow graph. I'm rewriting it to improve support of the nested statements and cover this with unit tests. After that it will be easy to add additional checks for unreachable code, for example, handle the cases with EXIT from loops, when other part of code stills unused. It also easy to check unused local variables in POUs. Then I want to add ARRAY and STRUCT types in parser and some declaration analysis for them.

Next step for me will be an integration with our infrastructure to make this checker work with our (proprietary) ST code and do something useful. Surely this will show bugs in checker, that will need to be fixed.

I haven't thought about what to do after this. It will take me about a few months to get this checker do something useful, then we'll see.

P.S. There is a Python interface to IR created by the checker, so it could be possible to extend it functionality with the scripts. See, for example script that plot control flow graph from Python using graphviz.

from iec-checker.

@Aliazzzz I added support for all essential types. For now everything, excluding OOP constructions should be correctly parsed. I might have missed some constructions, I will add them when I find them.

And here is approximate roadmap for this project: https://github.com/jubnzv/iec-checker/projects/1

I also write a simple web-interface to checker, so, you can try it here: https://idie.ru/bin/iec-checker

Feel free to ask if you have any questions / suggestions.

from iec-checker.