How to interface LabVIEW 64bit to cRIO

[heel]

We need to interface LabVIEW2013/64bit to a cRIO chassis (cRIO-9068). LV64bit does not have a development interface for cRIO - Target can not be imported into the project. What are our alternatives to interface LV64bit and cRIO?

1) TCP/UDP,
2) Streams,
3) Shared variable,
4)..

TCP/IP will definitely work, but are there methods operating at a higher level?

The application is data acquisition and control at slow rate (few S/s). LV64bit is needed because LV32bit is not compatible with other essential equipment in our setup:  the OS is 64bit and the driver does not support mix of 64bit OS and 32bit application! LV32bit will of course be used for the cRIO development.

Advices are very welcome.

[crossrulz]

I would use the Network Streams.  They are easy to use and are basicly a queue over the network.  Sounds about perfect for what you quickly described.

[A.E.M]

Hi Heel.

It is correct, that LabVIEW 64-bit does not have support for developing FPGA targets, since the FPGA module is not supported. Refer to the following document, which specifies supported modules:

National Instruments Product Compatibility for Microsoft Windows 7

However, you can still interface to your cRIO target from LabVIEW 64-bit in the same way you do it from LabVIEW 32-bit.

Can I Access My FPGA Target From LabVIEW 2013 64-bit?

For high throughput data communication, I would also recommend Network Streams.

Lossless Communication with Network Streams: Components, Architecture, and Performance

I'm not sure I understand your reasons for using LabVIEW 64-bit. Which driver are you talking about? You can use LabVIEW 32-bit and the NI-RIO driver on a 64-bit version of Windows without any problems. When people are using LabVIEW 64-bit, it's usually due to the memory limitation in using a 32-bit application:

How Much Memory can LabVIEW 32-bit or 64-bit Use?

[heel]

Crozrulz and Alex, Thanks for your inputs.

I have looked at the network stream but for this particular application we do not need all data - only the newest data (I should have pointed that out), so this makes network streams less practical.

For this reason, a better option could be shared variables, or of course the method Alex points out: direct access from LV64 to the FPGA (LV2013-64 to FPGA). Drawback with the fpga method is the slow turn-around cycle (compilation) during development. But a quick test shows that it works nicely.

Experimenting with shared variables I found that it is a bit tricky to architect. Below is the solutions I came up with:

The upper part of the diagram is with LV64bit-cRIO the lower is LV32bit-cRIO shared variable access.

A shared variable on both the Host64-bit and on cRIO is required. The two shared variables on PC and cRIO have to be bound together.

Note that this is not the only option in LV32bit. Here you can link to a shared variable directly from the Host_application_LV32 to the shared variable on the cRIO (blue arrow). This appears not to be possible in LV64 bit. Here the only option is as the upper part of the picture - two bound shared variable on both host and cRIO.

This asymmetry is not present when it comes to frontpanel control/indicator data-binding. Here the diagrams looks like this for the two kind of hosts:

I.e. one can bind to the shared variable on cRIO in both LV64 and LV32. 

What is the reason for this asymmetry in functionality?

The reason we need to use LV64 is that a driver from Ocean Optics (which we have to use) only supports either Win32bit+32bit applications or Win64bit+64bit applications but not the last option which we would need: Win64bit+32bit application. 

thanks

[heel]

Below I tried to illustrate precisely how the difference between LV64 and LV32 manifests itself with respect to linking to a shared variable on cRIO and host.

In LV32bit one can select a variable both on My Computer and the cRIO targets listed in the LV32 project....

In LV64 there can be no cRIO target in the project, thus it is not listed when selecting variable. So on LV64 there is no way to select the shared variable hosted on the cRIO target:

When it comes to binding of front panel items to shared variable, there is no difference between LV32 and LV64. You can browse the network for variable - not limited by what is included in the project.

So to restate my question why cant one link a shared variable by browsing on the network for all shared variables, but only browse to variables in the project?

[0utlaw · Accepted solution]

Hello heel,

This behavior is because the method of linking to the shared variable is not precisely the same.  The two cases are as follows:

A) Your "Block Diagram" shared variables.  You are using Project-style (Interactive) shared variables which are just that- variables implicitly linked to this VI via the project.  The variable host must be a valid target in the project for you to be able to use this method.  This interactive method is a bit simpler, but does have limitations (which you've run into).

B) Binding to a Front Panel terminal.  This is actually using the programmatic NI-PSP binding API behind the scenes and uses a network path to the variable library rather than a link through the project.

This is detailed a bit better in the LabVIEW help topic here:

LabVIEW Help: Using I/O Variables (Real-Time, Windows)

https://www.ni.com/docs/en-US/bundle/labview/page/using-io-variables-real-time-windows.html

Refer to the "Configuring I/O Variables" Section of the document linked above, which details the differences between the two approaches a bit better. You can certainly link to a RIO-hosted shared variable container from 64-bit LabVIEW, you'll just have to do it explicitly using the PSP API.  More detailed information on using those functions can be found here:

LabVIEW Help: Reading and Writing Shared Variables Programmatically

https://www.ni.com/docs/en-US/bundle/labview/page/reading-and-writing-shared-variables-programmatica...

Hope that helps!

Best Regards,

[heel]

Hello Tom,

Thank you for putting some logic into this. Now it makes sense to me.

regards

[jjsmith777]

I have the same issue. The reason I am using LV 64 BIT is because I am Using TestStand 64 BIT and LV 32 BIT modules will not run in the RTE adapter config.  Should I have two Projects now, one for the HOST PC in LV64 BIT and one for the cRIO in 32 BIT?

I should add that I'm currently using FPGA front panel controls and FIFOs to communicate directlybtwn Host and FPGA. I am using shared variables and network streams to communicate to LV Real Time on my cRIO 9056.

[Hooovahh]

I presented on Network Streams for our user group a few months ago.

https://www.youtube.com/watch?v=NMYbTlsNlpk

I have several demos and code examples, but most notable communication between LabVIEW bitness can be done.