Eclipse 4diac Wiki/Development/Breaking FORTE Changes Collection

New IO Architecture

It needs documentation

I (Jose) am having my doubts regarding using the name of the funciton block instead of PARAM as an indicator which is later used to couple with the real hardware. I will recommend to change this to have it the PARAM as default, and in case it's empty, to use the FB's name. Why? I have a couple of reasons:

• You can use the VirtuaDNS in PARAMS and not in the FB's name Edit Martin: VirtualDNS is dead and is superseded by global constants. You can still use them this way
• I had a problem when using it: I had a traffic light with 3 outputs. I first had the three outputs as OPC UA variables, to test it locally. So I created an adapter with the 3 BOOL, an INIT and REQ events and 3 PARAMS strings for the communication FBs. My FB or Subapp controlling the traffic light hat an output of this adapter. I created then a SubApp holding 3 Communications FB with this adapter as input, and worked fine. When I tried to have it as real harware output, I needed to know the names of the outputs inside this SubApp to match them later, and if I wanted to change them, I needed to change it inside this SubApp. A smoother development IMHO would have been to have these output names as a virtualDNS global constants which are set in the application and passed through the adapter.
• Comment Alois: I dissagree here. When using the full hierachical name (includeing subapps) for the fb instances, which is in work. You can easily copy subapps or use several instances of typed subapps and you always have a unique name for the IO configuration. I think as soon we have that we need a name proposal provider for the IO config searching for all I and Q blocks to be configured.

Allow using STL also in core and arch

With the improved C++ compiler support for all platforms that we currently actively use would allow us to make more use of the standard C++ libraries.

• Use std:vector in several places instead of list can reduce memory consumption and allows use of stl algorithms for searching and sorting. Potential starters are:
  • Done: CFBContainer: for fb and subapp lists, perform a sorted insert allows for quick searches
  • TNameIdentifier: makes mgm commands more flexible regarding sub-app hierarchy depth
    • Get rid of Identifier length
  • Done: TConnection: for the destination list
  • Done: CTimerHandler: the sorted insert done in the timer handler could benefit from std:vector however here clearly measurements are needed
  • CStringDict: replacing the stringID buffer with vector could greatly reduce the code here

Remove event-chain execution thread pointer from function block and add it as parameter to receiveInputEvent, sendOutputEvent, and sendAdapterEvent

requires update in code generator

Combine connection pointers

Currently we have three pointers in the fb handling the connection lists. These pointers could be reduced to one and an static offset stored in the interface struct could be used instead

The performance impact of this change needs to be evaluated before applying it globally

requires update in code generator

CDataConnection

Get rid of data buffer and turn any into value

Requires to remove if2internal data con and rework how a CFB and Resource handles connections from their interfaces to internal elements. For CFBs this can quite easily be done with the input with. For resources I currently don't have an idea how to do it.

Derive CCompositeFB from CFBContainer

This should only be done after CFBContainer utilizes std:vector for the FBlists

This can reduce some duplicated code between both

Where possible change geters from returning pointers to returning const references (e.g., getFBInterfaceSpec())

Find a way to get rid of the resource mutex

Replace Resource pointer of an FB with a pointer to a CFBContainer

This would allow FBs to retrieve their full hierarchical name

only possible when we get rid of resource mutex, otherwise it will have a severe performance impact as getResource would turn into a recursive function

requires update in code generator

Remove internal vars from base class and generate the necessary variables in the appropriate concrete FB types. Populate them via static functions. This a lot of memory can be saved.

Done

Use 64bit datatype in forte timerhandler instead of struct -> Bug 538419

As now nearly all of our systems are 32 or 64bit systems support for 64bit datatypes is available on them. This would greatly reduce the implementation effort for the timerhandler and I assume also some performance implications.

This could already be a target for 1.10

• Use std: meta programs instead of the reimplemented ones in iec_61131_cast_helper.h
  • replace custom is_same with std version
  • replace custom static_assert with std version

Change int in receiveInputEvent(int paEIID) to size_t

requires update in code generator

Changed to TEventID type which is a typedef for size_t

Adapter connection support in Composite FBs Bug 578390