NI PCI-8430 RS232 with DMA

One of the features of the NI’s RS-232 card is “High-speed DMA Interface minimizes CPU overhead”. When programming them with LabVIEW controllers, are there any special VIs to be used/techniques to be followed to activate/maximize the DMA capabilities of this card? Or just because it’s a card with DMA feature, I am expected to see an instant boost in performance.
Your input will be appreciated,
Thanks,
Santiago

Hey Santiago,
Sorry for the late reply, but to get back to your question, having the RS-232 board with DMA will optimize your system by itself. In LabVIEW you will have to allow access to DMA transfers, this can be done through a property node under General Settings. As for special coding methods, there really isn't anything that you need to follow to a tee, although there are certain practices that may help further optimize your code. All these can be seen in the example programs under Hardware Input and Output->Serial. I hope that this helps you out
Regards,
Can W.
PXI and VXI Platform PSE
National Instruments

Similar Messages

Are there known problems with using the PCI-8430/8 with windows 7?

Hello,
I have several PCI-8430/8 cards (8 serial port cards) that were originally purchased to be used in Windows XP computers for the purpose of calibrating proprietary serial devices (using 9600 baud.). When my company transitioned to Windows 7 PCs (Dell Optiplex), I discovered that the PCI cards now collect data from our devices at a noticeably slower rate than previously experienced, with our calibration process taking nearly twice as long as it used to. It almost seems as if the ports can no longer be accessed asychronously. I have tried using several different versions of the Ni-Serial driver to resolve the problem, all to no avail. Has anyone heard of this problem, or know of a potential solution to speed up the serial communications with this data card?

You are correct that VISA is used in LabVIEW, but it can also be used from other programming environments.
I actually thought about what may be causing the performance difference. The ports on this board have 128 byte receive buffers for each port. By default they will wait until 64 bytes arrives before sending a batch of data to the computer. If you have less than 64 bytes received by the port, it will wait for a period of 4 bytes before deciding to go ahead and send the data to the computer.
The trigger point at which they decide to send data to the host is configurable, either through the advanced properties of the port in Device Manager, or through Measurement & Automation Explorer (NI-MAX). Configuring the receive buffer trigger point to a lower number can help decrease latency from your hardware, at the expense of increasing CPU usage. The best latency (and also the highest CPU usage) will be achieved by setting this value to 1, since it will always send the data back to the computer as soon as it arrives, and never incur the 4-byte-time delay before transmitting data back to your application.
I would suggest you look at the receive buffer settings on your XP machines which run quickly. If they are not set to 64, they have been customized for your application, and you will want to ensure you configure them the same way on your Windows 7 machines.

Where to down load Software or driver for NI PCI-8430/16 (RS232)

where to down load Software or driver for NI PCI-8430/16 (RS232)

Try here:NI-Serial 4.0
I just did a search from ni.com for "ni-serial download" and that was the first link.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

PCI-MIO16XE-50 with DAQmx; Reset traditional driver

I am developing a C++ application using DAQmx on Windows XP. I have two boards for testing- a PCI-6229 and an old PCI-MIO16XE-50. Whenever I run my application, I get an error back when I attempt operations on the MIO16:
-89130 Device not available for routing.
The 6229 works fine.
The solution is to go to MAX, right-click on Traditional Devices and select Reset. An alert tells me that the driver was reset, then I can access the MIO16 from DAQmx calls.
Although I have Traditional NI-DAQ installed, I haven't been using it. Why should I need to reset it?
I am using NI-DAQ 7.1; would this be fixed by upgrading to 7.4?
John Weeks
WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com

There has been a recent (7.4 timeframe) fix for the PCI-MIO-16XE-50, but it has to do with DMA support under DAQmx, not the problem you're describing.
If you haven't been using traditional DAQ at all, I'm a bit stumped as to why you're seeing this problem. In the hopes that we can figure this out together, here's an explananation of what we did to make the Traditional DAQ & DAQmx drivers interoperable with each other:
Prior to DAQ 7.0, the behavior of nidaq32.dll was that when the DLL loaded, it would enumerate the configured devices, and initialize the driver code for each device. We changed this in DAQ 7.0 such that the device initialization wouldn't happen until the first API function was called to use the device. Also, we changed the device initialization code to call into DAQmx to disable the DAQmx driver for that device. Finally, we added code to re-enable the DAQmx driver when the Init_DA_Brds or Device Reset.vi was called (or when the "Reset Driver for Traditional DAQ" MAX menu option is invoked), or whenever the nidaq32.dll is unloaded from all processes.
So, you should only see the behavior you are seeing if the nidaq32.dll is loaded by a currently running process AND if a trad. DAQ API call has been invoked on the PCI-MIO-16XE-50 in that process. It makes sense that you're not seeing this behavior with the M-Series device, because it's not supported by traditional DAQ at all.
Can you double-check that there is not another process running on your system that has loaded nidaq32.dll? You can use the "process explorer" utility, available for free download from www.sysinternals.com, to search for processes that have nidaq32.dll loaded.
If you don't find anything, then this could be a bug. Since DAQ 7.4 fixed the DMA issue with the MIO, you'll probably want to get this version of the driver anyway, which may have resolved the issue (though I don't remember such a bug). If you can reproduce this with DAQ 7.4, we'll still have an unsolved mystery. In that case, let us know and we'll try to reproduce your problem here.
Good luck,
Joe Savage

Why does it take so long to clear a task (with DMA transfer) using the PXI bus?

I am migrating a system which used to use a PCI-6133 (8 channel simultaneous AI) and PCI-6733 (8 channel AO) to one that uses a PXI-6133 and PXI-6733 mounted in a PXI-1033 chassis.
In general, things seem to work (synchronized AI/AO running near the maximum rate on both devices), with the one exception that clearing an AO task on the PXI-6733 takes forever (on the order of 20-30 seconds).
Even when I try the sinewave generation for the PXI-6733 in the MAX test panel it takes the same amount of time to stop the task. If I switch to using interrupts as the transfer mechanism, it stops immediately.
I tried using the interrupt transfer mechanism on my more demanding set of synchronized tasks, but that does not produce the right behavior (even though it does not give any errors).
Is there any trick (or better diagnostic) to help get my tasks working with DMA under PXI that used to work fine on PCI?
Thanks in advance!
Solved!
Go to Solution.

Hi Patrick,
I'm using a PCIe-8361 controller. The computer is a Dell T5500 workstation running Windows 7 x64. I see the problem every single time I try to clear a task running on the PXI-6733, including my example using the Measurement & Automation test panel (from the very first time I try the Sinewave Generation onward). I can try other parameters in the test panel, but I don't need to adjust anything from the defaults (e.g., Rate = 1000) to get the behavior. I will also try installing the PXI chassis in a few other computers we have here just to confirm that it's not computer specific. From your line of questions I can at least gather that there's nothing obvious (like a known bug with the PXI-6733) and that I should expect this configuration to work.
Thanks for your help and I'll post any other findings I obtain.

Mac pro and motu PCIe audio card with a 2408mkIII

mac pro and motu PCIe
i recently upgraded to the mac pro from a G5 and now my motu 2408 mkIII sound card does not work.
i installed the motu PCIe 424 pci card from motu and installed the latest UB drivers, followed the instructions to the letter, repeated numerous times in every pci e slot with only temporary luck. it worked briefly and then when the computer slept i lost the connection with the interface and have not been able to regain it.. yes i re-installed to the letter again. the pcie card is seen by the computer but it cannot seen the external rack mounted 2408 via the audiowire that connects it. yes i tried other cables. the unit worked fine on my G5.
i have heard of others with the same problem after updating the firmware to SMC 1.7. my mac pro came with the latest firmware.
Message was edited by: tara ntula

another user forum wrote this on 8 august 2007 in regards to their mac pro.
To my surprise I had five software updates waiting for me. Among them Pro App update, two of them, and this SMC update. After I updated my MOTU PCI-424 audio interface no longer works. Tried installing MOTU drivers again, still nothing. It can't communicate with its audio interfaces. So right now, this amazing update from Apple stopped me from working, and I am on a pretty tight deadline. I hope I'll find a solution ASAP

PCI 4351 cjc with SCB-68

Is it possible to enable cold junction compensation using a PCI 4351 board with a SCB-68 terminal block?
I have searched around and tentatively concluded that it is not possible. Under the "accessory" option in MAX SCB-68 is not an option, and TBX-68 does not have a checkbox for temperature compensation.

Hello Craig,
National Instruments recommends the following accessories that are designed to be used with the NI 435x for thermocouples/CJC: the cold-junction sensor is on analog channel 0 on the TC-2190, TBX-68T, and CB-68T accessories. Additionally, the NI TBX-68T (used with NI 435x devices only) is the correct acccesory which includes a built-in cold-junction compensation sensor and autozeroing circuitry (compared to TBX-68).
Best regards,
Ali M
Applications Engineer
National instruments

I am using the PCI-6110E/6111E with the NI-DAQ software version6.7.Is there a way to record at the same time analog and digital channels?If,ye

s can I have timestamps for each sample?I mean,is there a notion of time information on this board?Finally,is there a way to know ,in the double buffer's case,the number of samples in the halfbuffer which is not full if the acquisition stops by a trigger?.I am using the PCI-6110E/6111E with the NI-DAQ software version6.7.Is there a way to record at the same time analog and digital channels?If,yes can I have timestamps for each sample?I mean,is there a notion of time information on this board?Finally,is there a way to know ,in the double buffer's case,the number of samples in the halfbuffer which is not full if the acquisition
stops by a trigger?.
Thank you for your interest in advance

s can I have timestamps for each sample?I mean,is there a notion of time information on this board?Finally,is there a way to know ,in the double buffer's case,the number of samples in the halfbuffer which is not full if the acquisition stops by a trigger?.PALE wrote:
>
> I am using the PCI-6110E/6111E with the NI-DAQ software version6.7.Is
> there a way to record at the same time analog and digital
> channels?If,yes can I have timestamps for each sample?I mean,is there
> a notion of time information on this board?Finally,is there a way to
> know ,in the double buffer's case,the number of samples in the
> halfbuffer which is not full if the acquisition stops by a trigger?.
Start by looking around the examples that ship with LabVIEW (if you are
using LabVIEW).
Also look around zone.ni.com for general data acquisition information &
examples. A good site.
Mark

PCI expansion slots with LV and NI hardware

I was wondering if there were any hardware or software limitations
with the use of a PCI expansion unit with NI boards and LabVIEW.

pincpanter wrote:
Hello LabVIEWers,
I tried to install the old DAQ-mX 7.5 to drive a NI 6601 PCI card under Microsoft's Virtual XP (host is Win7 Pro).
The driver installation failed somewhere (the errore message did'nt specify exactly what went wrong).
Also, the card itself was not seen by the virtualized OS.
Documentation available is somewhat limited and confusing, so I prefer to ask to actual users.
Are you running multiple LabVIEW versions on different VM's? Which ones? Do you get troubles?
Are the virtual OS really able to recognize the hardware? Is it possible to install different versions of the DAQ drivers on each?
Thank you in advance for your help
The PCI bus is not exposed to the MS XP virtual machine - You can't get there on that VM although.. while not officially supported other XP VM emulators do exist. a quick search on the forums should yeild results
Jeff

X-Fi XtremeMusic - 100Mhz or 133Mhz PCI-X support with nForce Pro chips

I have a Tyan k8we motherboard which makes use of a nForce4 chipset and I know there are issue with it and the X-Fi XtremeMusic cards.
However my question is this will the X-Fi work in 00 & 33 PCI-X slots? The reason I ask is that the Tyan k8we has two 6-bit PCI-e slots with a standard 32-bit PCI in between them, which makes it impossible to install anything in that 32-bit slot if you run in SLi mode.
I only have 00 and 33 PCI-X slots left that I can use on my motherboard. Both of which do not seem to work properly with the X-Fi XtremeMusic card (when I plug in the X-Fi, my onboard network cards stop working).
So I need to know what my options are if this X-Fi card will not work.
- Is there something I missed during the installation?
- Do I obtain a firmware or an update for the X-Fi card?
- Swap the card for one that does work?
- Return the card and get the Pro version (which I have heard works for some strange reason)?
- Or return the card and get my money back?
This card is only a day old so I would like to act on the store's return policy if CL Support cannot help me anytime soon.
Thanks very much
Message Edited by ghoulish on <SPAN class=date_text>0-26-2005 <SPAN class=time_text>0:32 AM
Message Edited by ghoulish on 0-26-2005 04:42 PM

I think vanilla PCI is 33 MHz. 66 MHz is a PCI-X rate. Anyway, step is to talk to the motherboard manufacturer and make sure you are doing everything necessary to allow a 32-bit 33MHz PCI device to work in one of the PCI-X slots. If that doesn't work, the next step to talk to Creative. I doubt anyone here has any experience with this.
Also, I KNOW that the PCI slot is stuck between the two PCIe x6 slots. All I'm saying is that something is not right (ie. Tyan screwed up) if you can't use all 3 slots at once. I don't have any experience with SLI. Is there a rigid connector between the 2 cards that doesn't fit if there is a 3rd card in between. If it is, I'm suprised that a dual-slot solution where the 2 slots aren't adjacent is even conforms to the required spec. Is the problem that your heatsinks are too big? Exactly WHY does it become unusable, and how could Tyan possibily think that such a restriction is reasonable?

M-Series Buffered Event Counting with DMA -- gating problem

Hi --
I am implementing DMA-based buffered event counting on a PCIe-6259 board. I use G0_Out as the gate for G1, which counts events on a PFI pin. So by setting the speed of G0, I get an event count (either cumulative or non-cumulative) on a periodic basis, which is directly DMA'd to my buffer, and synchronized with other i/o operations.
This is working well right now, except for one problem, which is that the I only get data if there is at least one source edge between gates. i.e. if there are no edges, nothing gets pumped to the dma buffer.
I am guessing that a stale data error is somehow choking off the DMA transfer from the counter. Is that possible?
Is there some magic that I need to do to avoid this, because for this application, especially if I am counting cumulatively, I don't care about a missing edge, but I do care if the dma transfers get out of phase with the rest of my timing.
Thanks in advance for any help!
--spg
Here is a snippet of the code that sets up the event counting on G1, partly based on gpctex6.cpp:
const int sDMASelect[] = {1,2,4,8,3,5};
// source: pfi, or -1 for 20Khz clock
void eventTimerSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source)
   int sourceSelect = (source==-1) ? 0 : (source+1);
   //MSeries.CTR.Source
   tio->G1_Input_Select.setG1_Source_Select(sourceSelect); // (pfi+1) or 20Khz=0
   tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
   tio->G1_Input_Select.setG1_OR_Gate(0);
   tio->G1_Input_Select.flush();
   //MSeries.CTR.Gate
   tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
   tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
   tio->G1_Input_Select.flush();
   //MSeries.CTR.IncrementRegisters
   tio->G1_AutoIncrement.writeRegister(0);
   //MSeries.CTR.InitialCountRegisters
   tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1_Mode::kG1_Load_Source_SelectLoad_A);
   tio->G1_Load_A.writeRegister(0);
   tio->G1_Command.writeG1_Load(1);
   tio->G1_Load_B.writeRegister(0);
   tio->G1_Load_A.writeRegister(0);
   tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG1_Command::kG1_Bank_Switch_EnableBank_X);
   tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_Command::kG1_Bank_Switch_ModeGate);
   tio->G1_Command.flush();
   //MSeries.CTR.ApplicationRegisters
   tio->G1_Input_Select.setG1_Gate_Select_Load_Source(0);
   tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::tG1_Mode::kG1_Reload_Source_SwitchingAlternate);
   tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_Gate);
   tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::kG1_Loading_On_TCRollover_On_TC);
   tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active_High);
   tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_Disabled);
   tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTIO::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Does_Not_Stop);
   tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_Stop_ModeStop_On_Gate);
   tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::kG1_Counting_OnceNo_HW_Disarm);
   tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode(0);
   tio->G1_Input_Select.flush();
   tio->G1_Mode.flush();
   tio->G1_Second_Gate.flush();
   //MSeries.CTR.UpDown.Registers
   tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command::kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
   //MSeries.CTR.OutputRegisters
   tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::kG1_Output_ModePulse);
   tio->G1_Input_Select.writeG1_Output_Polarity(0);
   //MSeries.CTR.BufferEnable
   board->G1_DMA_Config.writeG1_DMA_Reset(1);
   board->G1_DMA_Config.setG1_DMA_Write(0);
   board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
   board->G1_DMA_Config.setG1_DMA_Enable(1);
   board->G1_DMA_Config.flush();
   tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode(0);
   tio->G1_Counting_Mode.setG1_Alternate_Synchronization(0);
   tio->G1_Counting_Mode.flush();
   //MSeries.CTR.EnableOutput
   //board->Analog_Trigger_Etc.setGPFO_1_Output_Enable(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_EnableOutput);
   //board->Analog_Trigger_Etc.setGPFO_1_Output_Select(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_SelectG_OUT);
   //board->Analog_Trigger_Etc.flush();
   //MSeries.CTR.StartTriggerRegisters
   tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_Arm_Enable(0);
   board->G0_G1_Select.writeG1_DMA_Select(sDMASelect[dmaChannel]);
   tio->G1_Command.writeG1_Arm(1); // arm it
Scott Gillespie
http://www.appliedbrain.com
scott gillespie
applied brain, inc.
Solved!
Go to Solution.

Okay, I have it working now. In addition to your suggested changes, I had to remove the following line:
tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_Arm_Enable(0);
It appears that writing something to MSeries_Counting_Mode causes that register to supersede the Counting_Mode register. Is that right?
So code that now works for me is listed below.
thanks Tom!
-spg
void eventCounterSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source) // pfi, or -1 for 20Khz clock
int sourceSelect = (source==-1) ? 0 : (source+1);
//MSeries.CTR.Source
tio->G1_Input_Select.setG1_Source_Select(sourceSelect); // (pfi+1) or 20Khz=0
tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
tio->G1_Input_Select.setG1_OR_Gate(0);
tio->G1_Input_Select.flush();
//MSeries.CTR.Gate
tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
tio->G1_Input_Select.flush();
//MSeries.CTR.IncrementRegisters
tio->G1_AutoIncrement.writeRegister(0);
//MSeries.CTR.InitialCountRegisters
tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1_Mode::kG1_Load_Source_SelectLoad_A);
tio->G1_Load_A.writeRegister(0);
tio->G1_Command.writeG1_Load(1);
tio->G1_Load_B.writeRegister(0);
tio->G1_Load_A.writeRegister(0);
tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG1_Command::kG1_Bank_Switch_EnableBank_X);
tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_Command::kG1_Bank_Switch_ModeGate);
tio->G1_Command.flush();
//MSeries.CTR.ApplicationRegisters
tio->G1_Input_Select.setG1_Gate_Select_Load_Source(0);
tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::tG1_Mode::kG1_Reload_Source_SwitchingAlternate);
tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_Gate);
tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::kG1_Loading_On_TCRollover_On_TC);
tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active_High);
tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_Disabled);
tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTIO::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Does_Not_Stop);
tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_Stop_ModeStop_On_Gate);
tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::kG1_Counting_OnceNo_HW_Disarm);
tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode(0);
tio->G1_Input_Select.flush();
tio->G1_Mode.flush();
tio->G1_Second_Gate.flush();
//MSeries.CTR.UpDown.Registers
tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command::kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
//MSeries.CTR.OutputRegisters
tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::kG1_Output_ModePulse);
tio->G1_Input_Select.writeG1_Output_Polarity(0);
//MSeries.CTR.BufferEnable
board->G1_DMA_Config.writeG1_DMA_Reset(1);
board->G1_DMA_Config.setG1_DMA_Write(0);
board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
board->G1_DMA_Config.setG1_DMA_Enable(1);
board->G1_DMA_Config.flush();
// from Tom:
// The "magic" you need is referred to as synchronous counting mode (or Duplicate Count Prevention in NI-DAQmx).
// Try setting G1_Encoder_Counting_Mode to 6 (synchronous source mode) and G1_Alternate_Synchronization to 1 (enabled).
tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode(6); // 0
tio->G1_Counting_Mode.setG1_Alternate_Synchronization(1); // 0
tio->G1_Counting_Mode.flush();
board->G0_G1_Select.writeG1_DMA_Select(sDMASelect[dmaChannel]);
tio->G1_Command.writeG1_Arm(1); // arm it
scott gillespie
applied brain, inc.

Does PCI-DIO-96 have DMA?

Does the the National Instruments PCI-DIO-96 have Dynamic Memory
Allocation? I was hoping to be able to have digital input be sampled by
the card asynchronously rather than have to force the computer to use
processing time to look for new inputs on the card.
Thanks.
-Tony

Tony,
Your PCI-DIO-96 Board does not has DMA. This board doesn't has any FIFO component on it so its not capable of configuring an on board buffer for later transfer to the computer buffer. The 653x family does have DMA, but the 650x family in which your PCI-DIO-96 board belongs to does not has DMA. You can find more information on each products catalog webpage in the datasheet link. (www.ni.com).
Your best approach with this board is performing handshaking I/O.
Good luck!...
Nestor Sanchez
Applications Engineer
National Instruments
Nestor
National Instruments

K8N 7030 BIG Strange problem with DMA?

My conf.
2 x 80 GB SATA RAID STRIPE (WINXP)
1 x 160 GB PATA
1 x DVD LITEON PATA
2 x 512MB KINGMAX
Wireless PCI planet
Ieee 1394 PCI
6800GT AGP galaxy
PSU 500W
BIOS 2.1
Recently I saw that my hdd (160GB PATA) didnt work in udma 5 (worked in pio) and dvd worked in pio (in bios was activated dma etc.) This problem was not always. Begin I thought that controller in mobo is broken. I put in pci pata controller and it can`t work if I turn off the ide controller in mobo. But when i turn off IDE controller in mobo, RAID can`t work (its silly because RAID is sata not pata). After this sound card in mobo desappeard. Even I unplug all pci devices the sound card completly deasappeard. I update bios the same version and reset bios...and it helps. Now, dvd and hdd works, but I think it could repeat. Where is a problem?

Quote from: Slepy on 05-June-06, 23:20:59
I don`t have a time for new instalation windows. I think the problem isnt in windows. Maybe drivers, but if it was a problem, why the sound card deasappeard even I reinstall all drivers? I suspect bios. It can be problem with sharing IRQ. Now I have Bios ver. 2.1
syar said me:
"nvidia ide/sata drivers needs to be matched (in version) with the nvidia raid class driver .
You need to be careful installing windows and updating/installing nvidia UDP driverpackage
for NF3 .
It has an error in it , it never updates the nvraid driver (when you select to install the NV IDE sw
drivers).
Yes it's true what Syar's say. But beware if you neva do properly you may screw up your Raid array. But it's better to do manual flashing the Bios if want to flashed it. If your system is stabile and did not bring any problems then you shouldn't flashed it. Also I'll do back the array again and do the fresh installation. BTW you must used the Nvidia driver 5.10 it's more stabil and safe rather than 5.11. Gd luck.
This can leave you with mismatched nvraid and ide/sata driver .
Nvraid driver with version from the floppy disk used in win install, and nv ide/sata drivers with
the version from the UDP driver pack install .
Other than that I have heard mostly bad things of all MS-7030 bioses after 1.7 .
I have one rig at home with K8N Neo Platinum (MS-7030) running with bios 1.5B6(modded)
with raid-0 and it's been acting like a champ . No need for any "newer" bios .

Where can i find vis to communicate (via RS232) with a controller ?

Hi,
i use Labview 6.0 with windowsXP. I have a PCI/RS232 car to connect to my controller.
I'd like to command my controller (no vis available).
i am beginner and my problem is: how to communicate (send commands, know the syntax, formation and transfer of commands and recognition of the responses) with my controller via Labview and serial communications?

Hello Sebsanaur,
You can found, in the link below, document that can help you to understand the Serial Communication:
http://zone.ni.com/devzone/conceptd.nsf/webmain/c553228fd78a7add862568f9006e9129?OpenDocument#2
Now about the Instrument driver jetDrive III controller from MicroFab Technologies, you can found in the link below, a NI tool to "Search Instrument Driver" from manufacturers:
http://sine.ni.com/apps/we/niid_web_display.drv_search
The driver you search is not available in our web site however you can contact MicroFab Technologies to see if they develop it for LV.
Hope this help.
Best Regards,
Sanaa TAZI
National Instruments France
Sanaa T.
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;}
>> http://www.nidays.fr/images/081110_ban_nidays09_468X60.gif

How to simutaneously use 2 PCI cards, one with traditional DAQ, the other with DAQmx?

Hi,
I am currently trying to debug a system that used to work.. but sadly isnt anymore
A single computer contains 2 PCI cards (6110 & 6036E). The 6110 card is controlled by a fairly old software, programmed in labview, and hence, using Traditional NI-DAQ. The 6036e card is controlled by a more recent soft, programmed in LV as well but using DAQmx.
the AI/AO of the 6110 card is only momentarily used (20 sec consecutively, every minute) while the 6036E card is continuously receiving and sending data on its AI/AO.
Now the problem: the program that control the 6036E card freezes every time that the old prog access the 6110 card.. and then it works again perfectly until the next time that the 6110 card is used.
So my question: how can I make those 2 cards work simultaneously?
I dont think that it is because of the software nor because of the computer lack of memory/CPU if it used to work in the past. It might be about a wrong configuration of cards in the MAX but I couldnt find anything wrong there (no problem when accessing AI/AO of both cards through "test panel")
Thank you very much for you help.

That's what bugs me. The only thing that those 2 cards share is an AO of the 6110 connected to an AI of the 6036.
For the rest, nothing is common. The 1st program only deal with device1, while the 2nd prog only access dev2. There shouldnt be any problem and everything is working fine separately. Hence, why I was wondering if the traditional daq and daqmx might conflict on a same computer.
I just cant find out why the 2nd program controling the daqmx card just freeze everytime the 1st program access the traditional card. It actually doesnt freeze completly but becomes soooo slow, with about only 2 iterations of the main while loop during those 15-20 sec (instead of the normal 3-4000 iterations during such a period).
The computer specs are a 2.2ghz proc for 1G of ram and running XP, so it should be ok.. even though the computer does slow a bit down when the 1st prog access the traditional card.

NI PCI-8430 RS232 with DMA

Similar Messages

Maybe you are looking for