Error porting code from 9626 to 9627

[Daklu]

I have a large app running successfully on the 9626 that I have am attempting to get working on a 9627.  Opening the main rt vi in the dev environment doesn't reveal any errors, but when I attempt to run it interactively I get several failure messages:

My understanding is that .out files are a VXWorks file extension, while linux uses a .so file extension.  Why is Labview trying to load a VXWorks file on a Linux system, and do you have any ideas how I can resolve this?

Thanks,

Dave

[BradM]

Daklu,

I would check with the author of the app, it seems that it's referencing (through CLFN, likely) a library (named target.out). It seems that whoever wrote that original app was plugging into VxWorks itself to gather information about the running system. Most of the functionality can likely be replaced by calls through System Exec, and can be put behind conditional execution structures to run different G code on different OS'd targets. See http://zone.ni.com/reference/en-XX/help/371361M-01/glang/conditional_disable_structure/

[Daklu]

Brad,

I have all the source code; there are no calls to native VXWorks libraries in the code.  Target.out is a file I've seen frequently in my Labview VXWorks projects.  I've always assumed it was a file Labview generated...

Any other ideas?

[ScotSalmon]

Hmm. Something is definitely odd here. It's correct that target.out is installed with LVRT for VxWorks, but Brad's suggestion is accurate: the OS-specific behaviors in any ".out" file should be accessed through VxWorks-specific code in  VI's. We would normally follow our own advice here, and the VI's that ship with LVRT should all have the conditional execution structures Brad describes already in place. If there are Linux VI's referencing target.out, either there's a bug in an NI VI (can't be ruled out yet, although I haven't heard other reports of this; please point us to the relevant VI's if so) or there is a VI in your project that is not part of LV that references target.out explicitly.

The reason I think this is particularly odd is that target.out has always been an internal component and not part of the public API to LVRT, so I wouldn't have expected code other than NI code to reference it at all, even on VxWorks. But from the symptoms so far, either that is happening, or you found one of our VI's that was not correctly ported to Linux. If you can narrow that down at all and share the affected VI, that would be very helpful.

[Daklu]

Scot,

I did create a report from the error log on the device I can send you.  (It has some proprietary information so I'd rather not post it on the message board.)  It contains hundreds of "VI_BROKEN" messages similar to those listed below.  Unfortunately it doesn't really tell me where to start...

I should also point out that this application is built and deployed as a source distribution.  We have a small rt executable boot loader that loads and runs the source distribution.  Whether or not that makes a difference here I don't know.

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

DSToExtFuncLinkRef::UnFlatten: refer is [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)], refeeIndentity is [LinkIdentity "settime.dll:settimeUTC:C" [ Main Application Instance]

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

SetVIBad on vi [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

VI_BROKEN (1): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

NotifyVIOfChangedLink

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

CheckVIRefsForMissingDependencies: vi is [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

dependency ident is [LinkIdentity "settime.dll:settimeUTC:C" [ Main Application Instance]

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

VILinkObj::SetSelfErrorsCORE - VI is actually bad on [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

vi->flags=16851460, vi->flags4=0, vi->flags6=2048

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

VILinkObj::SetSelfErrorsCORE - VI is actually bad on [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi" (0x008ec640)]

vi->flags=16851460, vi->flags4=0, vi->flags6=0

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810001" (0x008fa130)]

VILinkObj::SetSelfErrorsCORE - VI is actually bad on [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810001" (0x008fa130)]

vi->flags=74244, vi->flags4=0, vi->flags6=0

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810001" (0x008fa130)]

SetVIBad on vi [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810001" (0x008fa130)]

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810002" (0x008ef308)]

VILinkObj::SetSelfErrorsCORE - VI is actually bad on [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810002" (0x008ef308)]

vi->flags=74244, vi->flags4=0, vi->flags6=0

VI_BROKEN (0): [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810002" (0x008ef308)]

SetVIBad on vi [VI "NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi:6810002" (0x008ef308)]

VI_BROKEN (0): [VI "NI STM.lvlib:Read Message (TCP).vi" (0x0064d910)]

VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI STM.lvlib:Read Message (TCP).vi" (0x0064d910)]

this->flags=50340352, compilerError=6

VI_BROKEN (0): [VI "NI_Real-Time Libraries.lvlib:RT Get Target Information (IP).vi" (0x004bdd78)]

VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_Real-Time Libraries.lvlib:RT Get Target Information (IP).vi" (0x004bdd78)]

this->flags=50340352, compilerError=6

VI_BROKEN (0): [VI "NI Debug.lvlib:Read Nand Statistics.vi" (0x00ef94c0)]

VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI Debug.lvlib:Read Nand Statistics.vi" (0x00ef94c0)]

this->flags=33563144, compilerError=6

VI_BROKEN (0): [VI "NI_Real-Time Libraries.lvlib:FPC pad strip string to size.vi" (0x00506e88)]

VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_Real-Time Libraries.lvlib:FPC pad strip string to size.vi" (0x00506e88)]

this->flags=33563136, compilerError=6

[ScotSalmon]

Ah. You'll need to rebuild your source distribution for Linux. Copying the VxWorks source distribution will still use the VxWorks code paths, because those are fixed at compile time. You'll need to put the source distribution under a Linux target in the project, and rebuild it.

[Daklu · Accepted solution]

I had already moved the code under a linux target during the build process when those errors were generated.

However, I was able to successfully deploy the code after disabling the following vis in our code:

• NI Debug.lvlib:Read Nand Statistics.vi
• NI_Real-Time Target Support.lvlib:RT Set Date and Time.vi

The first is password protected, but it wouldn't surprise me if it had a CLFN in it.  The second one is a carryover from LV2011 and uses a CLFN to call a function in settime.dll.  (Which I don't understand, but I suppose it isn't important...)

[ScotSalmon]

Do you know where NI Debug.lvlib comes from? I don't recognize that one and can't quickly find it on my system. There may be a Linux version, I'm just not aware of it off the top of my head.

RT Set Date and Time is supposed to show up as deprecated since 2011 (greyed out icon with big red "2011" on it) and doesn't have Linux support (since Linux support came out after 2011). The supported equivalent is in the palette Real-Time>>RT Utilities>>System Configuration>>Utilities>>Set Time. Although, I should probably ask what you use case for setting the time is, because I've seen a few applications recently that were better served by a time sync protocol rather than manually calling Set Time.

It seems like the failure mode on the deprecated VI is pretty hard to track down. I think it would probably be possible to make it return an error at run time instead of load time. Any idea if that would have been better or worse for you? (Presumably it depends on whether you wire the error out from that VI to somewhere prominent or not; or, eventually, you might have noticed that the date & time was not what you expected.) Alternately, since it's been > 3 years, I believe our deprecation policy would allow it to be removed from vi.lib now, which should make it very easy to track down, but obviously at the cost of potentially unnecessary breakage of VxWorks applications where it could otherwise still function.

[Daklu]

NI Debug came from the R&D group we were working with 3-4 years ago to track down a firmware problem with the NAND flash.  They needed more information so we inserted that code in a few places.  We no longer need that functionality--I've removed it from our code base.

I saw on another thread where you suggested using a time sync protocol over setting the time directly.  I'm not familiar enough with the time sync protocols to understand whether or not we can use them and how much effort it would be to implement them in our overall system (which extends well beyond the sbRIOs.)  Our use case is that we have devices deployed all over the world and they need to remain time synced with our central server.  Currently we receive a time stamp from the server and change the time when the error is larger than some small number of seconds.

[ScotSalmon]

That does sound like a use case for a standard time sync protocol. Depending what your overall system consists of, using one like NTP/SNTP might even integrate with time sync protocols already in use in your system for other devices. These protocols and others like them implement what you're describing in a standard way. They also have the advantage of integrating with OS services that allow the clock to be "steered" towards the correct time in the long run, by frequency adjustment, rather than jumping backwards or forwards in time slightly whenever a discrepancy is detected, which is what can happen when using Set Time directly from a VI (since we only allow you to set the current time, not the  frequency). You can implement something like it yourself, for example by using http://man7.org/linux/man-pages/man3/adjtime.3.html or http://man7.org/linux/man-pages/man2/adjtimex.2.html from a CLFN in your VI, but most likely using something like NTP is easier and better. These are in the Linux package feed and you can try "opkg install ntpdate" to play around with it. I'm not an expert in configuring these protocols but there is a good amount of information available online. One thing I do know is that in our 2015 and earlier feeds, the time server configuration is a placeholder, but we recently paid for a server in the NTP pool if you would like to use ours, i.e. 0.natinst.pool.ntp.org.