Installtion Labview RT on PXI Controller

We have a PXI Controller 8106 which is running on Windows OS. We want to run it on Real Time OS from NI. What steps I need to perform to install that. Currrently when I boot in LabView RT fron BIOS, it displays "Transferring Control to User Program. System Unconfigured, Rebooting ...". I am able to connect it to MAX through Host PC and able to install Veristand 2011. But it does not reflect while booting Controller.
Solved!
Go to Solution.

When converting from Windows to RT, there are some very important things you must do to manage the conversion; the big one is your hard disk.  Your hard disk must be formatted with a FAT32 partition - most likely Windows formatted it NTFS, which RT cannot read or use.  Converting your disk will be a manual step for you; if you follow these steps you can use an RT PC Desktop Utility disk to perform the swap (these instructions done with a PXI-8106):
First we have to put a FAT32 partition on it, and format.
 Acquire a USB Flash Drive 256MB or larger.  Plug it into your host machine.
 Format/Image the USB Flash Drive via MAX
Under Tools->Create Desktop PC Utility USB Drive in MAX
Plug USB Drive in 8106
Enter the BIOS of 8106 using "DEL" key
Go under "LabVIEW RT" menu and set "Boot Configuration" to `Windows/Other OS".
Press F10 to save and exit, rebooting the controller.  
Enter the BIOS of 8106 using "DEL" key (we had to set the controller to Windows/Other and reboot to allow USB to be detected/used)
In the "Boot" menu, make sure the "USB HDD" (probably also has your mfg of the USB key inserted) option is #1 in boot list (using +/- keys)
In "Advanced->Integrated Peripherals" make sure "Legacy USB Support" is [ENABLED].  
Press F10 to save and exit, rebooting controller.
The controller will boot using the USB Flash Drive.
In the USB Flash Drive Options, choose option 6 "Format Options" (depending on flash drive image, may say something else, but option # is same).
Choose to format the drive, use Option #2 in format to "Erase All Partitions on the Drive and Create a Single New Partition" - this wipes the partition information from the disk and creates a single FAT32 partition on the drive.
Format with FAT32 (DO NOT use Reliance on an 8106 - the BIOS does not understand the Reliance Filesystem).
Once complete, reboot the controller (you can use Option 9 to do this).
Now we have to get the controller to think it's a PXI controller and not an RT Desktop PC
Enter the BIOS of 8106 using "DEL" key
Go under "LabVIEW RT" menu and set "Boot Configuration" to `LabVIEW RT Safe Mode"
Press F10 to save and exit, rebooting controller.
In MAX, find the device in Remote Systems.  Right-click the device and choose "Format Disk"
Once you format the disk, the controller will then think it's a PXI controller.
(You may have to delete the controller from MAX and press F5 to redetect for the images to update)
Now let's put the controller into RT mode so we can use it.
Enter the BIOS of 8106 using "DEL" key
Go under "LabVIEW RT" menu and set "Boot Configuration" to `LabVIEW RT"
Press F10 to save and exit, rebooting controller.
There you go.  Now you're ready to deterministically rule the world.
-Danny

Similar Messages

  • Remote startup and shutdown of of PXIe controller running Labview RT (WoL)

    I would like to be able to remotely start up and shut down a PXIe-8133/PXIe-8130 controller remotely over the LAN.  
    I can see that the hardware specs for the PXIe-8133 supports wake on lan (WoL), but I'm not sure about the 8130 (although it seems to respond to the network when asleep).
    I have seen the guide for configuring WoL under Windows, but I do not have Windows installed on these controllers, so how is WoL configured if I only have Labview RT 2011?
    And the 2nd part of my question is whether Labview RT supports a way to programatically shut down the controller?  I'd like the controller to shut down when the startup application terminates.  I've found the RT Restart Target VI, but not one for shutting down.

    Hey there.
    Power management on a PXI controller isn't well supported (or supported at all, really).  WoL is only supported via Windows, LabVIEW Real-Time does not support the WoL feature.  Shutting the controller down is only supported in LabVIEW 2012 and newer via the power button on an express chassis; LabVIEW Real-Time cannot programmatically kill the power on the controller, but it can put itself into a safe state (i.e. shut down) when the power button tells it that, "it has 13 seconds to shut down or else."  
    Power Management is on our roadmap, and is being considered for future versions of LabVIEW Real-Time.
    -Danny

  • PXI Controller / LabVIEW Compatibility

    I have a system using a PXI-8175 RT controller with LabVIEW 7.1.  I am looking to upgrade the LabVIEW version to LabVIEW 2011.  Is there a table of PXI-Controller compatibility with LabVIEW?

    Hi Jeffmg,
    We do have tables of compatibility for PXI controllers with different versions of the PXI Platform Services and operating systems.  Please take a look at the documentation located on the following web links and let me know if you have any questions!
    PXI Platform Services Operating System Support
    PXI Platform Services Hardware Support
    | Zach J. | Applications Engineer | National Instruments |

  • How do I restrict access to the RT Series PXI Controller via its FTP server?

    The RT Series PXI Controllers run an FTP server, so I can view files on the controller over the Internet wtih a Web browser. I can also download and upload files with a Web browser. How can I instruct the FTP server to give access only to specified, trustworthy FTP clients?

    It is possible to "Lock" the controller from the Measurement and Automation Explorer program. The password you set when locking the controller (which prevents others from making configuration changes to the controller while running) is the same password that controls access to the FTP server. When the controller is unlocked, anyone who can access the PXI controller's IP can read, write, and delete files on the FTP server. When locked, anyone can read data from the FTP server, but only when logged in with the lock password will you have access to write or delete data.
    For more information on locking your controller, see the user manual, MAX online help, or the following link.
    NI Developer Zone: Controlling Access to LabVIEW Real-Time PXI Targets

  • How can I boot my PXI controller into real-time without a floppy disk?

    My PXI controller is in a lab which has intense magnetic fields that could corrupt the floppy disk used to boot the PXI controller into the LabVIEW Real-Time (RT) Operating System. How can I boot the PXI controller into real-time directly from the hard drive?

    If you are using LabVIEW 5.1.2 Real-Time (RT), launch Remote System Explorer and select Disks >> Create Format Hard Drive Disk. If you have LabVIEW 6 RT, launch the Measurement and Automation Explorer (MAX) and select Tools >> RT PXI Disk Utilities >> Create Format Hard Drive Disk (LabVIEW RT 6 has not be released yet). Once you have created the disk, boot the PXI controller with the Format Hard Drive Disk, and this will format the PXI's hard drive and install the real-time OS boot loader. Now you can reboot the PXI without a floppy disk and configure the PXI using Remote System Explorer or MAX. Be aware that this will remove all information from the hard drive, including other operating systems.

  • Can I install Windows onto a PXI controller originally configured with Pharlap?

    We recently upgraded several PXI systems, replacing PXI-8196 controllers with PXI-8106 controllers. The old PXI-8196 controllers were running RTOS, but we would like to install Windows XP on them for use as ancillary DAQ systems.
    Is there any reason why this would not be possible? Are there any hardware/BIOS differences between stricly-RT PXI systems and Windows/Dual-Boot PXI systems? I imagine we'd be replacing the hard drives (the stock 20GB's probably wouldn't cut it for a windows machine), so we could make sure that they're formatted as NTFS instead of FAT32. But once we have the new drives, we should be able to install Windows XP without any problems, right?

    Hi Phil,
    The only catch is that our RT controllers do not come with a license for Windows, you would need to get your own, other than that, the hardware is perfectly capable of running windows. Keep in mind that dual boot is also an option:
    Dual-Booting Windows XP and LabVIEW RT on a PXI Controller
    Thanks
    Scott M.
    Applications Engineer
    National Instruments

  • Mounting /dev/hda1 on home/ftp/c failed on NI-8196 PXI controller.

    Hi folks,
    I am having some problems in recognising a PXI controller ( NI-8196
    )  and a field point unit on my host MAX. I know both of them are
    on the same subnet. I have Labview RT running on the PXI controller. I
    don't know which version though.
    The problem is while setting up the IP configuration for the PXI
    controller in the MAX. It doesnt take the IP from either the DHCP
    server or when I use static IP's. I have already checked the Switch
    settings on the controller. All of them are OFF. The BIOS option for
    the IP reset has been disabled too, still the controller boots up with
    0.0.0.0 
    While booting up it gives me the error:  "  mounting
    /dev/hda1 on home/ftp/c failed:  Invalid Arguement. Booting in
    safe mode. "
    With the field point unit, the MAX doesnt recognise it on the network. it doesn't show up under the REMOTE SYSTEMS panel.
    My MAX version is 4.0, Labview version on the host is 8.0
    Any help will be greatly appreciated.
    Thank you,
    Sandeep

    For the PXI chassis, I would start by trying a reformat. RT Disk Utilities in MAX>> Create format and boot disks.
    For the fieldpoint Try using this document. http://zone.ni.com/devzone/conceptd.nsf/webmain/49e7983a1c47a3af86256a3a005b4a3e?OpenDocument

  • What is the best practice for PXI controller, connect to the company network and install antivirus? Special Subnet?

    I need your suggestions and common practices. 

    Hello TomMex,
    Thanks for posting. If what you are looking for are suggestions for how to use your PXI controller in regards to some of the issues you mentioned, then here are my suggestions. For networking purposes, you can consider your PXI controller the same as any other computer; you should be able to connect it to your network just fine and it will be able to see other computers and devices that are on the same subnet. Antivirus software in general should be fine for your system until you want to install new NI software, at which point you may want to disable it to avoid issues during installation. Does this answer your question? Let me know, thanks!
    Regards,
    Joe S.

  • RTSI implemention between FPGA and PXI controller

    I have a need to be able to send and receive data from a r-series modules. I note these have an RTSI bus (PXI form). I am looking to implement this bus so I can pass results to a PXI controller and send new settings (info for PWM), can someone point me at an article as I have been looking for a while now to no avail.
    Many thanks
    Please remember to accept any solutions and give kudos, Thanks
    LV 8.6.1, LV2010,LV2011SP1, FPGA, Win7

    To pass data from an FPGA depending on the data type it is common to use a FIFO as R series cards tend to gather data faster than most devices can handle so the buffer is used so data isnt lost. If you could post some example code I would be happy to point you in the right direction.
    Matthew Trott
    Applications Engineer
    National Instruments UK
    www.ni.com/ask

  • PXI controller identified as Generic Desktop PC in MAX

     Hello,
     I have formatted my 8176RT controller using an USB. The utility was created using MAX. I am able to format the controller but when the controller was up it was identified as "Generic Desktop PC" even though its an PXI controller. Why is it has been identified as PC? Can anyone comment. 
    Message Edited by AHK on 07-13-2009 01:03 AM
    Regards
    Aks
    (Appreciate answers by giving KUDOS)
    Hit the stars.............. sky is not the limit.

    Hi..
    I have attached the screen shot.Pls look at the model name. Reply ASAP 
    Regards
    Aks
    (Appreciate answers by giving KUDOS)
    Hit the stars.............. sky is not the limit.
    Attachments:
    RT Model Name.JPG ‏140 KB

  • Choosing a PXIe controller for streaming 200 MBps

    Warning:  This is a long post with several questions.  My appologies in advance.
    I am a physics professor at a small liberal-arts college, and will be replacing a very old multi-channel analyzer for doing basic gamma-ray spectroscopy.  I would like to get a complete PXI system for maximum flexability.  Hopefully this configuration could be used for a lot of other experiments such as pulsed NMR.  But the most demanding role of the equipment would be gamma-ray spectroscopy, so I'll focus on that.
    For this, I will need to be measuring either the maximum height of an electrical pulse, or (more often) the integrated voltage of the pulse.  Pulses are typically 500 ns wide (at half maximum), and between roughly 2-200 mV without a preamp and up to 10V after the preamp.  With the PXI-5122 I don't think I'll need a preamp (better timing information and simpler pedagogy).  A 100 MHz sampling rate would give me at least 50 samples over the main portion of the peak, and about 300 samples over the entire range of integration.  This should be plenty if not a bit of overkill.
    My main questions are related to finding a long-term solution, and keeping up with the high data rate.  I'm mostly convinced that I want the NI PXIe-5122 digitizer board, and the cheapest (8-slot) PXIe chassis.  But I don't know what controller to use, or software environment (LabView / LabWindows / homebrew C++).  This system will likely run about $15,000, which is more than my department's yearly budget.  I have special funds to accomplish this now, but I want to minimize any future expenses in maintenance and updates.
    The pulses to be measured arrive at random intervals, so performance will be best when I can still measure the heights or areas of pulses arriving in short succession.  Obviously if two pulses overlap, I have to get clever and probably ignore them both.  But I want to minimize dead time - the time after one pulse arrives that I become receptive to the next one.  Dead times of less than 2 or 3 microseconds would be nice.
    I can imagine two general approaches.  One is to trigger on a pulse and have about a 3 us (or longer) readout window.  There could be a little bit of pileup inspection to tell if I happen to be seeing the beginning of a second pulse after the one responsible for the trigger.  Then I probably have to wait for some kind of re-arming time of the digitizer before it's ready to trigger on another pulse.  Hopefully this time is short, 1 or 2 us.  Is it?  I don't see this in the spec sheet unless it's equivalent to minimum holdoff (2 us).  For experiments with low rates of pulses, this seems like the easiest approach.
    The other possibility is to stream data to the host computer, and somehow process the data as it rolls in.  For high rate experiments, this would be a better mode of operation if the computer can keep up.  For several minutes of continuous data collection, I cannot rely on buffering the entire sample in memory.  I could stream to a RAID, but it's too expensive and I want to get feedback in real time as pulses are collected.
    With this in mind, what would you recommend for a controller?  The three choices that seem most reasonable to me are getting an embedded controller running Windows (or Linux?), an embedded controller running Labview real-time OS, or a fast interface card like the PCIe8371 and a powerful desktop PC.  If all options are workable, which one would give me the lowest cost of upgrades over the next decade or so?  I like the idea of a real-time embedded controller because I believe any run-of-the-mill desktop PC (whatever IT gives us) could connect and run the user interface including data display and higher-level analysis.  Is that correct?  But I am unsure of the life-span of an embedded controller, and am a little wary of the increased cost and need for periodic updates.  How are real-time OS upgrades handled?  Are they necessary?  Real-time sounds nice and all that, but in reality I do not need to process the data stream in a real-time environment.  It's just the computer and the digitizer board (not a control system), and both should buffer data very nicely.  Is there a raw performance difference between the two OSes available for embedded controllers?
    As for live processing of the streaming data, is this even possible?  I'm not thinking very precisely about this (would really have to just try and find out), but it seems like it could possibly work on a a 2 GHz dual-core system.  It would have to handle 200 MBps, but the data processing is extremely simple.  For example one thread could mark the beginnings and ends of pulses, and do simple pile-up inspection.  Another thread could integrate the pulses (no curve fitting or interpolation necessary, just simple addition) and store results in a table or list.  Naievely, I'd have not quite 20 clock cycles per sample.  It would be tight.  Maybe just getting the data into the CPU cache is prohibitively slow.  I'm not really even knowledgeable enough to make a reasonable guess.  If it were possible, I would imagine that I would need to code it in LabWindows CVI and not LabView.  That's not a big problem, but does anyone else have a good read on this?  I have experience with C/C++, and some with LabView, but not LabWindows (yet).
    What are my options if this system doesn't work out?  The return policy is somewhat unfriendly, as 30 days may pass quickly as I struggle with the system while teaching full time.  I'll have some student help and eventually a few long days over the summer.  An alternative system could be built around XIA's Pixie-4 digitizer, which should mostly just work out of the box.  I prefer somewhat the NI PXI-5122 solution because it's cheaper, better performance, has much more flexability, and suffers less from vendor lock-in.  XIA's software is proprietary and very costly.  If support ends or XIA gets bought out, I could be left with yet another legacy system.  Bad.
    The Pixie-4 does the peak detection and integration in hardware (FPGAs I think) so computing requirements are minimal.  But again I prefer the flexibility of the NI digitizers.  I would, however, be very interested if data from something as fast as the 5122 could be streamed into an FPGA-based DSP module.  I haven't been able to find such a module yet.  Any suggestions?
    Otherwise, am I on the right track in general on this kind of system, or badly mistaken about some issue?  Just want some reassurance before taking the plunge.

    drnikitin,
    The reason you did not find the spec for the rearm time for
    the 5133 is because the USB-5133 is not capable of multi-record acquisition.  The rearm time is a spec for the reference
    trigger, and that trigger is used when fetching the next record.  So every time you want to do another fetch
    you will have to stop and restart your task. 
    To grab a lot of data increase your minimum record size.  Keep in mind that you have 4MB of on board
    memory per channel. 
    Since you will only be able to fetch 1 record at a time,
    there really isn’t a way to use streaming. 
    When you call fetch, it will transfer the amount of data you specify to
    PC memory through the USB port (up to 12 MB/s for USB 2.0 – Idealy).
    Topher C,
    We do have a Digitizer that has onboard signal processing
    (OSP), which would be quicker than performing post processing.  It is
    the NI 5142
    and can perform the following signal
    processing functions.  It is
    essentially a 5122 but with built in OSP. 
    It may be a little out of your price range, but it may be worth a
    look. 
    For more
    information on streaming take a look at these two links (if you havn’t
    already). 
    High-Speed
    Data Streaming: Programming and Benchmarks
    Streaming Options for PXI
    Express
    When dealing with different LabVIEW versions
    it is important to note that previous versions will be compatible with new
    versions; such as going from 8.0 to 8.5. 
    Keep in mind that if you go too far back then LabVIEW may complain, but
    you still may be able to run your VI.  If
    you have a newer version going to an older version then we do have options in
    LabVIEW to save your VI for older versions. 
    It’s usually just 1 version back, but in LabVIEW 8.5 you can save for
    LabVIEW 8.2 and 8.0.
    ESD,
    Here is the link
    I was referring to earlier about DMA transfers.  DMA is actually done every time you call a
    fetch or read function in LabVIEW or CVI (through NI-SCOPE). 
    Topher C and ESD,
    LabVIEW is a combination of a compiled
    language and an interpreted language. 
    Whenever you make a change to the block diagram LabVIEW compiles
    itself.  This way when you hit run, it is
    ready to execute.  During execution LabVIEW
    uses the run-time engine to reference shared libraries (such as dll’s).  Take a look at this DevZone article about
    how LabVIEW compiles it’s block diagram (user code). 
    I hope all of this information helps!
    Ryan N
    National Instruments
    Application Engineer
    ni.com/support

  • PXI Controller will not boot when 6071E is in chassis. (new problem).

    My PXI contoller stopped upon an acquisition error, and then would not reboot until I removed the 6071E card from the chassis. When I put the 6071E back in the chassis the controller again fails to boot.

    I agree.  It sounds initially as though it is a faulty card.  I would try the card in a different slot and if possible, try a different card.  If niether of these solves the issue, then I would call in and RMA the card.
    -Jeff P.
    National Instruments Applications Engineer
    Jeffrey P.
    LabVIEW Product Management
    National Instruments

  • How to synchronize the system time/date of a PXI controller with a GPS or time server?

    Using a PXI system with a NI-PXI 8196 controller and LabVIEW RTOS, I am  searching for a solution to set or reset the on board timeclock of the controller trough a external signal like a GPS or a time server (ntp).
    Do an easy way exist to do this?
    Any response will be greatly appreciated.
    Philippe D.

    Hello Philippe,
    combining those examples should resolve your request:
    http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=DB0882E37369122DE034080020E74861&p_...
    and
    http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=EE349DC00D8D5E08E0340003BA7CCD71&p_...
    or
    http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3E23356A4E034080020E74861&p_...
    Hope this helps,
    Regards Thomas Bl.

  • 1MHz noise from embedded pxi controller?

    I am using a NI-PXI-8187 embedded controller in a NI-PXI-1045 cardframe.  I am using NI-PXI-6115 cards for data acquisition.  At the input of the 6115 cards, i see a 1MHz spike of about 40mV.  When I remove the computer it's gone.  I also have an older 8176 controller inside a 1000B cardframe, and I see the same noise at about 100mV.  Is this a known problem, and if so is there a soution?
    Thanks,

    Hi Matt-
    When you say you traced the signals to the embedded controller, do you mean that removing the controller removed the problem or that you literally traced the 1MHz signal to some point on the controller.  When you remove the controller are you still running the DAQ card via MXI or some other remote means?  If the system is not operational I would expect to see the noise being induced if it is indeed coming from the system itself.
    When you acquire data with the DAQ card do you see similar noise?  A great example to try for LabVIEW would be "Cont Acq&Graph Voltage-Int Clk.vi" from the NI Example Finder (Help>>Find Examples) under Hardware Input and Output>>DAQmx>>Analog Measurements>>Voltage.  Please let me know if the spike shows in the data read by the DAQ card as well.
    Thanks-
    Tom W
    National Instruments

  • Can I have LV RT version 5.1.2 and version 7.1 on the same PXI controller if I just want to run one or the other at one time?

    I have LabVIEW Real-Time 5.1.2 on my PXI-8170 controller. If I install LabVIEW Real-Time 7.1 on the controller will I still be able to go back and run my 5.1.2 code? Also, what will happen to my 5.1.2 NI-DAQ software if I install the 7.1 NI-DAQ software?

    Hello,
    You can only have one version of LV RT installed on a controller at a time. If you install LV 7.1 on your controller your 5.1 code should still run because LV is backwards compatible. Your NI-DAQ software should still run because it is also backwards compatible. Once you open and save your LV 5.1 code in LV 7.1 it will be recompiled and saved for version LV 7.1. You will no longer be able to open that code in previous versions of LV. Therefore I recommend making a backup of the original 5.1 code.
    Are you going to be using different host computers? If not you should know that you can only have one version of NI-DAQ installed on your host machine. So as soon as you install NI-DAQ 7.2 on your host machine you are no longer able to use previou
    s versions of NI-DAQ.
    Regards,
    Joe D.
    National Instruments

Maybe you are looking for