DAQmx allows to register dynamic events , but how about NI-Scope, NI-Fgen , .... if you have an event you can route to something in hardware it should be possible to register it also as an dynamic event in LabVIEW.
Just ran into a situation where I need to stream a lot of data to TDMS. The only problem is that I need to store additional metadata with the channels. I could go through all of the generated TDMS files and insert them after the fact, but this is kind of tedius. I propose a way to add metadata to the channel. My first thought was to use a variant input on the Create DAQmx Channel, but some of the polymorphics already have really fully connector panes. So I am now thinking to just add a property to the Channel Property Node that is just a variant. When logging to TMDS, the variant attributes can be put in the metadata of the channel. Do something similar for the group so that we can have additional group metadata.
Metadata that I'm currently thinking about could include sensor serial number and calibration data. I'm sure there is plenty of other information we would like to store with the TDMS file.
When doingPWM with DAQmx, error -200684 is thrown if a 0% duty cycle is attempted. For situations where a true 0% is needed, this is problematic. There are a few workarounds available, but some are less than ideal.
The suggestion here is to pause the output if a 0% duty cycle is attempted.
PCI Express bus became more and more popular. PCIe has a new type of interrupts - MSI/MSI-X. Today VISA driver is able to work only with old style interrupts (Legacy).
Let me explain the main difference:
Legacy interrupt mask intA/B/C/D signals (these signals was in PCI bus, but not exist in PCIe bus). These signals (for PCIe actually packets with Message setA/B/C/D) are shared between all PCIe devices. So VISA driver spend a lot of time when it looks who produced this interrupt.
MSI interrupt is actually a Memory Write packet to preallocated address. In this case VISA should already know which device produced this interrupt. Also MSI interrupt can contain different interrupt vectors inside of Memory Write packet. So it would be very helpful to get access to vector value too.
Requesting MSI/MSI-X interrupts support to VISA driver.
It would be great if the full DAQmx library supported all NI data acquisition products on Windows, Mac OS X and Linux. The situation right now is too much of a hodge-podge of diverse drivers with too many limitations. There's an old, full DAQmx library that supports older devices on older Linux systems, but it doesn't look like it's been updated for years. DAQmx Base is available for more current Linux and Mac OS systems, but doesn't support all NI devices (especially newer products). DAQmx Base is also quite limited, and can't do a number of things the full DAQmx library can. It's also fairly bloated and slow compared to DAQmx. While I got my own application working under both Linux and Windows, there's a number of things about the Linux version that just aren't as nice as the Windows version right now. I've seen complaints in the forums from others who have abandoned their efforts to port their applications from Windows to Mac OS or Linux because they don't see DAQmx Base as solid or "commercial-grade" enough.
I'd really like to be able to develop my application and be able to easily port it to any current Windows, Mac or Linux system, and have it support any current NI multi-function DAQ device, with a fast, capable and consistent C/C++ API.
As documented in a previous post, it is currently impossible to install the nidaqmx-python library into a Docker container. Enabling this functionality would create an opportunity for software teams to build cutting edge big data pipelines for measurement instruments using container technology. This could also optimize development time by including custom DAQ code in continuous integration pipelines.
By default, DAQmx terminal constants/controls only show a subset of what is really available. To see everything, you have to right-click the terminal and select "I/O Name Filtering", then check "Include Advanced Terminals":
I guess this is intended to prevent new users from being overwhelmed. However, what is really does is create a hurdle that prevents them from configuring their device in a more "advanced" manner since they have no idea that the name filtering box exists.
I am putting "advanced" in quotes because I find the distinction very much arbitrary.
As a more experienced DAQmx user, I change the I/O name filtering literally every time I put down a terminal without thinking about it (who can keep track of which subset of DAQmx applications are considered "advanced"). The worst part about this is trying to explain how to do something to newer users and having to tell them to change the I/O name filtering every single time (or if you don't, you'll almost certainly get a response back like this).
Why not make the so-called "advanced" terminals show in the drop-down list by default?
Often I need to create a simulated version of a real device in order to debug something. It would be nice if I could right-click on a real device in MAX and select "Create simulated version of this device", and it would create a simulated version of the device I'm running. This isn't so bad with standalone devices but it could make simulating modular devices easier and reduce the likelihood of a mis-click making an incorrect simulated device.
So I have a cRIO with a 9203 mA input module. I also have sensors etc that are 4-20mA. So when it came to using the scaling feature of the shared variable as below see if you can spot the bug.
So I was thinking in mA from sensor to mA input to the 9203 which is a mA module - but the RAW scale is in Amps! (Which is obvious once your colleague points it out!) Consequently I wasn't seeing any signal readings from the cRIO as 20mA << 4A.
Since there is an error if you get Full and Zero around the wrong way... can there also be an error or warning if its outside the range of the module?
When using TDMS on cRIO systems, there are a couple of considerations that doesn't normally play in too much when storing data as TDMS files and they are:
* The current version of the file system used on cRIO controllers degrades significantly in performance if -any- folder on the cRIO contains more than ~100 files. (work-around> more elaborate folder structures, but a lot of this structuring would be only to work around this shortcoming of the (old) version of the file system
* The drives are SSD with limited life-length and wear-leveling etc. Writing and re-writing these index files add un-necessary overhead and wear on the disks
* They use up space which is (very) limited on some cRIO's (even if not much). (people may be quick to point out that you can add a thumb-drive, but down-sides to that is the thumbdrives (as far as I know) needs to be FAT. Compared to storing on the cRIO file system which is atomic and fail-safe where you pretty much don't have to worry about sudden power outages and interruptions mid-write.. on a thumb drive you would have all these issues that could worst case corrupt your whole thumb drive.)
I propose to add a boolean (default to false) on the TDMS Open called "supress writing tdms index to disk" or some smart name along those lines. What this would do is still allow for the tmds index to be created, but it will remain in memory only and never be written to disk. When the TDMS Close is called, the memory is released and the tdms file is written to disk without the index file. If the same file is opened again, extra time would be needed since the index file would be re-created (again in memory only if boolean indicates this), but I think for the most part this overhead would be more than acceptable.
I'm not sure how "simple" modifying the TDMS open and close functions would be, but I do know that there are many cases where this flag would make sense.
There isn't anything in the event data node to tell you which line triggered the interrupt. I'm proposing we add something in the event data node for this event (like a bit field or a reference to the channel) so the programmer would know which line fired the event.
The workaround is you do a DAQmx read at this point and you mask the data vs previous data.. but I would prefer not to do this.
It is a frequent requirement to make measurements on production lines. Position on these is often tracked with Rotary Encoders https://en.wikipedia.org/wiki/Rotary_encoder . Many NI devices can accept the quadrature pulse train from such a device, and correctly produce a current position count. The information in the 2 phase pulse train allows the counter to correctly track foward and reverse motion.
What would be very useful would be a callback in NI-DaqMX that is called after every n pulses, ideally with a flag to indicate whether the counter is higher or lower than the previous value, i.e. the direction.
We need a way to query an output task to determine its most recently output value. Or alternately, a general ability to read back data from an output task's buffer.
This one's been discussed lots of times over the years in the forums but I didn't see a related Idea Exchange entry. Most of the discussion I've seen has related to AO but I see no reason not to support this feature for DO as well.
There are many apps where normal behavior is to generate an AO waveform for a long period of time. Some apps can be interrupted unexpectedly by users or process limit monitoring or safety range checking, etc. When this happens, the output task will be in a more-or-less random phase of its waveform. The problem is: how do we *gently* guide that waveform back to a safe default value like 0.0 V? A pure step function is often not desirable. We'd like to know where the waveform left off so we can generate a rampdown to 0. In some apps, the waveform shape isn't directly defined or known by the data acq code. So how can we ramp down to 0 if we don't know where to start from? This is just one example of the many cases where it'd be very valuable to be able to determine the most recently updated output value.
Create a DAQmx property that will report back the current output value(s). I don't know if/how this fits the architecture of the driver and various hw boards. If it can be done, I'd ideally want to take an instantaneous snapshot of whatever value(s) is currently held in the DAC. It would be good to be able to polymorph this function to respond to either an active task or a channel list.
Approach 2 (active buffered tasks only):
We can currently query the property TotalSampPerChanGenerated as long as the task is still active. But we can't query the task to read back the values stored in the buffer in order to figure out where that last sample put us. It could be handy to be able to query/read the *output* buffer in a way analogous to what we can specify for input buffers. I could picture asking to DAQmx Read 1 sample from the output buffer after setting RelativeTo = MostRecentSample , Offset = 0 or -1 (haven't thought through which is the more appropriate choice). In general, why *not* offer the ability to read back data from our task's output buffers?
I bought a NI USB-6251 BNC but the support explained me that it would have no Linux support out of the box. I will have to find out how to use it on Linux systems myself now (perhaps with help of the forum). It would be a nice feature, if it would ship with Linux support.
Basically, FlexLogger limits the range of readings to the values used in the 2 point calibration. For example, if your sensor has a range of -10 to 10 PSI, and the 2-point cal is done at +/- 10 PSI, FlexLogger will only display values within +/- 10 PSI (and will saturate otherwise).
I totally understand why this is done, but sensors in fact DO read above (and sometimes below) their stated ranges and have documented accuracy (i.e. 1% above 95% full scale) , so clipping the value to the scaling settings in the cal page is the wrong thing to do...the sensor can still be measuring correctly, but FlexLogger will only show the saturated value.
The scaling, however it is done, probably result in a Y=mX + b equation, and FlexLogger should display Y, whatever Y is, regardless of stated sensor range or 2-point cal/scaling.
A worse case is if the sensor has a range of +/- 10 PSI but your cal/verification system is only capable of +/- 5 PSI, you will be limited to +/- 5 PSI with the FlexLogger 2-point cal implementation.
Yes, there are way around this, but why should the user, usually technicians who don't necessarily understand the math or ins/outs of software, have to figure out a way around FlexLogger?