labview RT using desktop- failing to connect using MAX

[avnerw]

Hi,

i'm building a Labview real time system using a desktop PC. i purchased i compatible network adapter (intel Gigabit CT), prepared a utility usb drive (on MAX 5.0.0, labview 2011) and used it to format the HD to FAT. once i completed all this the PC passes the system evaluation and is declated compatible with LV RT.

however, booting into safe mode i get a strange IP address (not within my subnet) after network initialization. the message on the screen is:

Device 1 - MAC addr.: xx:xx:xx:xx:xx:xx - 169.254.102.51 /16 (primary-auto)

the x-s stand for the net adapter correct mac address. if i understand correctly, the ip should have been 0.0.0.0.

as a result, MAX in my host PC does not see the target and fails to communicate.

i should say the same net adapter (in the same pcie slot) connects to the internet well enough under windows 7.

any ideas? anything i've missed?

thanks,

avner

[Texas_Diaz]

Ever since RT 8.6.1, we have not allowed targets to get a 0.0.0.0 IP address - the only systems that will do this are systems that use a firmware in their safe modes that was developed prior to RT 8.6.1 (many VxWorks systems).  RT Desktop PCs are always on the cutting edge since they do not have programmed firmwares.

The 169.254.x.y address on the /16 network is actually a Link-Local address - this is being assigned because the device could not communicate with a DHCP server somewhere on the subnet.  This could be due to many factors, including but not limited to known issues with certain Intel gigabit chipsets using the PharLap drivers.  Clearly you're recognizing the device, but there seems to be issues with communication - the PC System Evaluation only determines if the device can be loaded, it does not test communication using the network interfaces.  

Can you provide the Device ID for the chipset being used?  The name "Intel Gigabit CT" does not unfortunately identify the specific network chipset being used, I actually need the device ID for the chipset to identify which one you're using.  You can find this out in Windows (in the Device Manager) by looking for the Product/Vendor ID - the Vendor ID will be 0x8086, and the Product or Device ID may be 0x10D3 or something similar.  Also the chip family might be helpful, such as 82574L or similar if you can find that information.

The "known issue" I mentioned is with specific classes of devices on SandyBridge and IvyBridge motherboards with >2GB RAM installed - I've only reproduced it on those motherboards, but it could affect others.  There is an updated ethernet driver for a specific class of device that may fix this problem here:

http://joule.ni.com/nidu/cds/view/p/id/2700

What you will want to do is create a new USB Utilities disk using the tool provided in that link, and install the i1000e ethernet driver update in that zip file as well.  The USB Utilities creator in that link has updated drivers for BOTH major classes of Intel Gigabit drivers, but only contains the RT installable update for one of them - if the USB Utilities thumbdrive you create correctly gets an IP address, but your installed RT does not get a correct IP address, I can ask an RT PSE to provide a link to an updated driver for the missing class of devices.

-Danny

[avnerw]

Hi Danny,

many thanks for your swift response.

the device id is indeed 0x10D3 and the chipset is 82574L. i tried the new USB Utilities disk creator + i1000e ethernet driver update but so far without any success. i'm using a DQ35JO motherboard with a Core 2 duo processor.

i'll also try: reducing the memry to 2GB, connecting p2p directly to my host.

regards,

avner

[avnerw]

Danny,

follow up: reducing the memory to 2GB solves the ethernet problem, the target gets a valid ip and i can see it from MAX at the host.

is there a solution that will enable me to go back to 4GB? i'm not sure it's critical for my application, but would prefer not to down-grade my system if possible.

now i have another problem- i've installed all relevant software, but i don't see the devices installed on my target (NI-PCIe-1429 frame grabber and NI-PCI-6221 DAQ).

both these devices wroked perfectly in labview under windows environment.

thanks again,

avner

[Texas_Diaz]

---

@avnerw wrote:

follow up: reducing the memory to 2GB solves the ethernet problem, the target gets a valid ip and i can see it from MAX at the host.

is there a solution that will enable me to go back to 4GB? i'm not sure it's critical for my application, but would prefer not to down-grade my system if possible.

---

Yes, that's the specific bug I was talking about - I assumed it could happen on the "legacy" gigabit devices, but you're the first to verify that it does.  On Monday I'll ask the RT PSE to post a link to an updated driver so you can use your system with 4GB RAM. 

---

@avnerw wrote:

now i have another problem- i've installed all relevant software, but i don't see the devices installed on my target (NI-PCIe-1429 frame grabber and NI-PCI-6221 DAQ).

both these devices wroked perfectly in labview under windows environment.

---

That should just be a matter of what's installed on the system. Your PCIe-1429 frame grabber most likely needs the RT NI-IMAQ driver, at least version 3.1 (I think 4.6.1 is the latest). When you install LabVIEW RT to the target via MAX, you need to make sure that driver is also selected and installed. Same for the PCI-6221 DAQ card, you need to make sure NI-DAQmx is installed. It's quite possible the Real-Time drivers were not installed onto your Windows PC initially, if LabVIEW Real-Time was not installed on the system when you installed the Driver DVD and IMAQ drivers. It may be necessary to reinstall those drivers on your Windows system and make sure Real-Time support is installed. Then, you can install the software onto the RT system via MAX.

-Danny

[avnerw]

yep- now all is working well, including my hardware. i'd be very grateful for that driver update.

thanks Danny for all your assistance!

avner

[Texas_Diaz]

---

@avnerw wrote:

yep- now all is working well, including my hardware. i'd be very grateful for that driver update.

thanks Danny for all your assistance!

avner

---

Hah, looks like the update was already posted, I just completely missed it every time I looked.  

In the Desktop RT PC white paper, at the bottom of the page, under the blue "Downloads" heading, look for the downloadable file "usb_utilities_and_drivers.zip" (or, just click my link here).  This zip contains updated drivers for all of our supported Intel gigabit devices, and should completely solve your problem.  Once you've downloaded the ZIP, and extracted the entire contents into a folder on your hard disk, you'll find MSI installers for the Intel1000ei driver and Intel8254xi driver - double-click on the intel8254xi.msi and intel1000e.msi files to install (you may need Admin permissions to do this).  Once installed, go back to MAX and reinstall both Intel gigabit drivers onto your RT system - you may see an icon difference showing you have a newer version of the drivers on your PC than you do on your RT system.  Once you install the new drivers, and verify that the system still works, you can increase your memory to 4GB and verify that the system now works as advertised.  

Good Day!

-Danny

[Texas_Diaz]

One more thing - for a desktop system, I highly recommend creating a new USB Flash thumbdrive using the USBCreate utility in this ZIP file download and using that to format your computer.  The format process will image your system with a Safemode that contains updated network drivers, so that if you ever need to uninstall all software from your system and reinstall software, you aren't left in Limbo where you have to remove memory in order to get the system to function properly.  Then, reinstall all software (especially the run-mode driver updates) and you should be good-to-go.

Let me know if you have any problems with this.

-Danny

[avnerw]

hi danny,

i've downloaded and installed the ethernet drivers as you suggested (version 2.2.0.3.2 for 1000e and version 4.2.0.3.4 for 8254x), and re-formated my hard drive. then i added the two extra GB of memory (which actually might be crucial as my target keeps crashing with only 2GB).

now, the target gets a valid ip in safe mode, but for some reason after i install the software and boots from the hard-drive it fails again (i get an invalid ip address). any idea what's happening?

BTW, in safe mode MAX sees 3.2GB of memory on my target and not 4GB as is actually install. is that normal?

thanks,

avner

[Texas_Diaz]

Yes, seeing 3.2GB of memory when you've installed 4GB is normal.  The BIOS may have addressed some of the memory outside the 32-bit area that our OS can see (typical for 64-bit capable hardware), and additional memory chunks are probably reserved by various entities.  The 3.2GB is what is addressable and usable by the operating system, so that's what we report.  If you notice on Windows (often) you'll see something similar, most 32-bit systems will not be able to address/use the entire memory range, and will also reserve chunks of memory for "internal use" and may not report the entire installed memory but instead the memory that is addressable/usable by the user.

That's "interesting" that Safe Mode seems to provide you with a good IP address but the run-time using the same driver as what's compiled into the safemode (4.2.0.3.4) does not.  Are you using SMP?  Can you uninstall the SMP module (or just rename ph_exec_smp.exe on the hard drive) and tell me if that gets a good IP?  This may require some communication outside of this message board.  If your next response is what I expect, I'll send you contact information in a private message.

-Danny