PLCgen: structure event functions in a hierarchy in TIA Portal

If we generate a function per event, to ensure the MAIN program doesn't get too big for the PLC, then we may end up with many event functions. People may lose the overview.

From #1031 (comment 2838631) and the further discussion there related to this topic:

We just had the maintenance mechanic of Sluis Linne here with us looking at our code. Seeing al the FC's he noted "its a bit of a mess". He suggested using FBs to instantiate FCs, this would reduce the amount of blocks used and it gives a more clear structured hierarchy of the system.

In the future, you could write the PLC-code in the same structure as our models. [...]

If I understand correctly, FB is a function block and FC a function. We could maybe add more structure based on where events are declared. But, as @ahofkamp indicates, multiple automata may participate. We don't generate code per automaton, as automata synchronize. Thus, I'm not sure whether event-declaration-based structure would help much. Also, it would not reduce the number of FCs. Maybe if we can still link to component definitions, as @ahofkamp also indicated, then we could in the PLC also make definitions (FBs) and instantiate them multiple times, with different arguments. That all adds significant complexity to the code generator, so that is not achievable on the short term.

Was it just the number of FCs that is the problem? What else did he have as feedback?

The number of blocks is the problem. There were no other problems in how the code is generated, only that it is not very readable for a maintenance mechanic, due to the large number of FC's. [...]

Perhaps the comment about FBs was about merging the same FCs into one, since the former acts as a definition. On first sight of the large number of FCs, it might appear like lots of duplicate code.

No easy way to find such duplicated events I guess?

In the past I once wrote an "equal expression" and also an "equal update" comparer, so I could merge the same updates into one. It detected swapped arguments (eg 1 + 2 and 2 + 1 are equal too). That would be a step.

Here however you must also need to get away from directly accessing the global variables, I am guessing.

Different events that have similar code likely use different variables. For instance, if I have a sensor automaton definition and instantiate it multiple times, the concrete automata are different, as are any variables declared in them, etc. Furthermore, there could be different requirements and other connections to the rest of the model. I wonder how many of them are really 'the same' if they would be parameterized?

Indeed, I wonder about that as well. As a first quick over-approximation, stick my equality notion in and ignore differences in referenced variables?

It's perhaps easier to estimate the number of duplicates from the CIF model with definitions.

For interested readers, my comment is just about an extremely crude way of judging if it could have an impact at all. It's not a path to obtain less code on the short term.

In principle Function Blocks are just Functions with persistent data, I don't think that is very applicable to use / it won't solve this problem.

Seeing al the FC's he noted "its a bit of a mess".

Totally true, generated code will never be as pretty as hand-written code. That does not only hold for ESCET, but also other tools like Matlab. I do agree that generating a large number of FCs clutters the overview in TIA portal, optimizing that would be nice.

Addresses #679