Distributed Control & Automation Framework (DCAF)

cancel
Showing results for 
Search instead for 
Did you mean: 

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

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?

 

0 Kudos
Message 1 of 5
(1,962 Views)

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

0 Kudos
Message 2 of 5
(1,936 Views)

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.

Certified LabVIEW Developer
0 Kudos
Message 3 of 5
(1,912 Views)

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).

Guillermo Oviedo
R&D Software Engineer
CLA | CTD
0 Kudos
Message 4 of 5
(1,890 Views)

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.

----------
Although I've been 10+ years long fan of LabVIEW, I started to discourage engineers to start new projects in a SaaS language. NI must first regain trust within its community.
0 Kudos
Message 5 of 5
(1,094 Views)