Watch crashes when applied to CIEC_ARRAY_DYNAMIC if lower bound is not 0 because it does always assume a lower bound of 0.

Deploying the depicted FB network to a FORTE_PC instance, it can be observed that E_SR's Q output value doesn't toggle in the 4diac debugger's watch, nor does E_PERMIT indicate that a detectable number of events EI are processed for PERMIT = FALSE.

Does the FORTE event scheduler treat output events and their associated output variable values atomically for each separate event? That is, upon reception in a subsequent FB, does each of these events get processed with the variable values of each distinct event, or could two subsequent events, when received, operate on the output variables values of the later of the two events only?

Is this behavior of E_IMPULSE consistent with whatever the expectation is of an E_IMPULSE? I lack access to any documentation.

At present, I don't think E_IMPULSE provides any deterministic behavior. Different combinations of DT of E_CYCLE and DT of E_DELAY yield, modestly speaking, other interesting, but IMHO hardly useful, results. Which means, I thought that E_IMPULSE emits one or zero CNF with QO = TRUE in TM time units.

Add .cpp and .h files that are not yet in the repo, that have already been developed.
With the needed changegs to CMakeLists.txt and processinterface.cpp

The commit mentioned in the title, 8892bcf, introduced inconsistencies between header and implementation signatures for forteStopInstance, forteJoinInstance.

With #198, the resource itself is no longer returned when querying the device.

As a result, the user no longer prompted whether to replace an existing resource in 4diac IDE, which leads to the following error during deployment:

<!--  Connected to device: _04_LOCAL -->

<!-- 127.0.0.1:61499 -->
<Request ID="2" Action="CREATE">
    <FB Name="EMB_RES" Type="EMB_RES"/>
</Request>

<Response ID="2" Reason="INVALID_STATE"/>


Deploying: EMB_RES
<!-- 127.0.0.1:61499: EMB_RES -->
<Request ID="2" Action="START"/>

<Response ID="2" Reason="INVALID_STATE"/>


Deployed: EMB_RES with 1 elements
<!--  Disconnected from device: _04_LOCAL -->

Originally posted by @kumajaya in #198 (comment)

At least on Zephyr targets, the mentioned commit (3d80e37) breaks the build, caused by two quality issues:

There is no proper signature in a header file for std::string getRealtimeString(), instead just an ad-hoc in src/arch/devlog.cpp. This in turn relies on the class signature for std::string which is incorrectly assumed to be available indirectly via some other pre-existing includes.

Please fix the prototyping for getRealtimeString(), and properly include string [edit: include C++'s string instead of C's string.h].

I have a working FORTE as a Windows service based on MSDN Code Gallery Microsoft Samples https://github.com/microsoftarchive/msdn-code-gallery-microsoft/tree/master/OneCodeTeam/A%20basic%20Windows%20service%20in%20C%2B%2B%20(CppWindowsService)%202 but I am not clear about the license, stated as Microsoft Limited Public License (MS-LPL) on the README.md file https://github.com/microsoftarchive/msdn-code-gallery-microsoft/blob/master/OneCodeTeam/A%20basic%20Windows%20service%20in%20C%2B%2B%20(CppWindowsService)%202/README.md but as Microsoft Public License (MS-PL) on every files header, and found as MIT License on the root of the repository https://github.com/microsoftarchive/msdn-code-gallery-microsoft/blob/master/LICENSE

My question is how to properly integrate Microsoft sample code to FORTE source code?

When using OPC UA in FORTE a single core is using 100%.

I noticed this when using PowerLink and OPC UA. In combination PowerLink throws 0x8243 which corresponds to EPL_E_DLL_LOSS_PRES_TH as soon as a OPC UA node is part of the system. I guess it can't keep up with the cycle time which results in a restart of the PowerLink devices.

Reference to the PowerLink to the PowerLink AppCbEvents:

Investigating the PowerLink errors I noticed that the error is only thrown when an OPC UA node is part of the system. At the same time the CPU usage is stuck at a 100% when using OPC UA. Removing all PowerLink nodes in the system and recompiling with only OPC UA features also shows the same CPU usage. With only PowerLink the CPU usage was always lower than 10% and no errors are thown. Recompiling FORTE and open62541 did not change anything.

High CPU usage when ONLY using OPC UA (no PowerLink here):

Reproduction

1. Build Forte with OPC UA support following https://eclipse.dev/4diac/documentation/html/communication/opc_ua_version1.html

cmake -DCMAKE_BUILD_TYPE=Release -DFORTE_ARCHITECTURE=Posix -DFORTE_MODULE_CONVERT=ON -DFORTE_COM_ETH=ON -DFORTE_MODULE_IEC61131=ON -DFORTE_COM_OPC_UA=ON -DFORTE_COM_OPC_UA_INCLUDE_DIR=../../open62541/build -DFORTE_COM_OPC_UA_LIB_DIR=../../open62541/build/bin -DFORTE_COM_OPC_UA_LIB=libopen62541.so ..

3. Create a System using OPC UA

4. Create .fboot and start FORTE with it

admin@X1TBEES03: ~/forte/build/src$ ./forte 
INFO: T#1212520515334851: FORTE is up and running
INFO: T#1212520515468667: Using provided bootfile location set in CMake: forte.fboot
INFO: T#1212520515565327: Boot file forte.fboot opened
INFO: T#1212520515970966: Bootfile correctly loaded
INFO: T#1212520516041645: Closing bootfile
INFO: T#1212520516393086: [OPC UA LOCAL]: Starting OPC UA Server: opc.tcp://localhost:4840
[2024-06-11 14:47:04.138 (UTC+0200)] warn/server	Username/Password configured, but no encrypting SecurityPolicy. This can leak credentials on the network.
INFO: T#1212520530551869: [OPC UA LOGGER] info/network	TCP network layer listening on opc.tcp://BR-forte_4840:4840/

5. Observer high CPU usage

Running with Linux on an Intel Atom E3845 1,91 GHz Quad Core B&R PC with 8 GByte SDRAM.

Add Function Blocks for SAE J1939 or ISO 11783 Message Reception

List

			Symbol
1.	WBSD	Wheel-based Speed and Distance
2.	GBSD	Ground-based Speed and Distance

list be be written further.

In Detail:

WBSD

ISO 11783-7
PGN 65096

Specification is also mirrored in SAE J1939

solved with PR #189

Wheel-based Speed and Distance WBSD

Message sent by the Tractor ECU on the implement bus on construction and agricultural implements providing to connected systems the current measured wheel-based speed. The message also includes a free-running distance counter, an indication of the direction of travel and the state of the start/stop switch or input.

When the ignition key switch is turned off, both the ECU_PWR and PWR have to be maintained to send this message for an additional 2 s. This is not required when the engine is cranking (starting).

Accuracies of both wheel-based and ground-based sources can be speed-dependent and degrade at low speeds. Wheel-based information might not be updated at the 100 ms rate at low speeds.

https://www.isobus.net/isobus/pGNAndSPN/14648?type=PGN

SPN	SP Name	SP Position In PG	SP Length	Scaling	Offset	Link	Symbol
1862	Wheel-based machine speed	1-2	16 bits	0.001 m/s per bit	0	link
1863	Wheel-based machine distance	3-6	32 bits	0.001 m/bit	0	link
1866	Maximum Time of Tractor Power	7	8 bits	1 min/bit	0	link
1864	Wheel-based machine direction	8.1	2 bits	4 states/2 bit	0	link
1865	Key switch state	8.3	2 bits	4 states/2 bit	0	link
5203	Implement Start/Stop operations	8.5	2 bits	4 states/2 bit	0	link
5244	Operator direction reversed	8.7	2 bits	4 states/2 bit	0	link

GBSD

GBSD ist currently WIP

After seeing #54 I have tried to get a fully static-linked FORTE on Windows.

I have successfully built PAHO-MQTT with PAHO_BUILD_SHARED=OFF and PAHO_BUILD_STATIC=ON and changed the FORTE configuration in CMake to use libpaho-mqtt3a-static.a

I also had to make the following changes: ernstblechaPT@75dee04 otherwise linking would fail with

C:/forte/mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld: C:/forte/paho-mqtt/build_win/src\libpaho-mqtt3a-static.a(Base64.c.obj):Base64.c:(.text+0x37): undefined reference to `__imp_CryptStringToBinaryA'
C:/forte/mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld: C:/forte/paho-mqtt/build_win/src\libpaho-mqtt3a-static.a(Base64.c.obj):Base64.c:(.text+0x76): undefined reference to `__imp_CryptBinaryToStringA'
collect2.exe: error: ld returned 1 exit status

Do you have any pointers where I went wrong?

The problem is a corrupt vector iterator in void CTimerHandler::processTimedFBList(). The problem definitly occurs if only one E_CYCLE is used. This results in the runtime assert:

The following code fixes this:

void CTimerHandler::processTimedFBList() {
  bool fired;
  do {
    fired = false;
    // We keep a list of sorted entries (oldest at the beginning) so we only have to check the first entry in the list:
    auto it = mTimedFBList.begin();
    if (it != mTimedFBList.end() && it->mTimeOut <= mForteTime) {
      STimedFBListEntry entry = *it; // buffer entry
      it = mTimedFBList.erase(it);
      triggerTimedFB(entry);  // This adds the entry again if not a one shot.
      fired = true; // Check the next entry.
    }
  } while (fired);
}

STRUCT_MUX crash when there is a Struct which has a Namespace

Other Struct Types no issue.

TC ReqCmGuru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x400556d5  PS      : 0x00060230  A0      : 0x8217f90d  A1      : 0x3fcd9d10  
0x400556d5: r_rwbt_isr in ROM

A2      : 0x00000000  A3      : 0xfffffffc  A4      : 0x000000ff  A5      : 0x0000ff00  
A6      : 0x00ff0000  A7      : 0xff000000  A8      : 0x00000000  A9      : 0x3fcda1d0  
A10     : 0x3c28644c  A11     : 0x3c27a594  A12     : 0x3c283310  A13     : 0x0000023f  
A14     : 0x3c286490  A15     : 0x0000023f  SAR     : 0x00000015  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000000  LBEG    : 0x400556d5  LEND    : 0x400556e5  LCOUNT  : 0xffffffff  
0x400556d5: r_rwbt_isr in ROM
0x400556e5: r_rwbt_isr in ROM



Backtrace: 0x400556d2:0x3fcd9d10 0x4217f90a:0x3fcd9d20 0x42174509:0x3fcda040 0x42174546:0x3fcda0d0 0x4201560e:0x3fcda110 0x420156c5:0x3fcda140 0x4209a8c5:0x3fcda190 0x4205da8d:0x3fcda1d0 0x420365e9:0x3fcda1f0 0x42034cac:0x3fcda240 0x42034e3b:0x3fcda260 0x42036251:0x3fcda280 0x42033ecd:0x3fcda2b0 0x420ad4df:0x3fcda2d0 0x420ad704:0x3fcda2f0 0x420ad801:0x3fcda310 0x42016593:0x3fcda340 0x420165a0:0x3fcda360 0x42018994:0x3fcda380 0x4038501a:0x3fcda3a0
0x400556d2: r_rwbt_isr in ROM
0x4217f90a: _svfprintf_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/svfprintf.c:1521
0x42174509: _vsnprintf_r at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/vsnprintf.c:70
0x42174546: vsnprintf at /builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/newlib/newlib/libc/stdio/vsnprintf.c:40 (discriminator 1)
0x4201560e: forte_vsnprintf(char*, unsigned int, char const*, __va_list_tag) at ??:?
0x420156c5: logMessage(E_MsgLevel, char const*, ...) at ??:?
0x4209a8c5: GEN_STRUCT_MUX::createInterfaceSpec(char const*, SFBInterfaceSpec&) at ??:?
0x4205da8d: CGenFunctionBlock<CFunctionBlock>::configureFB(char const*) at ??:?
0x420365e9: CTypeLib::createFB(unsigned int, unsigned int, forte::core::CFBContainer&) at ??:?
0x42034cac: forte::core::CFBContainer::createFB(unsigned int, unsigned int) at ??:?
0x42034e3b: forte::core::CFBContainer::createFB(forte::core::util::CFixedCapazityVector<unsigned int, 30u, forte::core::util::CArray<unsigned int, 30u> >::CIterator&, unsigned int) at ??:?
0x42036251: CResource::executeMGMCommand(forte::core::SManagementCMD&) at ??:?
0x42033ecd: CDevice::executeMGMCommand(forte::core::SManagementCMD&) at ??:?
0x420ad4df: DEV_MGR::parseAndExecuteMGMCommand(char const*, char*) at ??:?
0x420ad704: DEV_MGR::executeRQST() at ??:?
0x420ad801: DEV_MGR::executeEvent(unsigned int, CEventChainExecutionThread*) at ??:?
0x42016593: CEventChainExecutionThread::mainRun() at ??:?
0x420165a0: CEventChainExecutionThread::run() at ??:?
0x42018994: CFreeRTOSThread::threadFunction(void*) at ??:?
0x4038501a: vPortTaskWrapper at /home/franz/esp-idf-v5.2/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:134





ELF file SHA256: 561adc7af312d94d

Rebooting...

Some headers have the wrong Years

Without a modified source code, UaExpert from Unified Automation display:

diff --git a/src/com/opc_ua/opcua_local_handler.cpp b/src/com/opc_ua/opcua_local_handler.cpp
index d08b9d1..ee8f462 100644
--- a/src/com/opc_ua/opcua_local_handler.cpp
+++ b/src/com/opc_ua/opcua_local_handler.cpp
@@ -165,6 +165,7 @@ void COPC_UA_Local_Handler::configureUAServer(UA_ServerStrings &paServerStrings,
   // hostname will be added by mdns library
   UA_String_clear(&paUaServerConfig.mdnsConfig.mdnsServerName);
   paUaServerConfig.mdnsConfig.mdnsServerName = UA_String_fromChars(paServerStrings.mMdnsServerName.c_str());
+  paUaServerConfig.mdnsEnabled = true;
 #endif //FORTE_COM_OPC_UA_MULTICAST

   UA_String_clear(&paUaServerConfig.customHostname);

With above patch applied, FORTE instance run on port 61499 with OPC UA on port 4840 and another FORTE instance run on port 61500 with OPC UA on port 4841, UaExpert display:

With above patch applied, FORTE instance run on port 61500 with OPC UA on port 4841 but without FORTE instance on port 61499 with OPC UA on port 4840, UaExpert display:

Start official Local Discovery Server service from OPC Foundation will make FORTE to close (crash).

FORTE for win32 target build with Visual Build Tools 2022 - amd64, MSBuild version 17.9.8+b34f75857.

The GetSystemTimePreciseAsFileTime function from commit #4b5dd43290bf3ef97303c022e6acb2fb646e36d2 requires a minimum of Windows 8 which is the only function that prevents FORTE runs on Windows 7. I made a modification and replaced it with GetSystemTimeAsFileTime (configurable via CMake with WINDOWS_7_COMPAT definition) but not sure if this is the correct way to fix it regarding the expected level of precision.

The Powerlink module is not compileable in the latest development branch.

The FBs don't match the required format anymore and need to be regenerated and adapted. Furthermore, commit 3cd52d7 renamed all variables which resulted in unresolved variables in EplWrapper.cpp as the names in the structs do not match the struct definition included from openPOWERLINK.

I am currently implementing a fix and can create a merge request if wanted.

Reproduction

Download and build powerlink lib (.lib never used as we don't get to the linking stage, but here for completeness)

git clone --depth 1 --branch v1.08.5 https://github.com/OpenAutomationTechnologies/openPOWERLINK_V2 powerlink
cd ./powerlink/ && mkdir build && cd $_
cmake .. && cmake --build .
mv ./Examples/X86/Generic/powerlink_user_lib/libpowerlink.a ../libpowerlink.a # lib in root of powerlink expected
cd ../.. # Back to main folder

Download tinyxml

git clone https://git.code.sf.net/p/tinyxml/git tinyxml

Download and build forte

git clone --depth 1 --branch develop https://github.com/eclipse-4diac/4diac-forte forte
cd ./forte/ && mkdir build && cd $_
cmake -DFORTE_ARCHITECTURE=Posix -DFORTE_MODULE_POWERLINK=ON -DFORTE_MODULE_POWERLINK_LIB_DIR=../../powerlink -DFORTE_MODULE_POWERLINK_TINYXML_DIR=../../tinyxml ..
cmake --build .

Build throws errors as FBs are not compatible and later unresolved variables.