PXI chassis 200m+ away; options?

Hey all. I have a couple PXI chassis located 200-300 meters away from my control center. Security issues prevent me from having anything with non-volatile memory inside the PXI chassis. We can argue about what constitutes non-volatile memory, but at the very least this eliminates "hard drives" including spinners and solid state. Unfortunately this means I can't use most/all PC-based PXI controllers.
I think I need a remote interface to get the data back to the control center. I see NI's fiber optic remote control cards such as PXIe-PCIe8375, but it looks like those are limited to about 100m on fiber. I've also seen a couple fiber optic PCIe extensions from other vendors that claim to work at 250m+. My guess is that I could use that to extend my PCIe way out to the chassis, and then use a short cable to attach to the PXI.
Ethernet might work also (I don't actually need much bandwidth), but I'm not aware of any basic Ethernet crate controllers that don't have hard disks.
Anyone have any of their own opinions about the best way to connect one or more very distant PXI chassis?

Hi votton,
I think you're on the right track. It looks like NI actually does sell a fiber optic cable that can run up to 200 m, according to the following link--http://sine.ni.com/nips/cds/view/p/lang/en/nid/10359.
This link may also be helpful in configuring the entire remote system--http://sine.ni.com/nips/cds/view/p/lang/en/nid/10359

Similar Messages

FPGA to FPGA communicaton in PXI chassis

I have two NI 5641R FPGA boards mounted in a 1062Q PXI chassis.
I would like to exchange data directly between the FPGAs. Is there a way to access the PXI bus from the FPGA code?
One solution could be sending data to the RT controller and then forwarding it to the other FPGA.
Nevetheless, I would like to find a way to communicate directly between the 5641R boards.

I believe going through RT controller would be your only option since these cards do not offer high-speed DMA transfers like what some of the RF signal generators provide.
If you are still very much interested and if you have any spare digital IO on both of your boards, you could implement a communication along with some needed hardware connections between the boards. But that's not a quick task...
-DP
BatchTest Corp.
NI Alliance Partner
New Controls & Indicators made using vector graphics & animations? Click below for Pebbles UI

PXI chassis won't power up

This is a pretty silly question...
I received a new PXIe-1073 yesterday. After installing the host PCIe card, I started with a fresh installation of Windows XP, and installed Labview, the latest version of NI-DAQmx, and the PXI chassis drivers. I then connected the PXI chassis to the host, and attempted to power it on.
The fans spin up briefly, and the power LED goes green, then it shuts down and the LED just blinks red. The manual briefly mentions that this indicates the power is out of spec, but gives no details. I don't see how this would be possible. I actually checked the outlets in the room with a multimeter a few weeks ago. I've tried a number of different outlets (and circuits), including one where another PXI chassis is running happily
For whatever reason, the "official" NI power cable wasn't included on the quote sent to the distributor, so the chassis is plugged in with a regular heavy duty computer power cable. I also tried several of these. I don't see how this could be causing the problem, though.
Is there anything else that can produce this behaviour in a PXI chassis? Have I messed up somewhere, or is it a dud?

It sounds like you have already taken care of it, but if you are having more funky issues, get in touch with an engineer at NI for trouableshooting/repair options.
www.ni.com/ask
Peter Flores
Applications Engineer

HELP! I need to be able to remove power from a PXI chassis and replace a card without rebooting the whole system

I do not have particulars on the controller, but I am sure it's an NI chassis
and NI regular controller that has a serial cable leading back to the PC.
I am making this PXI rack into a debug rack for instrument cards,
so I need to be able to remove power from just the PXI chassis
and then replace the card with another one
or the same one and then turn the power back on and restart a
diagnostic test on the card WITHOUT
having to reboot the PC.
Is there a PCIe bridge setup that would allow me to do this?
Is there software that I need that can accomplish this?

Yes
The Chassi is a NI PXI 1045
and the controller is a NI-PXI-8331
Let me re-enumerate my requirements:
Background:
I have a number of NI cards as well as other manufactured cards in the system.
One of these cards in the NI system is considered to be a UUT.
That is, I am using the NI card cage system and other cards in the system to test a CARD
during a manufacturing test of said UUT CARD.
The UUT uses a PLX 9030 for it's PCI interfacing.
This UUT is not designed for hot swap, and I do not bieleve it is plug and play.
Requirement:
1. I need to be able to shut off the chassis and remove the UUT when the test finishes, replace the tested UUT
with a unknown UUT, re-apply power and then test the new UUT WITHOUT having to reboot the PC.
I have tried several things, such as disabling the PCIe busses in the windows control panel, and then removing power
replacing the UUT with the next one, re-applying chassis power and then re-enabling the bus and SOMETIMES it works.
I need a very robust way to do this.
I also bought a CHROMA PXI-52906-E extender card with bus switches on it, so that I can remove power to the UUT
without shutting off the chassis. The card is supposedley designed so that when power is re-applied to the UUT, the necessary
signals to boot the PXI PCI interface is conducted, but I think something else has to be written to the card's PCI registers.
I am by no means an expert in PCI/PXI,
but I seem to have exhausted all of my reserach online in how to meet my requirements.
Perhaps there is a way for the NI8331 controller to capture PCI configuration data to the card's on system boot,
and then "replay it" to my UUT after I re-apply power to the UUT?
Or perhaps PLX makes such a tool?
Any ideas?

How do you configure multiple PXIe chassis to share Tclk synch with the 6672 timing module?

Hi,
I have two PXIe chassis, each with a number of digitizers (configured through NI-SCOPE). Each chassis has a PXIe 6672 timing module. I have downloaded the sample VI from:
http://zone.ni.com/devzone/cda/epd/p/id/5254
which deals with PXI chassis. My question is this: in the VIs at the above link (and in fact all VIs I've seen for using the 6672 for sharing triggers), the VI needs access to the resource identifiers for both Master and Slave timing modules, how do I access the (remote) slave resource identifier from the master chassis? I feel like I'm missing something obvious, but can I do this using just an ethernet connection, or do I need another module to enable the master chassis to view the devices on the slave chassis in MAX?
Thanks for any help you can provide,
Cillian

Those example VIs are written to be used when a single host PC is controlling multiple chassis so there is just one computer running the program. Since both of your chassis have their own controllers it will be necessary to run a program on each (one as master, the other as slave). You can modify the code from that example to create and Master and Slave VIs. For the Master you will call the VIs as specified in case 0 of the example; for the Slave you will call the VIs as specified in the default, 1 case of the example.
You will also want to send a signal from the Master to the Slave to let the Slave know that the clock is being generated. You could use TCP/IP or a PFI line to do this. The basic order of events should be as follows:
1. VI runs on Slave to configure it to accept a clock.
2. VI runs on Master to begin outputing the clock.
3. Master sends a signal to Slave to let it know that the clock is being generated.
4. Continue with the rest of your program.
Let me know if you have any questions about this.
Barron
Applications Engineering
National Instruments

Detect and employ PCI or PXI chassis

I'm currently on a project which has historically bee based around a PCI backplane (in a desktop PC) containing a couple of PCI-6229 cards and a PCI-7833R. This forms the core of a testrig of which there are about 25 instances worldwide. In addition, we also support many rigs which are cored around a NI PXI chassis.
There is a drive to replace the PCs and we have opted for a for smaller footprint unit having fewer PCI slots. These are being equipped with an MXI extender card to a PXI backplane. This means in future, we need only keeps spares in the PXI format. Supporting two sets of backplanes containing near-identical hardware without implementing two near-identical pieces of software does present its problems: The FPGA bitmap build for the PCI version of the card will not open through the reference type for the PXI version of the card. We need to have a PCI and a PXI version of the bitmap. Irritatingly, the source code for these two is identical.
The first part of the solution is to establish which backplane we're using. This is straightforward. Supplying the VISA Find Resource function with the appropriate search string will identify if any PXI backplanes are connected. (Figure 1.)
Next, we need to maintain references to both FPGA VIs. Figure 2 illustrates how the FPGA to be used can be opened and proposes a structure in which the references to all available FPGA types (this example actually has four FPGA bitmaps which might be selected). In each of the other cases, the appropriate bitmap is selected in the Open FPGA Reference VI. Further, in each case, the reference is wired to the appropriate component from the cluster. (For calibration records, we also find it necessary to return the serial number of the card, but that portion of this code can be ignored.) Notice that the FPGA_Type component of the cluster is used to control which bitmap loads and which Ref component is used to store its Reference. This is necessary because the reference types are different for each bitmap.
Having set FPGA_Type, Figure 3 shows how to employ the selected resource. A separate Read/Write Control must be coded for each FPGA type.
Closing the resource also requires a case for each FPGA type.
I hope anyone else planning a stepped migration between backplanes can make use of this.

To program any DAQ card for use in Linux you need to use Register Level Programming. Unfortunately, Register level programming for the counter/timer products based on the NI-TIO ASIC (includes the 660x boards) is not supported.

Assembly part number for individual PXI chassis slot blockers?

I need the individual assembly part numbers (not the catalog or packeaged kit number) for the standard 3U PXI chassis slot blockers. The ones we have accumulated are stamped with the part numbers below but I need to know if this is the part number for the "assembly" with fasteners, or just aluminum plate.
1 slot   185365C-01
2 slot   185365C-02
4 slot   185365C-04
also is there a there 3 slot available (perhaps a -03)?
Thanks,
Darrow

Hi Darrow,
The part numbers listed above are indeed for the plates. Those three sizes are the only ones available through National Instruments; unfortunately there is no three-slot plate.
Best regards,
Tim

Compatability of LabView RT with Third Party( NOT N.I ) PXI chassis

I want to use NI LabView and LabView RT, some PXI chassis of N.I and
some PXI chassis of Third Party( not N.I ) for diversity, How I will Install
Pharlap ETS ( LabView RT ) on those third party PXI's.
More simply
Third party PXI chassis and controllers support LabView RT or not?
Note: Mark Andre Hary [email protected] of Sensing Systems LLC answer to this question as:
"You can't. I think NI bought Pharlap, and they do not offer board support packages (BSPs) for non-NI PXI controllers. There is no way to get LabVIEW-RT running on a controller not purchased from NI. You will have to use a standard RTOS like Linux,VxWorks, or QNX.
Regards

Hello,
You can install LabVIEW RT ETS on a third party PXI controller just as if it were a PC. Check the requirements that a PC needs to have in order to run LabVIEW RT ETS.
Check the following link:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/cb3434da94466dd286256e9e006bb775?O...
Ricardo S.
National Instruments

Use NI LabView and LabView RT with third party PXI chassis

I want to use NI LabView and LabView RT, some PXI chassis of N.I and
some PXI chassis of Third Party( not N.I ) for diversity, How I will Install
Pharlap ETS ( LabView RT ) on those third party PXI's.
More simply
Third party PXI chassis and controllers support LabView RT or not?
Note: Mark Andre Hary [email protected] of Sensing Systems LLC answer to this question as:
"You can't. I think NI bought Pharlap, and they do not offer board support packages (BSPs) for non-NI PXI controllers. There is no way to get LabVIEW-RT running on a controller not purchased from NI. You will have to use a standard RTOS like Linux,VxWorks, or QNX.
Regards

As described in the web links below, the only way to run LabVIEW Real-Time for ETS on a third-party system would be to follow the procedure for desktop PC computers. You may find that your third party PXI controller may meet the requirements listed in the below link and you will be able to run Real-Time on the controller. If you decide to do this, you will need to purchase the LabVIEW Real-Time Desktop Deployment license (also linked below). After purchasing the deployment license, you will be sent boot disks that will install the real-time OS onto your system. There is no need to purchase Pharlap ETS from Ardence directly.
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/cb3434da94466dd286256e9e006bb775?OpenDocument
http://sine.ni.com/nips/cds/view/p/lang/en/nid/13751
Instead of using LabVIEW Real-Time for ETS, you could use LabVIEW Real-Time for RTX instead. This system allows you to run Windows and the Ardence Real-Time eXtensions (RTX) real-time kernel concurrently on one machine. Currently device support for LabVIEW RT for RTX systems is limited to RIO devices. This is all described in the below link.
http://zone.ni.com/devzone/conceptd.nsf/webmain/9cc60298315a687e86256e78007b3a96
I hope this answers your question.
Regards,
Kristi H - National Instruments

Gigabit ehternet card in real time PXI chassis

I was reading document # DZ52103_US about general real-time
information. This document states that plug in ethernet, serial, and
GPIB cards are not supported for real-time I/O operations. I want to
use a plug in PXI gigabit ethernet card to transfer data from my real
time PXI chassis to a host laptop computer. Can this be done?

Currently, the only PXI ethernet controllers supported in LabVIEW Real-Time are the PXI-8211 and the PXI-8212. These are not Gigabit cards. This information is documented in the following link and will be updated as ethernet device support in LabVIEW Real-Time changes.
If you have any further questions, please post a reply.
Regards,
Kristi H
Applications Engineer
National Instruments

Access PXI chassis resources via LAN and MXI?

I have a PXI chassis that I access from an external PC via MXI. I would like to have remote access to the PXI system from another PC on the network. [How] can I do this?

This really depends on what you mean by remote access. If you want to see what's running on the external PC you can use remote desktop (a summary of setting this up is below). If you're running LabVIEW and want to see a VI you could try "remote panel connection" in the tools menu.
To use remote desktop the external PC needs to be running WinXP Pro (and the other PC needs a version of WinXP).
To enable remote desktop on the external PC, go to "system properties" (right-click on "my computer" and select "properties"), and enable it on the "remote" tab.
From the other PC, go to start->all programs->accessories->communications->remote desktop connection.

Ethercat won't boot on PXI chassis

I have a PXI chassis successfully running Industrial EtherCAT 2.0. I've retrieved the image using RTAD and imaged a new PXI chassis. Afterwards I went into MAX and verified that my primary ethernet and Master EtherCAT NICs were set correctly. Regardless, when I boot my newly imaged PXI the phase "NI-Industrial COmmunications for EtherCAT 2.0 started successfully" is never shown on the console out and my PXI returns ZERO discovered EtherCAT chasiss/channels. Why is this not booting??
Thanks,
Craig

Hi Craige,
I think this is the KB you are talking about.
Cheers,
Ryan
Applications Engineer
National Instruments

6U digitizer in 3U pxi chassis

Hi,
Is there somekind of adapter where I can use a 6U digitizer card in a 3U PXI chassis ? Or do I have to buy a 6U chassis. I currently have a 8 slot 3U chassis and hate to waste it.
Thanks
Dan

We have an adapter to fit 3U modules in a 6U chassis, but we don't have an adapter to go the other way. If it's useful for you in the future, though, we offer a combination chassis (the PXI-1056) that has both 3U and 6U slots.

Scan RIO resources in PXI chassis

Hi,
I am trying to find a way to scan all RIO resources in a PXI chassis programmatically.
In my PXI-1085 chassis, there can be FlexRIOs (7975R), but also VSTs (5644R and 5646R).
Using NI-VISA communication, I have been able to communicate with all those modules,but only if an Alias is set in NI-MAX.
I have'nt bee able to get the RIO resource name associated to the modules found using "VISA Find Resource" VI.
I also have 2 questions:
- Is there any way to communicate with my modules without setting an Alias in NI-MAX?
- How can I get the RIO resource name programmatically?
(I could set as VISA alias in NI-MAX the same name than RIO resource name but this is very restrictive when deploying the application to other configurations)
Thank you,
Adrien L.
Solved!
Go to Solution.

I'm kinda guessing here - but is it possible using the System Configuration VIs? This is the library/toolkit that allows you get various information about a system (e.g. for cRIOs - the installed software) - there's a 'Find Hardware' VI in there - I would suspect that you can point that at your PXI and it will give you some information?
Certified LabVIEW Architect, Certified TestStand Developer
NI Days (and A&DF): 2010, 2011, 2013, 2014
NI Week: 2012, 2014
Knowledgeable in all things Giant Tetris and WebSockets

Computing Requirements in Multiple PXI Chassis System

I have acquired a two PXI Chassis system, each with their own embedded controller (PXIe-8108 and PXIe-8130). I would like to control all instruments (simultaneously) in both chassis from a central location (either a laptop or one of the embedded controllers). What is the best configuration for this and will using one controller have enough power to drive two fully populated PXIe-1065 chassis?
(I am aware of the different configurations for control (MXI, etc.) and am more concerned with instrument performance, data buffers become full quickly etc., in using one PC controller)
THANKS!

Hi JMU_ISAT,
The PXIe-1065 chassis uses a four link configuration where there is an x4 link going to slots 7, one to slot 8, another to slots 9-14. There are also an x1 link converted to PXI that goes to slots 2-7 and another x1 link converted to PXI that goes to slots 11-13 and 15-18. Each x4 link gives 1 GB/s of bandwidth and each x1 link converted to PXI will provide 125 MB/s of bandwidth. These bandwidths are theoretical maximums where overhead and chip design reduces the bandwidth somewhat.
The PXI-8130 has four x4 links with the four link configuration so it will be able to get the full chassis bandwidth. The PXIe-8108 has four x1 links which will limit the bandwidth to 250 MB/s for slot 7, slot 8, and slot 9-14.
To synchronize the measurements across both chassis you will need a timing and synchronization module such as the PXIe-6672 in the timing slot of each chassis. This will allow you to route the clock of one timing module to the other and then use that clock to override the backplane reference clock of each chassis. Now each module can use the 10 MHz reference clock to synchronize to each other.
In order to control both chassis from one controller, you can run windows on one controller and LabVIEW RealTime on the other controller allowing you to distribute code from the windows controller to the LabVIEW RealTime controller. The other method would be to run a MXI connection from one chassis to the other to daisy chain the chassis. Since the most you can get out of a single slot of the PXIe-1065 is an x4 link, this would limit the total bandwidth of the daisy chained chassis to 1 GB/s theoretical maximum.
I hope this information is helpful!
Andy K.
Applications Engineer
National Instruments

PXI chassis 200m+ away; options?

Similar Messages

Maybe you are looking for