PCIe 6320 et labview 7.1

Bonjour,
Voila j'ai une application a développer pour un client avec une carte PCIe 6320 la version du DaqMX fourni avec la carte est la 9.1.7. Seulement le client m'a fourni une version de labview en 7.1 D :
La version DaqMX 9.1.7 est compatible avec la carte mais pas avec Labview 7.1.
J'ai installé une version DaqMx 8.6 celle ci est compatible avec lavbiew 7.1 mais avec la carte (impossible de l'installer).
Comment faire ?
Y a t'il une version DaqMX compatible avec la carte PCIe6320 et Labview 7.1.
Cordialement
Johan CAILLET

Bonjour,
Merci d'avoir posté sur le forum NI.
Malheureusement, pour utiliser la carte PCIe 6320, une version de labVIEW 8.5 ou postérieur est nécessaire.
Veuillez trouver ci-dessous quelques liens susceptibles de vous intéresser :
NI-DAQ and LabVIEW Version Compatibility (for Windows)
NI-DAQmx and NI-DAQ Driver Support: PCI/PXI Devices
Cordialement Samuel G.
Samuel G. | Application Engineer Team Leader
Certified LabVIEW Developer
National Instruments France
#adMrkt{text-align: center;font-size:11px; font-weight: bold;} #adMrkt a {text-decoration: none;} #adMrkt a:hover{font-size: 9px;} #adMrkt a span{display: none;} #adMrkt a:hover span{display: block;}
Été de LabVIEW 2014
12 présentations en ligne, du 30 juin au 18 juillet

Similar Messages

Analog Triggering and Interrupt generation on the PCIe-6320 under Linux

We would like to use the analog triggering functions of the PCIe-6320 under Linux to time tag external events.
I have no experience with the MH DDK but have been told this is what we would need to implement the functions we want. We plan on using Fedora Linux and we are targetting kernel 2.6.31 with the PREEMPT_RT patch applied. We may consider slightly more recent kernel versions. The PREEMPT_RT patch is used to greatly improve determinism in the system and get real-time responses to some external events.
Here is what we wish to do in more details:
We wish to route at least two analog inputs to the comparator, then route the output of the comparator to a digital input which in turn would create a PCIe interrupt. The interrupt software handler would than time tag that event for our application purposes. We need the comparator threshold to be software programmable in level and slope. We are also interested in using the Watchdog Timer feature of the board.
Our application is written in C/C++.
Would the above be feasible? Please provide comments and instructions how we should address our requirement.
Thanks!

Patof wrote:
I am not familiar with the MHDDK. I would like to have an idea of the effort required to implement the functions I have described using MHDDK on Linux. Like I mentionned, we plan on using Linux kernel 2.6.31 with the PREEMPT_RT patch. Could you provide comments on that matter? I need to evaluate the amount of time I will need to spend to deploy and use MHDDK for the PCIe-6320.
There are two factors to consider when writing a driver for your specific application:
Using the deterministic kernel API calls
Writing to the device registers to
Control the watchdog timer
Configure the analog comparator
Manage the analog subsystem state as trigger events occur
Handle device interrupts
The MHDDK for X Series offers the following behavior out-of-the-tarball:
A Linux kernel module using the standanrd kernel and PCI subsystem calls
Mapping device registers to user-mode for access
Demonstrating/documenting how to
Control the watchdog timer (dioex6.cpp)
Manage the analog subsystem state as trigger events occur (aiex2.cpp, aiex4.cpp)
Handle device interrupts (reference manual only)
There are two notably missing pieces and one item to consider:
Missing: deterministic kernel API calls. If you decide to use the nirlpk module, you would need to change it from the standard interfaces to the deterministic variants.
Missing: configuring the analog comparator. You will need to implement this with additional insight from this discussion board.
Consider: if your application requires device access from kernel-mode only, you would not be able to use the MHDDK's C++ classes that perform device programming but would need to implement register programming in C.
To estimate the time for these three, here are my recommendations:
Review the nirlpk.c source file to understand how device access and DMA buffers are implemented and mapped to the user-mode application.
Beware that operation-specific programming help (as you would need for analog triggering) typically requires two weeks for a complete response.
Review the ChipObjects in the MHDDK distribution to understand how register addresses, widths, and bit fields affect device programming.
Joe Friedchicken
NI VirtualBench Application Software
Get with your fellow hardware users :: [ NI's VirtualBench User Group ]
Get with your fellow OS users :: [ NI's Linux User Group ] [ NI's OS X User Group ]
Get with your fellow developers :: [ NI's DAQmx Base User Group ] [ NI's DDK User Group ]
Senior Software Engineer :: Multifunction Instruments Applications Group
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)

Digital Signal Modification (PCIe 6320)

Hi,
We've got a digital signal which is basically a series of trigger pulses for a receiving device, constantly pulsing. However, the pulses need to be modified so that e.g. only every third pulse ends up on the receiving device, but not more than e.g. 4 pulses, with a given delay of e.g. 2 pulses.
Using this example, input and output signal should look the following:
in : 1---1---1---1---1---1---1---1---1---1---1---1---1---1---1---1
out: --------1-----------1-----------1-----------1----------------
We've got it basically working using Digital Edge Counting and connecting/disconnecting terminals as needed. However, the task is very time critical and I'm seeking for a solution that works as close to hardware as possible (ideally, the task should be carried out by the card itself after setting up the parameters).
We've got a PCIe 6320 that we want to use for this task, we are programming in C using the DAQmx C library.
Thanks for your suggestions.

Since your real code is different than what was posted, I can only take some guesses for why you can't count more than (about?) 1 million pulses.
1. If your real code doesn't wire a "# of samples" value to DAQmx Timing.vi, then a continuous task that is told it's acquiring at 100 MHz will use a default buffer size of 1 million samples. You can create a bigger buffer by wiring in a bigger value. You can also loop over your Read calls to help prevent a buffer overflow.
2. Theres a limit to the rate you can stream data from the board to system RAM. The X-series is very VERY much better than most of its predecessors in this regard for counter-based measurements. (See this thread and associated links.) But it still won't handle 100 MHz effective sampling rates for any appreciable duration.
3. Another option I've seen used is count binning. That method works kinda inside-out from your method by letting the external pulses increment the count while that count is sampled at a constant sample rate.
4. I haven't yet been able to do any real-life playing with an X-series board, but I think there's also a mode for measuring precise frequency while sampling at a constant rate. That mode might prove useful for you as well.
-Kevin P

Continuous, gap-free acquisition and processing with PCI-5142 and Labview

I am trying to continuously acquire data from a PCI-5142 in Labview 7.0. I have NI-SCOPE software installed, and right now, the best I can do is to acquire the data in chunks and then stitch the chunks together. However, this results in a short (approx. 10ms) amount of data loss between chunks. Since I am trying to do a cross-correlation of a function with my data, across chunks, I need the chunks to be contiguous. Additionally, I need to do this processing in real time so I cannot just stream to disk. What are my options?

Be sure that you are not stopping and re-starting the acquisition in between reads. Also, be sure you are not reading from a new record each time. There will be some time between separate acquisitions or separate records.
The best way to acquire continuously is to configure a single record, set the Reference Trigger to Software, and never send a Software Trigger. Set the Fetch Relative To attibute to Read Position. That way, every time you read data, it will start at the first unread data point. So you shouldn't see any gaps in the data (the chunks will be contiguous).
Please refer to two examples included in the NI-Scope driver:
- niScope EX Fetch Forever
- niScope EX Fetch In Chunks

PCIe-6320 doesn't see encoder

I am trying to set up the PCIe-6320 with two rotary encoders to measure position.
I wired up my encoder (dual quadrature with A, B, Z, V+ and Gnd wires) to my PCIe-6320 DAQ through an SCB-68 connector block. I used an external power source for the encoder so all I connected was the A, B, and Z channels. I checked my wiring. Counter 0 uses pins 37, 45, and 3.
When I connect it, there are a few issues: In Measurement and Automation Explorer (MAX), I go to the Counter testing function and it does not register. Using a multimeter, when the encoder is not connected I get some kind of output from the three channels. But once I connect it to the DAQ, I get nothing.
The self-test works in the MAX software and the calibration seems to go successfully.
What could be the problem here? Is it possible that the DAQ is broken even though it passes the self-test?
Solved!
Go to Solution.

I think I may know what is going on. The outputs are open collector, so you may need pull up resistors. See page 9 (page 7 in print) in the pdf file:
http://www.ctiautomation.net/PDF/Accu-Coder/Accu-Coder-Installation-Wiring-Guide.pdf
Since you are using an external supply, instead of tying the end of the resitor to your +VDC (6 volts in your case) you should connect it to the +5 out that is probably available on your DAQ card. This will ensure that the outputs do not exceed TTL levels (5V). You will then need to tie the common or ground of your 6V supply to the digital GND of your DAQ card.
DAQmx are the drivers and vi's for the hardware. If you have MAX, you can check for presence and version of DAQ under the software listing in MAX.
Hope this helps.
-AK2DM
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~

How to increase speed of analog read using PCI 6110 and LabView 7.1?

Hi All,
I'm a fairly novice user of LabView and I'm trying to figure out how to make my system as fast as possible. Basically, I'm reading in an analog signal (AI0) together with a trigger signal (PFI0) and I want to sample the analog signal on the falling edge of the trigger signal. What I'm finding, though, is that the acquisition rate of this system is excessively slow. My analog signals occur faster than 1 kHz, but the speed of my system is only about 100 Hz. A colleague of mine told me that the DAQmx Trigger.vi I was using was probably the culprit for the slow performance I was observing. Could this be right? If so, how could I resolve this issue?
Another thought I had was to input the trigger signal into the external source input of the DAQmx Timing.vi. In this way I'd be using the trigger signal as an external clock. If operated in Continuous mode, then I think the Sample Clock would cause a sample to be read only when the trigger signal changes its state (from high to low). Could this work?
Thanks for reading,
Ben

Hi Marni,
Thank you so much for your post! I tried doing as you suggested, using the Cont Acq&Graph Voltage-Ext Clk-Dig Start.vi and I first set the trigger signal as the external clock source. It works beautifully! Now, with 1.6 kHz signal in, I'm reading in 1.6 kSa/s. This is a dramatic improvement from before. I also tried using the internal clock source option, but it didn't seem to trigger when I wanted it to. I didn't spend too much time debugging it, though, since the other method works so well. This brings up an interesting question. Is the DAQmx Trigger.vi really that slow? Previously, I could read in 100 kSa/s at best using the Trigger VI. Anyways, I'm a happy camper now:-)
By the way, to answer your question about the DAQ device, I'm using the NI PCI 6110 Multifunction DAQ.
Thanks again!
Ben

Can I use a DAQ PCI-1200 with Labview 5.0.1?

I have a Labview 5.0.1 software, and I want to use PCI-1200 with it. Can I do that? My OS is Windows XP, but I can change it with Windows98/2000.

Hello jhylee,
The latest NI-DAQ driver for the PCI-1200 is 6.9.3, which is compatible with LabVIEW 5.0.1. LabVIEW 5.0.1 supports Windows 2000, but not Windows XP (although it may still run).
Have a nice day!
Robert M
Applications Engineer
National Instruments
Robert Mortensen
Software Engineer
National Instruments

Is Ardence RTX required when I use PCI-7831R with labview real-time module for RTX target

I am new in the labview real-time field. I want to use labview real-time module for RTX target on only one desktop. My card is PCI-78331R. Is Ardence RTX necessary? Why I cannot find my card in the MAX after I configured the RTX?
Thank you very much.

Hi Ziaozhongda,
You must have the RTX runtime engine installed before the LabVIEW Real-Time RTX module will install. Additionally, you should follow the instructions in the "Using the NI PCI-7831R with the LabVIEW Real-Time Module for RTX" section of Getting Started with the NI 7831R (page 8).
Please see Configuring Hardware for Use with RTX.
Also useful is "How Can I Validate That My PC Will Run RTX?

PCI-6220 COUNTER (Labview): Does "Sample Source" = "Gate Source"?

Hello,
I'm using Labview, DAQmx, PCI-6220 (Counter0). I connected an incremental encoder signal to the source input of CTR0. In Labview, the "DAQmx Timing" vi requires that the "source" input be wired. Does this "source" actually mean the source of the sample clock vs. the "Source" input to the counter?
Thanks for your assistance,
Chris

Chris,
When you talk about using a DAQmx Timing vi, I assume that you are performing
buffered event counting or any other task that performs buffered acquistion.
You can see an example that performs buffered event counting in NI Example
Finder called Count Digital Events Buffered - Continuous. The DAQmx
Timing vi in this example is used to read the current state of the counter
into memory at a constant rate. The source input of the Timing vi in this
case means the source of the sample clock. This clock is what determines
when the counter state is read and stored into a buffer.
If you are performing event counting, and do not need buffered acquisition (no
sample clock), you can look at example Count Digital Events.vi in Example
Finder. In this example no DAQmx timing vi is used.
Regards,
Jesse O.
Application Engineering
National Instruments
Jesse O. | National Instruments R&D

Controlling PCI-1422 with Labview instead of MAX

Hello Experts,
I want your help in one of my problem. I have a camera from Sensors Unlimited which is SU-640 1.7 RT-D and a NI parallel card PCI-1422. I can use and acquire data with MAX from the camera but I want to operate,use and acquire images from the camera using LabView. Is there any way of exporting or using the camera with Labview instead of writing a fresh code in LabView?
Does LabView offer any support or reads automatically from PCI-1422 or any possible solution that I get the block diagram code for using this camera in LabView.
Please let me know, reply.
Any help or suggestions will be highly appreciated.
Thanks in advance!

Nitai wrote:
Thanks but again it requires writing and struggling with coding and experience on LabView skills.
Just wondering something easy. I tried one of the example and it worked actually but I am trying to get more ideas or options to make it look better and impressive.
You want something and easy and doesn't require any effort on your end? Hire someone who knows how to program in LabVIEW.

Using PCI-6251 with Labview 6.1

I recently purchased a PCI-6251 multifucntion DAQ board to get a higher sampling rate than my old PCI-MIO-16E-4 board. However I have existing software that I want to run on the new board. The board came with NI-DAQmx which will only work with Labview 7 or above. I am currently running NI-DAQ 6.9.3 and the Measurement and Automation program does not recognize the new PCI-6251 board. Is there anyway to get Labview 6.1/NI-DAQ 6.9.3 to recognize and configure the new board? Or will I be forced to upgrade my Labview?

The M-series boards (PCI-62xx are M-series) require NI-DAQmx driver. The NI-DAQmx driver requires a newer Labview. No way around it.
John Weeks
WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com

RS-485: PC can send/receive data from PCI card, but LabVIEW can only send to card.

I have a master/slave setup with a 2-wire RS-485 connection via a StarTech PCI2S485 card http://www.startech.com/product/PCI2S485-2-Port-PCI-RS-422-485-Card-with-DB9. A Vista PC running LabVIEW 2010 is acting as the master to 6 slave devices. I am running a driver VI supplied by the company that made the slaves.
I've used a terminal program called Termite to monitor the ports during operation and have concluded that both the PC and the slaves are sending correct data packets (i.e. correct protocol and reasonable data). Termite indicates that the slave's response is being received by the PCI card, but the problem is that LabVIEW simply isn't reading the response from the card. Each time the driver VI is run it returns a "timeout waiting for slave to respond" error.
The VI and slaves I am using are designed for both RS-232 and 485 communication. I've verified the VI to run in 232 mode on a different COM port. I also wrote a simple VI using the VISA functions to test the ports on the PCI card, but I've had the same results. Hardware connections have been looked over carefully, but the fact that the card actually sends a correct message and receives a correct message indicates a different problem.
Any idea why LabVIEW can talk to the PCI card but can't hear it? Is there anything I can do about this, or does LabVIEW generally not like StarTech's PCI2S485 cards?
Thanks,
Tim

Tim359 ha scritto:
I have a master/slave setup with a 2-wire RS-485 connection via a StarTech PCI2S485 card http://www.startech.com/product/PCI2S485-2-Port-PCI-RS-422-485-Card-with-DB9. A Vista PC running LabVIEW 2010 is acting as the master to 6 slave devices. I am running a driver VI supplied by the company that made the slaves.
I've used a terminal program called Termite to monitor the ports during operation and have concluded that both the PC and the slaves are sending correct data packets (i.e. correct protocol and reasonable data). Termite indicates that the slave's response is being received by the PCI card, but the problem is that LabVIEW simply isn't reading the response from the card. Each time the driver VI is run it returns a "timeout waiting for slave to respond" error.
The VI and slaves I am using are designed for both RS-232 and 485 communication. I've verified the VI to run in 232 mode on a different COM port. I also wrote a simple VI using the VISA functions to test the ports on the PCI card, but I've had the same results. Hardware connections have been looked over carefully, but the fact that the card actually sends a correct message and receives a correct message indicates a different problem.
Any idea why LabVIEW can talk to the PCI card but can't hear it? Is there anything I can do about this, or does LabVIEW generally not like StarTech's PCI2S485 cards?
Thanks,
Tim
RS232 interface consist of 2 indipendent communication crossed lines between 2 devices (9DSub connector: Pin 2-RX Pin 3-TX pin 5-Gnd)
RS485 interfaceis a bus, shared between 2 or more devices. (like ethernet or CAN Bus)
This means that an incorrect use of the bus can lead to a "packet collision" if 2 or more devices try to send a message on the bus at the same time or at least their messages, partially "overlap"
About 10 years ago I have used a PCI 2 RS485 port: I remember that I have to change the status of RTS serial control line to switch between transmit and receive mode.
This can be done using the serial VISA property:
Serial Settings --> Modem Line Settings --> DTR State
or using the VI
<LabVIEW dir>\vi.lib\Instr\_sersup.llb\serial line ctrl.vi   (LV 8.6.1)
The result was that the slave device connected, send me the response after few nanosec. causing the lost of the answer.
because LabVIEW use more than some nanosec. to change RTS property after sending message on the 485 bus calling a VISA Write.
So for me there was 2 possibilities:
- use 2 RS485 port (1 for transmit 1 for receive echo transmit included)
- use this converter
         http://www.advantech.com/products/ADAM-4521/mod_2E78D425-8B08-43F6-81B0-1B924E53E075.aspx
this converter, after sending a message on the bus, electronically switchs back to receive mode without losing a byte.
But the question is :
what does it means
"RS-485 mode supports Auto Transceiver turn around (ATTA)"
of your card?
bye

PCI-6251 into LABVIEW DAQ Assist block interruptions and resets

Signals being received from PCI-6251 into a LABVIEW DAQ Assist block interrupts and resets every 10 seconds after 1 minute of data acquisition. Would this be a memory buffer problem or is it something related to the hardware? I am using a BNC-2110 hardware connector. Please view the attached image.
Attachments:
Interuption1a.GIF ‏4 KB

Hey Peter,
Ahh, I understand the graph now! Hmm, this is very strange behavior. Instead of using the DAQ Assistant, try to use the explicit DAQmx VIs (see picture). You have more explicit control over what is going on with the DAQmx VIs and keep as much as you can out of the loop.
Regards,
Erik
Attachments:
analoginput.JPG ‏23 KB

Integrating custom PCIe hardware with LabView

Hi, I am new to LabView so appologize if question is in the wrong place.
I have a custom PCIe acquisition card that I want to use in LabView environment to postprocess some data. So far the board has been used successfully with its windows drivers and VS.NET software. What is the process for setting up a device like that in LabView? Can LabView use the COM object windows driver just like a Visual Studio project would? If yes, is there a document that explains how this is done?
I have worked with NI's own instruments where the driver is provided and seamlessly integrates into the LabView, but I am a bit lost with this custom non NI board.
Thank you.

Thanks. I tried searching that site for examples... but this is a board that our company has developed (software defined radio) and I am certain no one has written any drivers for it yet. Thats the problem statement that I am trying to research. What would it take to make the board we designed compatible with LabView. Since this is a Software defined radio platform, LabView offers some useful functions that can be used to postprocess and analyze data captured by our card.
Ideal goal is to have LabView module capture data from PCIe buffer allowing for further processing (filtering, FFT, demodulation, etc...). I would appreciate if you can direct me to some examples or literature on this topic.
Thanks,
Anton

PCI 1408 mit Labview 6.i

Ich habe Probleme meine 6.i Software aufzuspielen. Im Moment läuft die Grabbercard PCI 1408 mit der Software 5.1, aber bei dem Versuch die neue Software zu installieren gab es große Probleme (Treiber ???) . Anscheinend ein Software-Hardware-Konflikt .

Im Grunde genommen sollte es mit der Karte unter LabVIEW 6 keine Probleme geben.
Bewährt hat sich folgende Installationsreihenfolge:
LabVIEW 6i
LabVIEW 6.02 (kostenloses update - unbedingt aufspielen!)
IMAQ-Vision
Treiber
Hardware
Wenn Sie das System neu einrichten möchten, empfiehlt es sich also, zunächst die Hardware auszubauen, dann alles zu deinstallieren, was sich bislang an NI Software auf dem Rechner befindet und anschliessend in der oben genannter Reihenfolge zu installieren. Verwenden Sie aktuelle Treiber (Installieren Sie LabVIEW benutzerangepasst und deaktivieren Sie zunächst die Treiberinstallation). Nach der Installation des Updates bitte wie empfohlen die Massenkompilierung durchlaufen lassen.
Das update gibt es hier: http://digital.ni.com/softlib
.nsf/954feaeea92d90918625674b00658b83/f983bda17b8f401b862569ec005a11c2?OpenDocument
NI-IMAQ Treiber finden Sie hier:
http://digital.ni.com/softlib.nsf/webcategories/85256410006C055586256BBB002C0D10?opendocument&node=132070_US
Viel Erfolg!
I. Schumacher
Application Engineering
National Instrument

PCIe 6320 et labview 7.1

Similar Messages

Maybe you are looking for