Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IEC61131-3 3 ed. parser for Structured Tex. Almost all IEC syntax constructions are supported excluding some user-defined types and OO features. #2

Closed
Aliazzzz opened this issue May 5, 2020 · 4 comments

Comments

@Aliazzzz
Copy link

Aliazzzz commented May 5, 2020

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

@jubnzv
Copy link
Owner

jubnzv commented May 5, 2020

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.

@jubnzv jubnzv self-assigned this May 5, 2020
@Aliazzzz
Copy link
Author

Aliazzzz commented May 5, 2020

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?

@jubnzv
Copy link
Owner

jubnzv commented May 5, 2020

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.

@jubnzv
Copy link
Owner

jubnzv commented May 10, 2020

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

@jubnzv jubnzv closed this as completed May 10, 2020
@jubnzv jubnzv removed their assignment May 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants