Data Acquisition Idea Exchange

Hello everybody!

Currently the AI.PhysicalChans property returns the number of physical channels for measurement (e.g. 16). However, to calculate the maximum sampling rate for the device programmatically (e.g. 9213), we need the total number of channels including the internal ones such as cold-junction and autozero (for 9213 it's 18).

Therefore I would like to suggest to include a property node with the number of the internal channels or the total number of physical channels or something similar.

Use case: programmatically calculate the maximum sampling rate in a program that should work for multiple types of devices without being aware of their type.

Thanks for consideration and have a great day!

[actually a customer's 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

Every time I have to work with a NI daq device the first thing i need to know is what pins can or cant do something.

Currently this involves looking through something like 7 diffrent documents to find little bits of information and bringing them back to your applicaiton.

A block diagram could easily be a refrence point for the rest of the documentation (you want to know about pin IO for your device look at this document)

Plus a good block diagram can tell you what you need to know quickly, and clearly. A picture is worth 1000 words?

Some might find the current documentation adiquite, but personally i would really like to have a block diagram that represents the internals and capiblities of the pins and device in general. Most Microcontrollers have this and it is an extremly useful tool. So why not have one for the Daq devices as well?

When using a buffered counter output task, the initial delay value is not used at all.  Instead, the user specifies an array of high and low times and the first low time is used as the initial delay.

If the output pulse train is repeated multiple times (or continuously), the first low time represents both the time from the trigger until the first pulse as well as the time between the last pulse and the first pulse.

It would be desirable to decouple these parameters by allowing for the option to use Initial Delay on buffered counter output tasks (e.g. with a channel property).  Here are a couple use cases off the top of my head where Initial Delay would be very helpful (if not required):

1.  This is the case I ran into (posted here😞  if you want to repeat a pulse train continuously every N seconds, you have to either have that N second delay at the start of the task or use another counter as a trigger source.  Depending on high and low times you might be able to get away with writing new values to the counter on-the-fly but this isn't a universal solution.

2.  If you wanted to synchronize multiple continuous buffered counter output tasks (with each one sharing a fixed desired period) to a common trigger source but with a different initial delay, you would be unable to do so since the requirement of having different initial delay would affect the period of your actual signal.  You would have to compensate by tweaking the other high/low times in your waveform (giving you something that you don't really want).

Hello,

DaqMx Vis only works when the NI Device Loader service is running.

If this windows service is not running, DaqMx functions generates error like "Device not found..., undefined board, undefined hardware ...."

For some week, i get such an error and it take me a long time to point the real cause !

A windows or software update had changed the service startup sequence ... and the Ni device loader service was no more starting.

The solution to this problem was to configure the NI Device Loader service in order to force restart on start failure. 

It should be nice if daqMX functions could generate the "right error".

An error like : "Ni services are not running please check their current state ... The DaqMx devices could not be accessed when Ni Device Loader service is not running".

This problem also generates problem in MAX ! (The device treeview takes a long time to expand ... and the device autotest fail)

Thanks for kudossing this idea which could help understanding windows services problems.