Many CAN protocols require a byte in a cyclic message to be incremented each time the message is sent (this is often byte 0). I might have read somewhere that this is possible with VeriStand but I am not using it. So when using only LabVIEW and the NI-XNET API, the only way to achieve this is to call the XNET Write function to manually set the value of this byte. But having to call the API each time the message should be sent removes all the benefits of cylic messages... Moreover LabVIEW can't guarantee the same level of speed and determinism (if the message is to be sent every 5ms for example).

Being able to configure a signal to be an auto-incremented counter would be a huge improvement. To me, this is a must-have, not a nice-to-have...

When a cDAQ (I'm using both a 9184 and 9188) chassis is energized (or the host computer is rebooted) it is programmatically read as reserved (by either MAX or LAbVIEW program). To gain control of the chassis, one has to either use MAX (MAX deosn't save or remember the previous reservation) and reserve it or programmatically force the reservation in the LabView code. In addition, if a chassis is reserved by a different host, another host can force the reservation by itself programmatically. Both of these can be accomplished by using the reserve chassis function with the 'Override Reservation' input set to True. This really is not a good method - it's effectively a hostile-takeover of the hardware (I've tried this and I can literally reserve hardware that is actively being used by another host).

I would recommend the following firmware/driver/software updates/corrections:

1. When a chassis is power-up it should be in an ‘unassigned’ state. Basically it will be in 'standing-by' waiting for a job/task.
2. When a host interrogates the chassis it should only be able to ‘reserve’ it if it is in the ‘unassigned’ state. Once the chassis is reserved by a host it is locked to it until it is either unreserved by the host or power is cycled to the chassis and it reboots, returning it to the unassigned state.
3. When interrogated, a ‘reserved’ chassis should provide the identification of what host has reserved it. This would allow redundant or multi-host configurations to find each other and do things like handing-over a chassis between hosts. This is useful if a host error is detected (redundant host system) or a host needs to be taken offline for service and the process can’t tolerate extended interruption (and it's useful to do this programmatically).
4. The chassis firmware and functions in DAQmx should be updated or augmented consistently to support 1,2, and 3.
5. There should be example code showing how to implement these features

All of the JAT's VIs output results as "sequence" and "timestamp", eg. the "Max and Min Voltage.vi".

I use the JAT to analyze high speed differential signals with unit interval of just 300ps. Because of this, the timestamp output cannot meet the required resolution. However, if timestamp is replaced with double precision float, it should be able to.

I have brought this up with NI's tech support and this is what they recommend, which is to suggest this change over here.  

This is pretty trivial to achieve through LabVIEW itself, but...

Signal Express is a simple, stand alone data acquisition system that allows those with limited exposure to LabVIEW set up simple test and measurement routines. One area where this is ideal - at least, for me - is in environmental or long life testing. Instead of crafting a beautiful piece of custom software for my colleagues, I can hand them a DAQ, point them in the direction of the SignalExpress and DAQmx installers, and off they go. With a little fiddling, they can create a logger that suits their needs.

One thing I've noticed, however, is that when sampling with non-simultaneous cards such as the USB 6225, users will select 1-pt-on-demand, set to some big interval, and then come back screaming at the top of their lungs - "OHMYGOD THERE'S CROSSTALK BETWEEN CHANNELS!". With a little bit of fault-finding, it's easy to point out that it's not crosstalk, but ghosting between channels, because I would guess that 1-pt-on-demand uses interval sampling and rattles through the multiplexing as quickly as it can.

My idea: give users the option to either select round-robin mode with a sensible delay, or complete control over the interchannel delay.

I realise that the standard line is usually "use LabVIEW" - I do - but I'd rather spend my time working on the important stuff and empowering those with less experience and/or exposure to make accurate measurements.

I use a PXIe-6363 which a wonderful device.   But it lacks level shifting at the digital I/O.

I would recommend that most DAQ multi-io devices support programmable and externally driven level-shifting for digital IOs.   Range for DAC driven level-shift (0.8 - 3.6, 5V),  and support for external input.   It would also be nice if multiple ports are present that some of them allow independent logic levels.  Default level should be 3.3V.    Port configurable pull-up, pull-down and latch-hold.

It is not possible to build Kernelmodule nirlpk 2.0  on Kernel >= 3.10

nimhddk_linuxkernel/LinuxKernel/nirlpk/objects/nirlpk.c:1076:5: error: implicit declaration of function ‘create_proc_read_entry’ [-Werror=implicit-function-declaration]
if (create_proc_read_entry(nNIRLP_kDriverAlias, 0, nNIRLP_procDir, nNIRLP_procRead, NULL))
^

create_proc_read_entry appears to have been deprecated in kernel 3.10.

See discussion here http://forums.ni.com/t5/Driver-Development-Kit-DDK/VM-RESERVED-and-create-proc-read-entry-deprecated-in-3-x-kernels/td-p/2937576