-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
Hi, Aliazzz,
I agree, OOP is an essential part of third edition and it would be nice to support it in checker. 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.
I'll take this. For now you will get P.S. Did you manage to compile the project? It should works with demo programs in |
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. I have not tried your example yet apart from reading through the sources but count on it I will do that soon. |
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 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. |
@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. |
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 text was updated successfully, but these errors were encountered: