startup.rtexe Error on cRIO - DCAF Standard Engine Runtime class:Open.vi, FPDCO data is no initialized

[Justin_Thomas]

I have a DCAF based project on cRIO 9038. The project works without issues in the LV IDE. When I build the RTEXE, the startup.rtexe fails to run. The error log from the cRIO looks like this:

----------------------------------------------------------------------------------------------------------------------------------------

LabVIEW RT Error Report generated 8/26/2021 5:01:55 PM
Target code: cRIO-9038
Firmware version: 7.0.0f0

******************** LabVIEW Error Log ******************
####
#Date: Thu, Aug 26, 2021 05:49:30 PM
#OSName: Linux
#OSVers: 4.14.87-rt49-cg-7.0.0f0-x64-189
#OSBuild: 265815
#AppName: lvrt
#Version: 19.0
#AppKind: AppLib
#AppModDate:

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 2 processors
InitExecSystem() call to GetNumProcessors() reports: 2 processors
InitExecSystem() will use: 2 processors

<DEBUG_OUTPUT>
08/26/21 05:49:33.904 PM
DAbort 0xC8211D41: Problem loading [LinkIdentity "Standard Engine Runtime.lvclass:Open.vi" [ Main Application Instance] FPDCO data is not initialized
/builds/labview/2019/source/panel/load.cpp(6480) : DAbort 0xC8211D41: Problem loading [LinkIdentity "Standard Engine Runtime.lvclass:Open.vi" [ Main Application Instance] FPDCO data is not initialized

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

LV version is 2019, DCAF core is 1.3.0.12 and all dependencies are latest versions installed via VIPM.

I saw a similar issue reported Here 

Any ideas on how I can troubleshoot this?

[APolk@BW]

I've run into an issue similar to this lately in LabVIEW 2020; not sure if it's a LabVIEW thing or an issue with my project source (heavily OOP, similar to DCAF).  Have you tried clearing the compiled object cache in LabVIEW?  If not, try clearing the cache (Tools >> Advanced >> Clear Compiled Object Cache; make sure to clear the cache for the application builder), restart LabVIEW, and rebuild/redeploy.  

-Andrew

[JKSH]

---

APolk@BW wrote:

not sure if it's a LabVIEW thing or an issue with my project source (heavily OOP, similar to DCAF).  Have you tried clearing the compiled object cache in LabVIEW?

---

I'm the one who wrote the other post in OP's link: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/What-does-quot-FPDCO-data-is-not-initialized...

I am familiar with the "clear compile object cache" dance -- I have resorted to it many times in various projects when building LVClasses start failing mysteriously.

Usually, clearing the compiled object cache does the trick... but not in this case with the "FPDCO" error. The project was an OOP-heavy, but non-DCAF project; no amount of cache clearing or restarting would get rid of the error.

What worked in the end was a running "Repair" on my entire LabVIEW installation (along with all the libraries/toolkits). It is a crude sledgehammer approach, but I do not have the time, energy, or will to track down the root cause.

[Guillermo.O]

I have been having this issue lately. What have helped me is checking the error log from NI MAX (by right clicking the target), and usually I found in the log a vi or control that is causing the issue, so I go back to that element and apply a simple change, and I guess that forces to recompile it, since it has been fixing this issue multiple times.

I'm also working with an OOP project, and also using DVRs, not sure if that matters.

I'll try the clear cache next time I have the issue.

My guess is that the compiler for RT code is not handling properly cases where OOP is present, (doing a small investigation, the only thing I find in common is OOP).

[benjamin-hinrichs]

I just had this problem on a PharLap machine. It turned out to be a VI that claimed to be part of a lvlib, but the lvlib hadn't been saved. It didn't break the build, but on opening the files they were broken.

I tracked the offending file by going through them individually on our version control system.

Cross posting this message also to a related thread.