LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

more DaqMx trouble

having sorted out some issues while moving form traditional ni-daq to daqmx based programming, I'm still facing new problems,

e.g., in ni-daq, there was a 'SCAN_to_Disk()' function to directly redirect acquired data to disk instead of memory.
now I can't find an equivalent for this in daqmx ??

another problem is how to monitor a running acquisition.
in ni-daq, I used a construct like:

       SCAN_Start(Board, buffer, Nch * Nsamp, Timebase, Interval, 0, 0);
        while ((!Finished) && (!AbortMeas))
        {
                Err = DAQ_Check(Board, &Finished, &PointsAcqd);
                SetCtrlVal(panel, InfoAcqd, PointsAcqd);
                ProcessSystemEvents();
        }

 which would allow for
-   display numof currently acquired samples (PointsAcqd)
-   abort acquisition by pressing <esc> or thelike (which would be processed by a callback, setting 'AbortMeas' value appropriately)

now, how to achieve this with daqmx ?
(e.g. using 'DAQmxReadAnalogF64()' which obviously can't be aborted by keypress)


--
Once the game is over, the king and the pawn go back into the same box.
0 Kudos
Message 1 of 6
(3,976 Views)
Hi josswern!

    using DAQmxReadAnalogF64(), you have a parameter named Samples per channel read, which returns the number of read points.

   If you refer to ContAcq-IntClk-AnlgStart example, you will find a way to continuous sample and check the value of a variable, which states if a button has been pushed. This is a common way for performing continuous acquisition, that stops on button click.

   In most cases, with new DAQmx you have to re-engineer your software, so if you do not find a function, you have to perform different operations.  I've never heard about a SCAN_to_disk function in DAQmx, maybe it was useful on older archiectures.  Maybe you should manually save (append) the read array to a file.

   Anyway, it is interesting to know if there's an equivalent of this SCAN_to_Disk!

   Hope it helps!

graziano
0 Kudos
Message 2 of 6
(3,973 Views)
ok, thanks,
according to the example ContAcq-IntClk-AnlgStart
I managed to setup a callback

DAQmxRegisterEveryNSamplesEvent (taskHandle,
                                     DAQmx_Val_Acquired_Into_Buffer, 100,
                                     0, EveryNCallback, NULL);
   
which enables me to update a numeric control with the current #of acquired samples, however, it seems that functions like DAQmxReadAnalogF64()
are not interruptable via panel-callbacks (which worked before in nidaq-traditional), so I'm still trying to find a way for a user to abort a measurment in case,
e.g. a trigger signal is not available (in which case the mentioned function just waits forever, or at least until timeout occurs).

I also checked the other 2 daqmx event callbacks available: DAQmxRegisterDoneEvent(), DAQmxRegisterSignalEvent()
but these are not suitable for user-events, and I couldn't find anything else, so far.

and, well, it is totally clear that I will have to re-engineer the hardware-related code of my programs, but without a comprehensive documentation, this can be very frustrating...

as for
SCAN_to_Disk(), yes, this function was most useful in cvi 3.x, 4.x on win16 platforms, where array-size/memory had strict limitations.
anyways, I think it would still be good to have such a function.





--
Once the game is over, the king and the pawn go back into the same box.
0 Kudos
Message 3 of 6
(3,952 Views)
Hi, Josswern,

    it is not completely true that DAQmxReadAnalogF64() function (and similar) are not interruptable via panel callback, in fact you set the number of bytes to be read cyclically, and you can interrupt reading between two packets; I mean, if you set to read 1000 samples per cycle, you can interrupt your cycle only after 1000 samples are acquired (or 2000, 3000.....), but you have to put a ProcessSystemEvents() function in each cycle!

   ProcessSystemEvents() tells the application to check for events and other stuffs... if you're performing a CPU-consuming process, the application will lock, while forcing the system to check for system events allow you to check from inside the CPU-consuming cycle if some variable is changed (via user interface).

that's why:

     while( gRunning ) {
            /*********************************************
            /*/ DAQmx Read Code
            /*********************************************/
            DAQmxErrChk (DAQmxReadAnalogF64(taskHandle,sampsPerChan,10.0,DAQmx_Val_GroupByScanNumber,data,sampsPerChan*numChannels,&numRead,NULL));

            if( numRead>0 )
                PlotStripChart(panel,PANEL_STRIPCHART,data,numRead*numChannels,0,0,VAL_DOUBLE);
            ProcessSystemEvents();
        }


I know that at a first reading, hat I've written is not too clear (due to my poor english, too......), but keep on trying!

Let me know......

graziano
0 Kudos
Message 4 of 6
(3,950 Views)
again, Graziano,
your comments are much appreciated 🙂
but the problem with DAQmxReadAnalogF64() not returning will still remain in case the task is setup to start upon external trigger,
in which case no samples are acquired, so the program shown will never reach
ProcessSystemEvents(); - right ?
and that is what was possible with the 'old' functions like
SCAN_Start() in nidaq,
where I could setup a loop _after_ that which would check for user-events, signals, etc...
so I'm still missing what is, IMO, essential for proper operation.



--
Once the game is over, the king and the pawn go back into the same box.
0 Kudos
Message 5 of 6
(3,948 Views)
update:
I found out, DAQmxReadAnalogF64() may do what I want when

1. # of samples/channel to read is set to -1
2. task is set for continuous acquisition, not finite number - DAQmxCfgSampClkTiming (*taskHandle, "", rate, DAQmx_Val_Rising,DAQmx_Val_ContSamps, samplesPerChan)

in which case, I can use a loop with ProcessSystemEvents() to monitor user interaction.
the problem is, that the acquired data is corrupt (nonsense).
I'll further investigate, if this is due to another misconfiguration, or even a bug...

Message Edited by josswern on 01-12-2006 10:45 AM

--
Once the game is over, the king and the pawn go back into the same box.
0 Kudos
Message 6 of 6
(3,940 Views)