Add new integral function block for determining approximate integral over time.

[franz-hoepfinger-4diac]

No description provided.

[github-actions]

Test Results

   110 files  ±0     110 suites  ±0   48s ⏱️ ±0s
27 531 tests  - 2  27 531 ✅  - 2  0 💤 ±0  0 ❌ ±0 
27 532 runs   - 2  27 532 ✅  - 2  0 💤 ±0  0 ❌ ±0 

Results for commit 054e1c9. ± Comparison against base commit b2b0d82.

This pull request removes 2 tests.

org.eclipse.fordiac.ide.structuredtextfunctioneditor.tests.STFunctionValidatorPartialAccessTest ‑ testValidPartialAccessOnArraySubscript
org.eclipse.fordiac.ide.structuredtextfunctioneditor.ui.tests.STFunctionMultiQuickfixTest ‑ fixUnnecessaryConversionNested

[ernstblechaPT]

I would prefer TM to have type TIME to better indicate the meaning of this value. But I fully understand the implications this has on the integration as soon as people start to use values in nanoseconds...

[ernstblechaPT]

When testing this in the Interpreter I got the following case:

• send RESET
• set IN to 9.0E9, TM to 1 send REQ; OUT goes to 8999999.0
• set the input to 1.0, send REQ; OUT does not change
• set the input to -1.0, send REQ; OUT also does not change

this is caused by the variable resolution of the REAL datatype - a warning for the case where the integration does not work (i.e. OUT does not change with IN <> 0) could be nice-to-have

[franz-hoepfinger-4diac]

you are totally right:
our colleges at CODESYS have same issue with same Function.
this comes from the internal representation of REAL.

maybe we should also make a LREAL Version, as well a Fixed-comma Version in DINT.
i will think about it, and in the MEantime make the warning as written above.

[MartinMelikMerkumians]

Seeing the comments and the implications for the correct operation of this Function Block, I don't think this should be written as a SFB in ST at all, but as a SiFB, which can do all the relevant checking and error signalling on the system level.
TM can then be a TIME, which a check if TM's value is lower than current clock resolution, and IN and OUT could be ANY_NUMs, eliminating the need to define multiple, functional identical versions of this FB

[diplfranzhoepfinger]

@MartinMelikMerkumians i totally agree to you.
in my opinion we should make a First Version with severe Warnings about REAL.

and then step a big Moment back, go deep, take time, and make the improved Version with ANY_NUM,
wich will imply even more Documentation and more testing.

agree ?