Development of PLCgen (see #397) has progressed to the point that all main features are present and running. Issue #676 is tracking progress for making the program available for everybody. That however does not mean development of the program ends with closing #676. There are a still many things left to do in the code generator. The main change of this issue compared to #397 is that instead of constantly building new functionality, the focus here is more at consolidating and improving the program to a mature tool. ## Phase 4+ **PLCgen** * [ ] Test PLCgen for S7-1200/1500, using the test set of small test models from #798, using the lab setup. Report any issues. (#1019, #1100) * [ ] Have a PLC expert do some checks. For instance, to check that there are no blocking issues remaining (not a full re-evaluation, but only checking the points from previous CGI report, and not for safety PLCs). Address any issues that arise. RWS takes the lead here. No ESCET issue is created unless something comes up in the evaluation. * [ ] Ask a maintenance engineer whether the generated PLC code is traceable/understandable enough. Address any issues that arise. RWS takes the lead here. No ESCET issue is created unless something comes up in the evaluation. See also https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_2854113. * [ ] PLCgen: structure event functions in a hierarchy in TIA Portal (#1059) * [ ] PLCgen::TNG (The Next Generation) - different structure of generated code (#1184) * [ ] CIF PLCgen: Preserve Modular Technical Architecture (MTA) in generated PLC code (#1423) * [ ] PLCgen user requests * [ ] PLCgen: incorporate scaling of the analog signals for S7 in IO table file (#1109) * [ ] PLCgen generates code for CIF `real` literals that has warnings if the generated values for PLC `REAL`s have more than 7 significant digits (#1146) * [ ] Bug fixes * [ ] CIF PLCgen: PLC code generator shall define and document an implementation-dependent maximum identifier length (#1424) * [ ] PLCgen code in combination with other code in S7 (#1115) * [~] PLCgen: custom function calls (generic approach) (#1060) **Other** * [ ] Multi-level synthesis (#318) ## Phase 3: For release %"v7.0" **PLCgen** * [x] PLCgen testing for %"v7.0" (#1161) * [x] PLCgen user requests * [~] PLCgen: IO table file: allow a choice of conversion (cast expression) between PLC type and CIF data (#1108) * [x] PLCgen: incorporate scaling of the analog signals for S7 in IO table file (#1109) -> Implemented in %"v7.0", but still to be improved further (issue is not yet closed). * [~] PLCgen: implement unscaling for S7 (#1124) * [~] PLCgen: How to deal with the 64kb block size limit in S7 (#1137) ## Phase 2: Priority 2 (deadline: December 2024) RWS wants to do tests with PLCgen for a real-world object. The object would be closed for the tests. The tests will likely be done in January 2025. The following ESCET-related changes are planned to be finished before then: <details> <summary>Click to expand detailed list of issues for %"v6.0"</summary> **Bugs** * [x] PLCgen crashes on nested arrays (#1017) * [x] PLCgen crashes on compatible enum values being used in assignments (#1018) * [x] Exceeded maximum number of blocks in PLC-code for CPU (#1031) * [x] Failure of the test `op_bind_and_prio_numX` for S7-400 (#1034) * [~] PLCgen TwinCAT self-certification: generated solution files are not valid (#1035) * [x] PLCgen TwinCAT self-certification: build error on `SEL_DINT`/`SEL_LREAL` (#1036, #1041) * [x] PLCgen TwinCAT self-certification: division by zero exception (#1037) * [x] PLCgen TwinCAT self-certification: `VAR_TEMP` not supported in functions (#1038) * [x] PLCgen TwinCAT self-certification: variables from `MAIN` not recognized in `FUNCTION` (#1039) * [x] PLCgen TwinCAT self-certification: Cannot compare type `BOOL` with type `DINT` (#1040) * [x] PLCgen: Insufficient work memory (#1043) * [x] PLCgen: I/O table CSV file 4-cell line confusingly requires only 4 cell-lines (#1044) * [x] PLCgen self-certification test set: the results of the division are not compared correctly, for `op_bind_and_prio_num2` and `op_bind_and_prio_num3` (#1052) * [x] PLCGen: Separate functions for reading input and writing output (#1055) * [x] PLCgen self-certification test set: the results of the tests: `channels`, `expr_binary`, `expr_stdlib` and `tuples` are not compared correctly (#1057) * [x] PLCgen: test `names_s7` fails for S7-1200 (#1061) * [x] PLCgen: ambiguities in IO test (#1062, #1068) * [x] PLCgen self-certification test set: proposal for improvement of the test `timers` (#1076) * [x] PLCgen TwinCAT self-certification: unexpected results for channels.cif test (#1082) **Simulation** * [x] Execution mode for CIF simulator (#1045, ~#970~) * [x] Simulator SVG input mappings that assign input variables (#778, #227) * [x] Rename CIF simulator environment events option to non-urgent events option (#1063) **Controller checks** * [x] Improve feedback in case controller checks don't hold (part of #892) * [x] Improve performance of controller checks (part of #892) **Readability / traceability / small diffs** * [x] PLCgen: (too?) many lines of model overview in generated code (#1022) * [x] PLCgen: 'current location of automaton' text in model overview is confusing (#1023) * [x] Support constants natively in PLCgen, rather than by inlining their values, to improve readability. (!905) * [x] Generate edge selection variables based on absolute names of automata (#923) * [x] Use the names of enumeration literals rather than their indices. (#934) * [x] Don't generate 'magic numbers' in the generated PLC code, as they hurt readability. (#774) * [x] Use less numbers in the generated PLC code in general, as they hurt readability. See discussion at https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_2857456. * [x] Improve the names in the generated PLC code. * Use as much as possible (absolute) CIF names and structure, to be able to relate PLC code back to the CIF model. * For extra generated names (like derived variables for times, but also temporary variables) use prefixes/postfixes, to place them in different ‘namespaces’, such that they don’t conflict with each other, and prevents having to rename the CIF names. * [x] Check that changes (mostly) cause only local changes in the generated code. Address the biggest issues. See discussion at https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_2857439. **Migration/validation** * [x] Include self-certification tests as integration tests. (#1014) * [x] PLCgen self-certification test set: make it easier to compare TIA Portal output against expected test output. (#1033) * [x] Test PLCgen for TwinCAT, using the test set of small test models from #798, using the lab setup. Report any issues. (#1020) * [x] Test PLCgen for S7-400, using the test set of small test models from #798, using the lab setup. Report any issues. (#1019) * [x] Make the old PLC code generator deprecated, making the new PLC code generator the recommended PLC code generator. Do mark the untested targets as experimental (all but S7 and TwinCAT). (#1092) * [x] Declare annotations a stable CIF language feature (used e.g. for `@doc` annotations). (#869) **Other** * [~] Expanding PLC Code Generator with reading/writing to the internal tags for S7 target types (#979) * [x] Document `loopsKilled` variable (#1013) * [x] SBE course 1st version (#742) </details> ## Phase 1: Priority 1 (deadline: September 2024) RWS wants to do lab tests with PLCgen in October 2024. The following list is the ESCET-related improvements that need to be made. For now, the target is S7-300 only. This list is also tracked in epic &3. <details> <summary>Click to expand detailed list of issues</summary> **Bug fixing / testing** * [x] Create a PLCgen test set of smaller models, that cover all supported language features and options, as well as all relevant aspects of the generator (#798). * [x] Execute the test set in the lab. Fix any issues that are found. Make any architectural changes necessary to fix the issues. (#798) * [x] 'Test' the documentation. (#798) * [x] Fix bugs that were found while testing: * [x] !920 Make "timer" a reserved word in PLCgen * [x] #770 Expression/type related improvements/fixes. * [x] #818 PLCgen crashes on nested tuples. (!876) * [x] #847 Problems with `EXPT`. * [x] #847 Problems with parameters of function calls. * [x] #847 `MIN` and `MAX` on non-`int` issues. * [x] #848 Problems with `"DB"`. * [x] #848 Problems with semicolons. * [x] #849 Documentation does not list the right steps (for TIA Portal v15). * [x] #850 Problems with timers (this bug has priority). * [x] #852 Documentation has a timer example model with a syntax error. * [x] #854 Allow having a type extension to a prefix function name (e.g., `SEL_...`). * [x] #857 PLCgen crashes on models with switch expressions. * [x] #858 CIF to CIF transformation to transform 'switch' expressions to 'if' expressions doesn't handled nested 'switch' expressions. * [x] #859 PLCgen should disallow 'switch' expressions on tuples/arrays. * [x] #860 PLCgen test model "empty" does not execute on S7-300 * [x] #862 PLCgen test model "timers" does not compile * [x] #863 PLCgen test model "tuples" does not compile * [x] #868 Boolean algebraic variables don't update in PLC-code * [x] #876 Drop power and exponentiation support in PLCgen. * [x] #877 PLCgen test model "constants" does not compile * [x] #884 PLCgen: I/O table entry address size is always checked against target's max integer size * [x] #890 PLCgen test model "io" does not compile * [x] #901 PLCgen: S7 has additional naming constraints / #921 PLCgen test mode "names" does not compile * [x] #912 PLCgen: Error when compiling code for large model * [x] #923 PLCgen: generate edge selection variables based on absolute names of automata * [x] #934 PLCgen: use smallest integer representation possible for ranged integer and enum-typed variables/constants. * [x] #935 PLCgen: split generated `MAIN` over multiple functions to prevent too large code * [x] #945 Rework PLCgen name generator * [x] #965 PLCgen: using bound from controller properties annotation's bounded response could lead to killed loops * [x] #967 PLCgen crashes on invalid I/O table files * [x] #968 PLCgen test models "op_and_bind_prio_num" do not comply with expected results * [x] #969 PLCgen: constants with enum values get unsupported values if enums are eliminated to constants * [x] #980 PLCgen test model "sync_events_funcs" does not compile * [x] #984 PLCgen: location pointers have names ending in '.' * [x] #986 PLCgen: event functions should not directly write to input variable * [x] #987 PLCgen s7 documentation: small improvements for steps in TIA Portal **Controller checker** * [x] In the generated PLC code, use two 'while' loops, one for uncontrollable events and one for controllable events. (#628) * [x] Adapt other tools to be compatible with using two 'while' loops for uncontrollable/controllable events. (#628) -> Superseded by #970 (see below) * [x] In the controller checker, compute 'while' loop bounds, separately for uncontrollable events and controllable events. Add as an annotation to the CIF model. (#621) * [x] Use 'while' loop bounds in generated PLC code. (#816) * [x] Add non-blocking under control check to the controller checker tool. (#410) * [x] CIF controller properties checker for bounded response has performance issues. (#911) -> Done, for as far as it was planned for this phase. * [x] Document and use a consistent transition execution order for CIF tools that use it. (#970) -> Done, for as far as it was planned for this phase. **Documentation/traceability** * [x] Support @doc annotations on all CIF elements that have a name or can have a name. (#593) * [x] Make @doc a non-experimental feature. (#869) * [x] Generate documentation in the generated PLC code for @doc annotations, similar to how the CIF code generator does it. (#814) * [x] Add more comments to the generated PLCgen, for input reading, state initialization/updating, and output writing, similar to how already done for transition code. (#815/!902) * [x] Document the general structure of the PLC code in the PLC code (first read inputs, then perform transitions, then write outputs). (#805/!878) * [x] Document in the code generator why we read inputs at the start and write outputs at the end. (#831) * [x] Preserve names of state/event exclusion invariants, to ensure they end up in the generated code. (#830) * [x] Allow to customize name of variables connected to an I/O address. (#897) **Versions** * [x] Generate comments with application name, version, and date/time of generation in PLC code. (#805) * [x] Allow users to supply additional information to be incorporated in the header of the generated code. (#805) </details> ## (Other) things to do From here on, all other things that could be improved in PLCgen are listed. Not all may actually be picked up. Some are duplicates of the new lists of above. It should be considered a wishlist. ### Preparation - [x] Copy remaining relevant points of #397 to here. - [ ] Integrate `TODO` items currently sprinkled throughout the code. (#397, point 26) - [x] Add list of possible improvements from the report published by CGI for as far as they relate to the PLC code generator. - [x] Finish and close #676 - [x] Finish and close #397 with respect to all points that have not been copied to this issue. ### Bugs - [x] PLCgen Siemens target: location variables get assigned non-existing values. (#675) (#397 point 31) - [x] Proper code generation for the Siemens target wrt timers can arguably also be seen as a high priority improvement/fix. See also the 'Targets' section below (https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#targets). (!912) - [x] Protect the PLC from getting negative TON end-values. (!912) - [x] `cifplcgen` is missing from the scriptable tools overview in the CIF documentation. (!731) - [x] Issues found during testing of generated S7 PLC code (thanks to @jverbakel): - [x] State variables need a memory address when they are in a global table, or they can be stored in a DB file. (Fixed, they got moved to a DB file in the mean time.) - [x] Double underscore sequences in an identifier are not allowed (Gets fixed in !806). - [x] `firstRun` variable does not exist. Comment: Also check its initialization value. - [x] `preset_timer_t` variable does not exist. - [x] `timer` is a reserved word (it's a function block type in S7). (!920) - [~] Fights between local variable name, global variable name, and eg types can be resolved by prefixing local variables with `#` and adding `"` around global variables. (rejected, as not supported by all PLC vendors) - [x] PLC timers use `TIME` type, while CIF uses real numbers to express duration. Conversion is needed with a cast from a number to `TIME`, eg by `timer0.PT := DINT_TO_TIME(LREAL_TO_DINT(#preset_timer_t * 1000));`. CIF does not prescribe a unit for `time`, but generally we use 'seconds' as unit, and the PLCgen docs describe this already as well. (!912) - [x] `SEL` function expects boolean values to select, other types must be denoted by appending a type, e.g. `SEL_LREAL`. (#854) ### Conceptual cleanliness - [x] Reconsider how a function block call should be created. Currently, the code that produces calls to the timer function block may have too much knowledge about PLC target information. See https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/683#note_1320599, https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/688#note_1349579 and https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/770#note_1700315. - [x] !785 tried and failed in the current setup of variables and functions. However, as noted in https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/785#note_1704688 the problem could be that variables and functions are much closer related than they are usually in other languages. The direction therefore could potentially be to merge these concept in the core data (possibly with interfaces), and then variables, functions, function blocks, POUs, and programs all collapse to the same basic idea. - [x] Reconsider the model classes for functions, function blocks, function calls, variables, etc. See https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/785#note_1704170. (#770) - [ ] `ExprGenerator` has a bunch of `// S7-400 and S7-300 only support <<OPERATOR>> on the same types.` It ensures these restrictions without regard to the actually used target. Other comments seems to point at similar considerations, check all line comment in that file. (Remarks deleted in !1151) - [x] Variable tables have confusing names. Method `addTimerVariable` is used to add non-timer variables. Reconsider it all. See also https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/697#note_1392717. Fixed in !770. - [x] As suggested at https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/770#note_1658164, cleaning up variable access with respect to getting the name or getting the stored value of the variable is useful. Fixed in !785. - [x] Drop writing to derivatives in the expression generator and the underlying `CifDataProvider`, as CIF doesn't support that (in !1093). - [ ] Drop the special case of keeping constants generated from "Constants created by Convert enumerations are not inlined." See also https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/905#note_2405184 - [ ] State variables that get copied for reading their values during update should not have a copy for each different event. - [x] The `PlcFuncOperation` field should move from `PlcSemanticFuncDescription` to `PlcBasicFuncDescription` as it is needed more often. This will drop the `PlcSemanticFuncDescription`. Done in #877, !956 - [x] Re-organizing initialisation of funcdescriptions seems like a good idea too. Too many parameters in the constructors currently. - [ ] Re-organize the main driver code in the target, such that various generators only exchange data through the main driver (instead of through invisible back-doors directly between different generators). See #993 ### Industrial usage A [Dutch report (PDF)](/uploads/cced4b3b7fed5b00587505d1becfc663/ROK-IA.SBE.RAP01_v1.0.pdf) was written by CGI for RWS about PLC code generation in synthesis-based engineering (SBE) context. Many conclusions are about the design process, rather than about implementation issues in the generator itself. Here, only the latter are considered. The identified points have been given a brief English description. The `V` and `A` references relate to points in the report. The `V` references are safety related, while the `A` references are more general considerations from system development. - [x] Ensure suitably short PLC cycle execution times (`V-3`). (see #621 for event loop bound calculation, #816 for using them in PLCgen) - [ ] Avoid using the `WHILE` statement (`V-4`). - [x] Add suitable comment lines to the code what it is doing (`V-6`), eg `read inputs` or `try to perform event E`. (#782 adds comments to the code) - [x] Add more details to input and output code about what is read or written. (#815) - [x] Add more details to initialization of state variables, and updates of continuous variables. (#815) - [ ] Extend the code generator to include safety PLCs (`V-1`, `A-7`). - [ ] Avoid `set`/`reset` function blocks (`V-7`). - [ ] Include the used versions of the input models, synthesis software, and code generator in the generated code (`V-10`). (#805 allows inserting a text-file at the top of the code) - [ ] Allow function blocks to be included from a model (`A-2`). - [ ] Allow having user-parameters to tune/configure system behavior without falling back to changing the models (`A-3`). - [ ] Enable relating between modeling information and the generated code (`A-4`, `A-13`). #587 was a first step in this direction, but is obsolete now. #593 is working on the underlying foundation to enable `@doc` annotations, and #814 is about using `@doc` in PLCgen. - [ ] `A-4` specifically addresses the need to relate generated guard tests for a requirement, while - [ ] `A-13` addresses the reverse need (which requirements are addressed in this code?) - [ ] See what else is need to ensure traceability. - [ ] Ensure that small changes in the models don't lead to large changes in the generated code (`A-5`). - [ ] I/O table file: allow more PLC data types for S7 (#1107) ### Improve user-experience (UX) - [ ] Add PLC input/output annotations for linking sensors/actuators to CIF variables. (#1049) - [ ] Add `@plc:input` annotation. - [ ] Add `@plc:output` annotation. - [ ] Allow them without arguments, to just mark them and have them be considered for code generation. See also https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_2534561. - [ ] Allow customizing addresses, etc, like in the I/O table file. - [ ] Add `doc` annotations for attaching documentation links to elements in the CIF specification. #593 #814 (old: #587 (#397 point 28)) - [ ] Add user-defined internal functions (#397 point 18). - [x] Add continuous variables (#397 point 6, #630 implements it ) - [x] Prechecker "continuous variable as timer" sometimes emits strange error reports, see #681 (!798) (!819) - [x] Allow using algebraic variables (#956), continuous variables and locations as outputs, not just discrete variables. - [x] Generate code/type dependencies file (#994) ### Pre-checking - [ ] Consider generalizing the 'continuous variables as timers' check and move it to `common.cif.precheckers`. (#397 point 31) - [ ] Implement non-blocking under control checking, described in Reijnen 202, needed by plcgen, may possibly be done independently (#397 point 25, #410). - [x] Disallow `list[0]` completely (!879 fixes this). ### Testing - [x] Reduce test duplication. (#781) - [ ] Test the validation performed by `InputOutputGenerator` for I/O table files. - [ ] Ensure all `cif2plc` tests and/or tests from the test set of #798 are added to the `plcgen` integration test set. - [ ] Test that all options have the desired effect on the generated code, for all targets. - [ ] Perform testing for what function notation forms are supported by what target, and update the target classes to match that. (is part of #798 for S7-300) - [ ] Perform extensive testing of the new PLC code generator, on real PLCs, for the various targets. (is part of #798 for S7-300) ### Options - [x] Check which options are really useful. Maybe some could be removed and just decided by the target instead. (See https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_1657463 for the argumentation that why it is considered done.) - [x] Add "auto" to the convert-enums option to let the target decide. (!764) - [x] Check and handle other options that lack an `auto` value. (See https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_1657458 for the argumentation why it is considered done.) - [ ] Enum conversion should handle three output forms: Enumeration values, constants, and numbers. - [ ] Consider renaming options, but only if we agree that is a good idea. See https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_1392038. - [ ] Consider a different name for `convert-enums`, such as `convert-locations`, to improve clarity in what it does? - [ ] Consider a different name for `simplify-values` to avoid confusion with `convert-enums` functionality? - [x] Replace the `PlcFormalFuncInvokeArgOption`, `PlcFormalFuncInvokeFuncOption` options by 'supported function invocation notations'. (!688) - [x] Remove the `PlcFormalFuncInvokeArgOption`, `PlcFormalFuncInvokeFuncOption` options. (!697) - [x] Add the `PlcMaxIterOption` options. (!697) - [ ] Output **file** option is not always for creating a file. ### Code improvements - [x] Consider **generating names in code more carefully** so there is a system in place. See also https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/664#note_1262087. - [ ] Consider adding an **analysis+rewrite step** to improve generated PLC statement models (from #397 point 8, and several other sub-points so it covers all available expressions). - [ ] Consider improving **algebraic variable** handling beyond replacing them with their definitions (#397 points 21/22). Perhaps with the analysis framework? (#1056) - [x] **Implement constant declarations and usage** in the PLC (from #397 point 3). - [x] Code still has some `root[Cif]Provider` names, they should be renamed to `scopeCifProvider`. (#397 point 31) (!751) - [ ] Currently there is a requirement "The continuous variable is only assigned in a single-variable assignment, not in multi-assingments.". This seems an unnecessary limitation. (#97 point 31) - [ ] Reduce restrictions for precondition check on continuous variables: - [ ] Checker currently requires 'Continuous variables, if explicitly initialized, must have an initial value that is zero or larger, and this must be statically decidable.' We may want to reconsider this. See also https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/700#note_1477524. - [ ] Checker currently requires continuous variables to be assigned only in single-variable assignments, while the implementation does support multi-assignments already. See also https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/700#note_1477527. - [ ] Checker currently requires continuous variables to be initialized to, assigned, or compared to, a non-negative value. Not all of these restrictions may be needed. See also https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/700#note_1517084. - [ ] Remove `app.framework` paths from the writers. See #666. ### Event transitions code improvements - [x] In **event transition code magic numbers are used to point at automata and edges**. It should likely use CIF automata and CIF location names instead. (#397 point 29) (#774 discusses names and number triplets like `12_34_456` (automaton, location, edge) ) - [x] **Event transition code could use more comments what is being done to guide the reviewer**. For example - [x] mention the automaton that owns the edges being checked. (#782 adds comments to the code) - [x] Some empty lines eg between different events could be useful too. (#397 point 29) - [x] other improvements if needed/useful. - [x] Use better names or add comments to make it easier to **find the connection between guard checking code and update code** of the same edge. (#397 point 29) (#782 adds comments to the code) ### Performance - [ ] Add sequencing of event transition processing (Reijnen 2020, #397 point 23): - [ ] Collect querying of state data in guards and state updates. [See issue #595 ] - [ ] Construct a graph as input for the algorithm. ### Targets - [ ] Add a timer type-name (`IEC_Timer` for S7). - [x] Allow for a function name suffix (`.TON`) with a function-block instance. (!785 ) - [ ] Consider integrating `Writer` classes more with `Target` classes (#397 point 27) - [ ] Targets could perhaps also use a fresh look at their code (#397 point 27). - [ ] `S7` (!770, !785) - [ ] `ABB` - [ ] `PlcOpen XML` - [ ] `TwinCAT` - [ ] `IEC 61131-3` - [ ] Siemens target currently banishes all forms of array, but as PLCgen relies less on functions, the reason for that in cifplc (".. because S7 doesn't support functions returning arrays and doesn't support arrays of arrays.") seems to leave room for improvement. - [ ] Try to add links to public PLC system documentation for reference for the targets (see https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/770#note_1657881 ) - [x] `PLCopen XML` -> https://reference.opcfoundation.org/nodesets/87 - [x] `IEC 61131-3` -> No public access, Wikipedia has a short description https://en.wikipedia.org/wiki/IEC_61131-3, likely other targets are useful too. - [x] `TwinCAT` -> https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/2529458827.html&id= - [ ] `ABB` - [ ] `Siemens S7-300` - [ ] `Siemens S7-400` - [ ] `Siemens S7-1200` - [ ] `Siemens S7-1500` - [ ] Improve output for targets: - [ ] Newer TIA Portal versions support 'enums' (#851) ### Other - [x] Improve naming in the generated code, and add documentation that explains the generated code. (#774) (#782 adds comments to the code) - [ ] CIF assumes that both input and output variables are part of the state. This is debatable as often these variables are only pass-through copies of the read input data or created output data. (#397 "other considerations" at the bottom) - [~] Since all code and data lives in the main program, there isn't any need to make a copy of the inputs to a state variable. It can simply always use the input variable itself instead. - (As noted in https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_1656095, using the input variable itself may at some point interfere with input changes due to actions from the asynchronously running safety PLC.) - [ ] Another form of this improvement can be not use a state variable for storing read input. That value is valid only for the duration of the cycle, and could be a temporary variable instead. - [ ] As noted in !619 (comment 1159022) the chosen approach of performing event transitions by first deciding complete feasibility of an event before even considering performing it means that guard checking code of an edge and the update code that the edge may perform are not close to each other in the source code. This complicates code review. (#397 "other considerations" at the bottom) - [x] #628 should be decided at some point. (#397 "other considerations" at the bottom) - [x] See what else to do to address the recommendations from the report that CGI wrote for RWS about PLC code generation: [ROK-IA.SBE.RAP01_v1.0.pdf](/uploads/cced4b3b7fed5b00587505d1becfc663/ROK-IA.SBE.RAP01_v1.0.pdf) - [ ] See whether our generated PLC code (especially for multi-level supervisors) can make use of TIA Portal's 'software units' feature. See https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/679#note_2946823. ### Migration - [ ] Does it support all tool options, properly. (#397 point 32) - [ ] Does it have all the features of the current/old PLC code generator? Is it a full replacement? (#397 point 32) - [ ] Is there any documentation, are there test, etc, from the current/old PLC code generator that have not yet been migrated. (#397 point 32) - [x] Deprecate `cif2plc`. - [ ] Get rid of `cif2plc`, `cif to plc`, `cif_to_plc`, etc in PLCgen.