9068 Conditional Disable and OS/Processor

[GrahamB]

Hello,

If I want to put a conditional disable structure in LabVIEW for the OS or Processor for the 9068, what is the condition string in LabVIEW for each?

Old examples:

OS = VxWorks

Processor = PowerPC

Thanks,

Graham

[Sanjay_C.]

Hey Graham,

It should be:

OS == Linux

[GrahamB]

Thanks Sanjay,

Any idea what the Processor field would be? This is more critical for us to be safe since I assume OS == Linux could imply both x86 Linux and ARM Linux.

[Sanjay_C. · Accepted solution]

Hey Graham,

You can use "CPU == ARM"

Also, to be clear -- why the concern between x86 and ARM? Are you developing code that would execute on both a Desktop system and an RT system? The "OS == Linux" shoud suffice if you have code that is portalbe between just RT systems.

[GrahamB]

We are developing a LabVIEW library which calls a .DLL/.SO/.OUT that will run on Windows, VxWorks, Linux on x86, PowerPC, and ARM so we have to be a bit careful. The issue is because we call a C function which returns data with different endinaness depending on the architecture. The library right now doesn't run on any x86 based Linux, but I just wanted to be thourough now in case we ever do in the future.

Thanks for your help,

Graham

[s.boria]

Hi Graham,

Could you please provide some details about the way you performed loading a user lib ".so" targeting the ARM:

- Did you mean to target the zynq of the 9068 with an external so lib?

- Did you mean loading it directly from a vi on RT side?

I wanted to use a Call Library node inside a vi linked to the cRIO target but I face an issue : the required input is waiting for a dll only.

Regarding my project, I fix it in a "non 100% labview" way using a rt system call to a wrapper directly embedded in the cRIO. But I was looking for something "less dirty" regarding the standard way of working with Labview...

[BradM]

s.boria,

What you could do is create you LVRT application with Call Library Nodes that are pointed to "Foo.*" (will resolve to Foo.dll on Pharlap ETS, Foo.out on VxWorks, and will try both Foo.so and libFoo.so on Linux). For the 9068, make sure that the library is placed in /lib or /usr/lib for the CLN to be able to locate the library for loading.

Alternately, you could change the string passed into the CLN based on target defines and, in that case, provide the full, on-target path for the 9068, allowing you to place the library anywhere on the filesystem on the target.

If you have some more questions, don't hesitate to ask (or you could track me down at NIWeek if you're attending)

[s.boria]

Hi Brad,

Thanks for this magic trick I didn't know ! I tested that and it works well on a very basic dll sample I made just now, so I think I will unplug quite soon my own wrapper after more complex test (reentrant call for example). The only point which is quite strange is that I had to close then reopen project to have a load from the target (and have access to function name). Closing node GUI didn't get the data in... Could you confirm that this is a "normal behavior" linked to the CLN?

Furthermore is it possible to add this tips entry in the official doc of the released version?

Or even better to implement this "joker mode" in the node interface directly instead of just "dll" (and in the import shared wizard too)?

Regards,

Seb

[BradM]

s.boria wrote:

...

Closing node GUI didn't get the data in... Could you confirm that this is a "normal behavior" linked to the CLN?

Furthermore is it possible to add this tips entry in the official doc of the released version?

Or even better to implement this "joker mode" in the node interface directly instead of just "dll" (and in the import shared wizard too)?

Regards,

Seb

Seb,

Since the VI itself stays loaded in memory while deployed to the RT target, the old library will continue to be loaded as well. You could alternately un-deploy and re-deploy to get the same effect.

This functionality is already pretty well documented. I think that just automatically doing anything would prevent some flexibility (how many times when your computer does something automatically that you don't want it to? and how frustrating is it when you can't do anything to prevent it from doing that automatic action?)

[s.boria]

My apologies, I didn't see the link at the end of F1 hel "call code written in text-based programming languages." ! Thanks for the link!

Regarding the automatic action, I totally agree with you. Nevertheless, a warning info to tell that a new deploy is required or an additional "refresh node content button" should perhaps provide an additional help to get a more genuine behaviour...?

Thanks anyway for this tip and the link!