Connecting an cRIO 9004 to a LAN

[Borglin]

Hi!

I recently acquired an old cRIO-9004 which I plan to use together with a cRIO-9263 and a NI 9205 to control some lab equipment and make measurements.

However, I've had big problems just connecting to the equipment, and hasn't been able to find a solution for the problem online or in the manual.

I want to connect the cRIO-9004 to a LAN where I also have my laptop. If I could connect the laptop wia WiFi that would be great, but cable access works for me. When I connect to the router I can access internet, so the connection to the router should work, but I can't find the cRIO. Even with the IP reset switch in "on" it does not show up in MAX. I know which IP it is supposed to have and have tried to connect to that IP as well, but it doesn't work.

I would be very grateful for any help!

I use Win7 and have the following software according to MAX:

I use Labview 10 SP1

• IVI Driver Toolset 1.5
•  IVI Engine 2.0
•  IVI Engine Package 2.0 2.0
•  LabVIEW 2010 SP1
  •  FPGA
  •  MathScript RT Module
  •  PID Control Toolkit
  •  Real-Time
  •  Real-Time Execution Trace Toolkit - LabVIEW Support
  •  VI Analyzer Toolkit
  •  Vision Development Module
•  LabVIEW Run-Time 2009 SP1
•  LabVIEW Run-Time 2010 SP1
•  LabVIEW Run-Time 2011 SP1 f2
•  LabVIEW Run-Time 8.2.1
•  LabVIEW Run-Time 8.5.1
•  LabVIEW Run-Time 8.6.1
•  LabWindows/CVI 2010
•  LabWindows/CVI Run-Time 2010 SP1
•  LabWindows/CVI Shared Add-Ons
  •  Real-Time Execution Trace Toolkit - CVI Support
•  Measurement & Automation Explorer 5.3.3
•  Measurement Studio for VS2005
  •  DotNET
    •  Common
    •  Vision
•  Measurement Studio for VS2008
  •  Core
  •  DotNET
    •  Common
    •  Common (64-bit)
    •  Vision
•  Measurement Studio for VS2010
  •  Core
  •  DotNET
    •  Common
    •  Common (64-bit)
•  NI I/O Trace 3.0.2
•  NI PXI Platform Services 3.2
•  NI System Configuration 5.3.3
•  NI Vision Run-Time 2012
  •  Image Processing and Machine Vision
  •  Services
•  NI-488.2 3.1
•  NI-DAQmx ADE Support 9.6
•  NI-DAQmx Device Driver 9.6
•  NI-DAQmx MAX Configuration 9.6
•  NI-IMAQ 4.6.4
•  NI-IMAQ I/O 2.1
•  NI-IMAQdx 3.1.2
•  NI-PAL 2.9
•  NI-RIO 4.0
  •  CompactRIO
  •  CompactRIO Module Software
  •  FlexRIO
  •  R Series
•  NI-Serial 3.9
•  NI-USI 1.9.1
•  NI-VISA 5.2
  •  NiVisaServer.exe
  •  NIvisaic.exe
•  NI-VISA Runtime 5.2

[PackersFan]

Make sure you try these steps: http://www.ni.com/white-paper/6537/en

[Borglin]

I have tried most of these steps except the console out, since I don't have a null-modem cable.

I've tried pinging it before but it only times out. Now I changed the reset IP to "on" for a while and the status light began flashing indicating that it needed configurating, (Single, slow, flash) but it still won't show up in MAX.

The LAN lights are flashing as described, all other network cards have been disabled and the ethernet connection is on top of the list of networks in "advanced settings"

[PackersFan]

Have you tried connecting directly to the cRIO from your laptop just to configure it?

[Borglin]

I'm doing that right now, and there's no change.

I've set my laptops IP to 192.168.0.101, since the cRIO was supposed to have 192.168.0.102, and set matching subnet-masks, gateways and DNS-servers, but nothing.

This has worked before, so I'm very confused as to why it doesn't work anymore.

[Borglin]

This is how MAX looks when I try adding it manually.

[Texas_Diaz]

You might not want to hear this, but I've found that some new versions of MAX have a problem with detecting devices that have the 0.0.0.0 IP address.  

The cRIO-9004 does not have automatic DHCP/LLA detection mechanisms within the Safe Mode of the target.  When you flip the IP Reset switch, it forces the IP address of the target to 0.0.0.0 and the target can then only be communicated with over a same-subnet broadcast mechanism.  Some versions of MAX do not interpret the response from the target correctly, and so the target will not show up any more.  Some versions of MAX newer than 5.0 are sometimes fickle in their detection of these devices; I generally prefer to use MAX version 4.7 for these.

You really cannot download versions of MAX individually, you have to get them bundled with other software.  I would recommend grabbing the newest version of MAX and giving that a shot - you can get that from the February 2013 Driver CD bundle via the downloader posted here:  http://ftp.ni.com/pub/devzone/tut/sds-feb-13-1_downloader.exe

Also make sure your firewall is either disabled or that you have the proper exceptions enabled for Measurement and Automation Explorer - because the device discovery is over a UDP Broadcast mechanism, the Windows firewall loves to eat those packets and prevent MAX from seeing those responses.

-Danny

[AMP12]

I'm going to jump in on this since I've got the same problem, the thread is recent, and I'm using the same hardware.  I can't see my cRIO in MAX on my laptop.

I have a 9004, which I had to load RT software onto from a desktop PC (I needed to do this for another project not long ago also).  But after I got everything loaded, I was able to save the IP config as DHCP, then connect it to my laptop and it found everything fine (This was with a cRIO 9012 though).  This time when I did it with the 9004, MAX on my laptop still doesn't find it.

I've tried everything here with out luck (IP reset, crossover cables, W7 firewall, disable wireless, etc.).  My biggest tell tale is the fact that I have no blinking light to indicate network activity at my Ethernet connection on the RIO, and I can not ping the IP address from my laptop.

When I reconnect it to the desktop PC, I can access it fine.  One peculiarity is that I can not get it to save the IP config as DHCP.  On the desktop PC, it shows a DHCP IP number, but still shows the control as Static.  I've allowed access through the Windows Firewall, but am assuming our corporate IT has some addition firewall software still blocking the packets.

Does anyone have any other ideas?

Could this old RIO (many, many years old) have any networking limitations in the hardware or firmware?

[Texas_Diaz]

---

@AMP12 wrote:

I've tried everything here with out luck (IP reset, crossover cables, W7 firewall, disable wireless, etc.).  My biggest tell tale is the fact that I have no blinking light to indicate network activity at my Ethernet connection on the RIO, and I can not ping the IP address from my laptop.

When I reconnect it to the desktop PC, I can access it fine.  One peculiarity is that I can not get it to save the IP config as DHCP.  On the desktop PC, it shows a DHCP IP number, but still shows the control as Static.  I've allowed access through the Windows Firewall, but am assuming our corporate IT has some addition firewall software still blocking the packets.

---

I'll tell you straight-up that the ethernet chip on the cRIO-9004 is "Janky" - it's using an STE 10/100A ethernet part that doesn't play well with others, particularly with current-day "smart/managed" switches.  There's something in the firmware for the chip (no, the firmware on the chip cannot be updated) that is pre-standards that causes issues when talking to systems that are incredibly strict about standards-compliancy.  Slap an older hub or non-managed switch between the device and the network, and you'll finally be playing on an even playing field (the network will then actually be talking directly to the hub or non-managed switch, not directly to the cRIO, so the cRIO is insulated from the craziness of the managed/smart switch and the problems "disappear").  

When you connect the cRIO to the desktop, I assume this is when you snapped the image of the hyperterm window.  The target in the "RIO Console out.PNG" file is actually doing DHCP, and then performing a Link-Local fall-back. The "(primary - static)" output is a "bug" in the output where it says "static" instead of "auto", but it REALLY is doing "auto".  "Auto" is a combination of DHCP with a Link-Local fall-back; once the controller begins the boot process, the RT controller sends out a series of 3-4 DHCP queries; if one of them is responded to, we perform DHCP with the DHCP server that responded.  If, for some reason, nobody replies in time, we then attemp a Link-Local fall-back (and DHCP is NOT retried until the controller boots again).  Your IP Address is in the format of 169.254.x.y - this is a Link Local IP Address, so you can tell that your controller fell back into Link Local.  The bad thing about a Link-Local IP Address is that you cannot ping it from the network (unless the network is ALL link-local).  See, 169.254.x.y is a private "unaddressable" network, same as 10.x.y.z, 192.168.x.y, and others.  If you've got an IP Address that is in the class of one of these IP addresses, you cannot target addresses in the other IP address ranges.  The reason it works on your desktop is because Windows falls back to Link Local when you plug the cRIO directly to the Windows machine, and then they both have the same address range and BLAMMO it just works.  

Okay, so what can you do in order to get this guy up and running?

1. Put a hub or non-managed switch between the cRIO and the network.  This will shield you from a PLETHORA of issues regarding Spanning Tree Protocols, standards-compliancy, firmware bugs regarding DHCP, and others.  No, really, it's not funny how this one trick will solve so many problems.  Just buy a cheap $20 10/100 (non-gigabit) switch, and connect the cRIO directly to that switch, and then plug the switch into the network.  DO IT!
2. Ask IT if they are running a DHCP server that's just too stinking new.  Every time we make modifications to the DHCP processing algorithm to support odd exceptions to the DHCP protocol, someone comes out with something new that causes a fuss.  If the system they're using is more than 3 years old, or is absolutely standards compliant (with respect to DHCP) it's likely good.  The last issue we had was with a DHCP server on very specific (and not heavily used) Linux distributions that didn't null-terminate their HOST strings and it caused issues with our BOOTP/DHCP packet parsing code.
3. Make sure your network doesn't require a-priori knowledge of systems before they're plugged in.  What I mean is that some networks actually have a white-list of devices that they'll assign DHCP addresses to, or require a very specific version of the DHCP client in order to allow devices to connect.  If you then introduce a new device to the network, it will not get DHCP until you update the white list or match the DHCP client version.  You can't update the DHCP client, but you can have IT update a white list if that is what's necessary.
4. See #1.  No, really, if you haven't tried that yet why are you still reading this?

Good luck!

-Danny

[AMP12]

Voila!!!

Danny, you are a master of your craft.  The switch worked (CompUSA retail version, probably an early 1990s vintage)!

Just to clarify for future readers, My situation was not connected over a network, just my computer (PC and laptop individually) and the cRIO.  They were isolated from the corporate network.

Thanks again.   I consider my issue closed.  Don't know about Borglin's...