I'm working with some B class devices and can't work on the project at home because I don't have the hardware and can't simulate it. Can you add the NI USB-6008 and 9 (whole class would be nice) to the MAX 'create simulated device' list?
I have a hard time explaning to clients that the little application that just monitors a few AI channels requires a huge (several 100'sMB) installer to run. It would be nice to allow for a small subset of daqmx to work. Maybe there is a way of doing this or maybe it is way too hard, but it would be nice to have the ability to filter support for devices and daq type on the drivers installation.
install only 6609 or 6008 AI only support where the installer would be a small fraction of the current size.
When it comes to documentation of an measurement, you need to report ALL settings of a device that effects that measurement.
From a core memory dump written as a hex string to a XML document.... anything that shows up a difference in the settings that affect the measurement would be fine for documentation.
Something like a big property node readout followed by a format into string .... but make sure not to miss a property.... and a bit more complicated when it comes to signal routing....
A measurement that isn't sufficiently documented is all for naught.
Just think of a nasty auditor
It's so easy to make measurements with LabVIEW, please make it easy and consistent to document it.
A quick measurement setup with the DAQ-assistant/Express fills Gigabytes but after a certain time they are useless because nobody knows how they where taken. A simple checkbox could add all this information in the variant of the waveform. (or TDMS or ...) even if the operator don't have a clue of all the settings that affect his measurements.
Would like to be able to collect a couple channels of analog inputs to the iPad. This is nice but I need a minimum of 2 analog inputs and I would rather have NI: http://www.oscium.com/
Response from coorporate:
"We don't currently have anything that would meet
the customer's requirement of being able to plug in directly into the iPad for
I don't believe that the iPad supports Silverlight which is a framework developed by Microsoft. Also, wireless DAQ has to communicate with a host running DAQmx, so the customer would still need a 2nd computer even if using wireless DAQ.
If you want to connect data acquisition hardware (of any form-factor) to a machine running LabVIEW and DAQmx, then use LabVIEW Web Services to publish the front panel to the web and view/control it from his iPad.
We do have several USB products that will work with Windows-based netbooks that could be an alternative solution if topic is open to a non-Apple platform. For example, the 5132/5133 are bus-powered digitizers with much higher sample rate, bandwidth, and buffer size compared to the Oscium device. However, the price is also quite a bit higher."
Multiple people have requested that there be a natural way for Labview and SignalExpress to do a rotational speed measurement using a quadrature encoder. An express VI under "Acquire Signals>>Counter Input>>Rotational Speed" that asks you basic quadrature encoder type questions and computes the rotational speed would be very useful. The information it asks would be things such as Ticks per Revolution, Decoding type (x1, x2, x4) would be useful in computing rotational speed. In addition, this can be then converted into a shipping example for DAQmx relatively easily. I have had multiple people ask this question and believe that especially within SignalExpress, this would be very useful.
Have Max maintain a database of your transducers calibration due dates that can be monitored in LabView. Currently I maintain a lot of transducers that are used throughout my programs. I have them selectable through the Custom scale input. Unfortunately I cannot conduct a quick check to make sure that my transducer is in or out of calibration through the program. I would be nice to have that capability.
I could use a USB X series multifunction device with more than 4 AO analog output channels. My current application does not require them to have waveform generation capability. There are devices available with more than 4 AO but I need AI and DI/DO and CTR as well and prefer them all on one device.
I continually come to your site looking for the DAQmx base API manual and have yet to find it. I eventually have to dig out an old CD to find my copy.
How 'bout posting these online so that we can help ourselves out of jams?
It seems the only indication in MAX that a device is simulated is that under the Devices and Interfaces section, the tiny glyph to the left of the device name is colored yellow instead of being white/transparent. I end up not remembering what color means what. It would be useful to add text "Simulated" next to the device name. It would also help to distinguish simulated devices by having the color of that glyph be green (instead of its current transparent/white) when the device is installed and detected. Have the color change to red (and keep the existing red X) if had been detected and a device number assigned but is currently not installed/detected. Then simulated devices being yellow may imply "warning/caution" or "not real". Perhaps also have a help-hint popup ("Detected" or "Not Detected" or "Simulated") when the mouse hovers over device names.
Any series card should have a feature listing different parameters like voltage, temperature etc it supports(May be a property node should be used). so that user can configure the required parameter among the supported.
Ex: SCXI -1520 module can be configured as Strain, Pressure or voltage but this information will be known only by seeing its manual or when a task is created in MAX. But in LabVIEW Software i cant get this information directly. Because it allows me to configure 1520 as temperature also and we will come to known that 1520 module doesn't support for temperature parameters only when once tried to acquire.
So what you people think about you.Share your ideas on this please.
The title pretty much says it all. I would like the ability to either configure a full hardware compliment as simulated devices then switch them over to real devices when the hardware arrives or go from real devices to simulated devices without the need to add new, discrete simulated devices to MAX.
This would make for much easier offline development and ultimate deployment to real hardware.
I rarely have to set up hardware for a new analog measurement and always have to puzzle over the difference between RSE and NRSE modes. I think of the inverting input as the reference, so "Non-Referenced Single-Ended" doesn't make sense to me. And, if I run the AISense line to my remote sensor, isn't that a Referenced Single-Ended measurement?
Yesterday, I noticed that at least some on-line documentation now refers to GRSE (Ground Referenced Single-Ended); adding that single letter helps a lot. What about adding another single letter and referring to the other mode as RRSE (Remote Referenced Single-Ended)? One letter could save a lot of people a lot of time.
Suggest NI produce an inexpensive (<$100) USB "stick" that has 2 hardware counters on it for optically isolated measurement of encoders, or other high-speed devices. The stick would have a standard connector it for easy wiring of differential encoders with ABZ lines. The device would enable measuring two separate encoders or track two sections of a shaftless drive line that needs to position-follow. One or two DIO lines would be a bonus. This would seem to be a good fit for the industrial machine markets (at the very least). Today you need to buy a multifunction daq for a several hundred dollars if you want two counters.
Contact me with any further questions.
I am using DAQmx Physical channel controls in user Interface to select the particular DAQ modules.I would like to display only the particular type (AI,DI,AO,DO.....) of modules which is connected in the system.For example i need to display only, DO-NI-9477 cDAQ modules in the physical channel not the other DIO models like NI 9403...IO name filtering option not useful to filter the other models which is same type.
That should be great if NI provides the option for filtering the modules name based on their product type or user configurable naming (for example, if cDAQ1 device renamed as "DEV1" means user can enter filter the device based on the string "DEV").
When using TEDS load cells it would be useful to have a built in tare function The null offset function only offsets the electrical value by the intialy measured amount. This essentially shifts the calibration curve horizontally only. The tare function could also shift the calibration curve vertically, in the load direction. Since two point calibrations don't always create a line that goes through zero, a tare function is needed to get to zero. Please see the attached VIs. Also, check out my thread on this subject.
A DAQmx Device property "Watchdog Timer Supported" would provide indication of that capability for the selected hardware device. Few devices (X series being one) have a watchdog timer. Since they are often used as a means of safeguarding, it is important to know that the selected device supports that function. Currently, one has to attempt to Create a Watchdog Timer Task and then trap error -200662 which says the device does not support that feature.