daqmx read.vi timestamp incorrect problem (storing the timestamp from start task)

[freemason]

Hello,

I have a state machine with 1st state: configure DAQ where i have [daqmx create channel.vi --> daqmx timing sample clock--> DAQmx start trigger--> daqmx start trigger] connected in order

sample clock in continuous mode, 10000 samples to read and sample rate 1000 Hz ,

start trigger has rising edge selected with a dev1/PFI0 from a daq board.

next state of SM is read channels which has daqmx read.vi set to 1d waveform  Nchan Nsamp.

and the program first configures and goes to read channels state and is just waiting for the true value on PFI0,

but the time stamp is not updated to current time/ when daqmx read starts instead it is getting the initial t0 from the time when it was in configure DAQ state of my SM in other words it stores the starting time when strart task.vi was run and then updates from then on.

so in effect i am not getting the exact time stamp values while i am running the vi.

i tried to build waveform by inputting the actual current time but the chart doesnot scroll and shows only few values each reading, when i tried to input the t0 from the waveform given out by read daqmx. vi, it then behaves normally..

option #1 from this link says

http://forums.ni.com/ni/board/message?board.id=250&thread.id=47648&view=by_date_ascending&page=2

Try and do exactly what the driver does.  This will require you to do exactly what you are doing in the posted example.  Call the current system time immediately prior to calling the DAQmx Read and subtract dt * x where x is the number of samples already acquired.  This will require you to know exactly how many samples have been acquired.  This can be found by calling the Total Samples Per Channel Acquired property immediately prior to the DAQmx Read.  This introduces some points of innaccuracy.  For example, you're system time is already innaccurate to some amount.  In addition, it takes some time between calling system time, calling the total samples acquired, and calling the DAQmx read.  If 2 samples are acquired between calling the system time and total samples acquired, you could be off by a few samples.  For slower clock rates, you will have more accuracy. 

but there are no samples that are acquired until the rising edge, so the number of samples is always zero before the read operation

http://digital.ni.com/public.nsf/allkb/5D42CCB17A70A06686256DBA007C5EEA 

this link says that

and the number of samples in my waveform is constantly changing around 20-40, so i cannot really input the current time to build the waveform, thats what i can figure out for now..

can somebody tell me why this is happening or is there any fix around this, how to get the current time into my daqmx read.viso it displays the currect time on my waveform chart

Thanks,

[CWolf]

Hello,

What device are you using, and what version of LabVIEW and DAQmx?  If you have a start trigger configured, then the timestamp should not be off like that.   How far off is it?  Have you tried placing a very long timeout on the DAQmx Read and then waiting at least a minute before sending the pulse on the PFI line, and were able to see that entire discrepancy between the timestamp and the actual time (which you could check using a Get Date/Time in Seconds)?  

-Christina

[CWolf]

Try running something like this.  I did it on my computer and the timestamp on the waveform data matched the system time quite well. 

If you are still seeing a discrepancy when running this code, please take a screenshot of the front panel and attach it (along with the information about the device and driver version).  Thanks.

-Christina

[freemason]

thanks,

im using LV 8.6, daqmx driver 8.9.5.

yes the program u posted get the currect time. but see attached program thats what i have in my program exactly

if you took out the time to using the get waveform components using the waveform  from daqmx read. i still have the timestamp as the application start time. plz see attached code 8.2v and FP

the waveform time x axis is not current, it is starting from the application start time.

PS: samples to read = 10,000 and sample rate = 1000

plz help..

 

[freemason]

see attached ...

if i try to replace the timing of the waveform obtained by current time using build waveform , the chart on the FP does not show all values / does not scroll with al values, it refreshes with current data so i can see only at the end some portion of it.  

[freemason]

update:

the chart scrolling goes smoothly now when i use the port0/line0 of another USB-6009 device as input the dev1/PFI0 (BNC 2120) as opposed to connecting within the same BNC 2120.

so i think the time sharing is not happening for the device if connected internally..

but the start time is still off by the amount = time between application start and the trigger (ex: if i wait 35 seconds to press the trigger button after the app started running then it is off by 35 secs)

can somebody help solving this issue daqmx readtime stamp issue..

Thanks,

[CWolf]

I've been playing around with the code you submitted and the issue seems to go away if you wire a value other than -1 into the number of samples per channel input of the DAQmx Read VI. 

-Christina

[freemason]

Yes I observe it now, thanks very much but can you explain me how/why this could be happening.

for a smooth flow i had to trial and error for a approximate number which for me is around 150 samples / channel, if i put more then again ofcourse chart updates in steps..

number of samples per channel specifies the number of samples to read. If you leave this input unwired or set it to -1, NI-DAQmx determines how many samples to read based on if the task acquires samples continuously or acquires a finite number of samples.

If the task acquires samples continuously and you set this input to -1, this VI reads all the samples currently available in the buffer.

If the task acquires a finite number of samples and you set this input to -1, the VI waits for the task to acquire all requested samples, then reads those samples. If you set the Read All Available Data property to TRUE, the VI reads the samples currently available in the buffer and does not wait for the task to acquire all requested samples 

according to the def, and my observation, the time is updated depending on the available sample/buffer and since this value is changing constantly if input -1, the running time calculated according to the formula is is also off and so daqmx decided to ignore the start time when daqmx was read and goes with the time when the start task was run.

what do you think, any other ideas...

Thanks,