Newbie Here - cRIO Confusion

[Jfran82]

Greetings LabVIEW Community,

I'm working with the compactRIO-9067 and an assortment of NI cards plugged into the chassis. 

After reading through several NI articles, I am still just as uncertain as when I started. When an article says that the LabVIEW FPGA module is "optional" - what exactly does that mean? One article said I only need the FPGA module if I'm programming the FPGA to do some hardware-level signal processing & another said that I need the FPGA module if I want the Linux-RT chip to have access to the I/O. 

All I need is a data acquisition unit that can read 50 sensor values at 10 Hz and give them to a host computer for storage and processing in Python.

[Terry_ALE]

Scan mode, see https://www.ni.com/en-us/innovations/white-papers/08/understanding-ni-compactrio-scan-mode.html is what makes the FPGA programming part optional.

[crossrulz]

At that rate, you can probably use the Scan Engine, which means you shouldn't need the FPGA module.  I'll have to see if I can make a setup to check that out.

[Jfran82]

Thank you,

So I have to write two LabVIEW programs, one for the host and one for the compactRIO's RT module?

Is there a way to ensure that the Host's LabVIEW program begins running at boot?

I was thinking of running Linux for the Host PC, but the Real-Time module is only available for Windows. Are there any work-arounds?

[crossrulz]

You only need a Windows machine to program the RT part of the cRIO.  The cRIO actually runs NI Linux RT on it.

For a host, you just need a program that can communicate with the cRIO over the TCP connection, not necessarily written with LabVIEW.  That communication protocol can be whatever you define it.

[Jfran82]

Hey crossrulz,

Will TCP work if the cRIO is plugged directly into the host using USB - what port on the localhost would it appear as?

[crossrulz]

When directly plugged in through USB, the cRIO actually shows up as a network device.  I don't remember the exact addresses it defaults to.  But, yes, TCP will still work.  Personally, I don't do that.  I use the USB connection for configuration and debug (through the LabVIEW project and/or MAX) and the Ethernet connection for deployment (communicating with host application).

[Jfran82]

Why don't you use the USB connection? Do you just plug the cRIO directly into the host's ethernet port?

Would you happen to have any good references for TCP communication on the cRIO? I think I can get moving after I see a Hello World TCP server program for the cRIO.

[crossrulz]

1. I don't trust USB for permanent connections.  I use Ethernet to communicate with my instruments as much as possible.  So my racks have Ethernet switches that all of my instruments and computer connect to.

2. All you really need is to learn TCP communications.  In LabVIEW, you can go into the Example Finder (Help->Find Examples) and just do a simple search for TCP.  If you want a more fleshed out communication, look into the STM library (Simple TCP Messaging, available in VI Package Manager).

[Jfran82]

Ok, ethernet cable ordered. I started trying out an example to test functionality but it's not working.

Right now I'm using the USB connection, which has the default address of 172.22.11.2

I tried out the TCP examples in LabVIEW, namely:

Simple TCP - Client.vi 

Simple TCP - Server.vi

I added the cRIO to the project and moved the Server.vi under it; updating the ports and addresses in the two Vi's (client's target is 172.22.11.1:5020 ; server's host port is 5020). The Sever.vi deployed to the cRIO successfully. However, when I run the programs, first running the server, then client, I get an error message:
From the client:

LabVIEW: (Hex 0x3F) Serial port receive buffer overflow.

=========================

LabVIEW: (Hex 0x3F) The network connection was refused by the server.

After 30 seconds the Server.vi gets the timeout error, since it doesn't get the connection.

I did look at the VI Server properties of the cRIO, checked the TCP/IP box, and deployed.

I'm not sure what the problem is, other than maybe the cRIO is not on the same subnet as the host, which is on a 192.168.X.X network, but that that can't be the problem since the cRIO's subnet is just another network that the host is connected to? Is this a firewalling issue?