Data Acquisition Idea Exchange

When a piece of hardware is simulated with MAX, I would like to be able to insert a transfer function or a signal simulating VI to allow me to get a more realistic test of a system. The current default of generating a sine wave for simulated acquisition only lets me test part of the code. If a transfer function, lookup table, or custom vi were able to be substituted for the sine wave generation, then I would be able to test many other facets of a system.

I'm writing a paper on different sensors and how to choose the correct sensor when trying to measure a physical phenomenon.  Customers are going to want to search for boards that provide exciation or allow for external exciation, and I don't yet see that as an option on ni.com/products when narrowing a search of our products.  Does anyone else think this is a good idea?

I have a data acquisition NI-DAQmx/C++ program where I am continuously acquiring 5 channels of data at 40KHz/channel and reading them in 0.1 second chunks.  This successfully works perfectly for over 14 hrs continuous acquisition, but at 14hrs, 54 min and 47 seconds the program hangs up due to an overflow in the int32 DAQmxInternalAIbuffer_Offset value sent to the DAQmxSetReadOffset() function.  In the DAQmxSetReadRelativeTo() function, I set the offset relative to the first sample using DAQmx_Val_FirstSample.  (See "32-bit lmitation pof the NI-DAQmx int32 DAQmxSetReadOffset() function?")

It would be very helpful for the DAQmxSetReadOffset() offset value to be 64-bits rather than the current int32 value.  This would make this function analogous to the DAQmxGetReadTotalSampPerChanAcquired() which returns a 64-bit value.  I understand that the offset is maintained internally as a 64-bit value, so perhaps this would not be too difficult to do.

I hope that National Instruments fixes this limitation in their API, not just for 64-bit Windows, but also for 32-bit Windows because a lot of us are still using 32-bit compilers and our users are using Windows XP.  Perhaps it could be implemented as a separate DAQmxSetReadOffset64() 64-bit function for the 32-bit Windows.

Thank you,
Bill Anderson

There is currently no API available to develop applications that will use the functionality of the GPIB Analyzer. There are customers who would like to be able to monitor the GPIB bus from LabVIEW, so this would be helpful.

Hi

I'd like to see PCI express versions of existing PCI Analogue Output cards eg PCI6713 and PCI6733.

I'm finding it quite difficult (and quite a bit more expensive) to source desktop PCs featuring PCI slots.

The X Series has support for a watchdog timer that can be used to define the states for all DIO and PFI lines.  It would be useful to me if it could also set the states of analog outputs since those are also outputs often used to control systems that should have a defined condition upon a fault.

Steve

There is a need for a quick low cost device to controlling/communicating with the popular low-voltage differential signaling (LVDS).  There is a need for transmit only, receive only, and transmit/receive USB devices.  The current solution is to buy the NI USB-6501 and build a daughter board with TTL-LVDS ICs on it to interface to digital equipment in the military/defense industry. Lots of time and energy is wasted on designing, building, and cabling boards as as additional interface step, where a simple USB solution could be made available.