counter task hang up system - strange

[feilong]

Hello All,

   This is a really nice place to post your problem and this time I have to get help here again.

   Now I am running a vi which take a 1 pulse per second signal from PFI9 (I am using E series DAQ card 6036E) as sampling clock to obtain a edge counting CTR and save that value as a timebase. this CTR is counting 100KHZ timebase.

n 

[feilong]

I am sorry something interrupt me when I input my post. here it is.

Hello All,
   This is a really nice place to post your problem and this time I have to get help here again.
   Now I am running a vi which basically just timestamp on each AI reading by reading the counter value when each AI/SmpClk pulse comes.
   What I did is to take a 1 pulse per second signal from PFI9 (I am using E series DAQ card 6036E) as sampling clock to sample a edge counting CTR task and save that value as a timebase. this CTR task 1 is counting 100KHZ timebase.
   The second CTR task is to use same counting edge source but use AI/SmpClk as sample cloclk for this task. The difference between the CTR 2 reading and CTR 1 reading will be regarded as time elapsed since last 1PPS pulse. I know the best way is to synchronize the two CTR starting same time but no way to do it with my DAQ card (is it?).
   Then I have a AI reading task which takes the channel 1 readings.

   I tried different way to implement the above schematic. The preferred way is to use a hardware-timed single point mode for all three tasks and use a internal source timed timed-loops process the CTR task 1.  Then use a external source (the sample complete event) timed timed-loop to process the AI task and CTR task 2. I call this vi as vi no.1.
   I also try another way to do this with two internal source timed timed-loops but I have to make sure the loop execute fast enough to keep up with incoming data. I call this vi as vi no.2.
 
   The strange thing is that, while the vi no.2 runs always ok, the vi no.1 seems to need a 'warm-up' before it could run well. If I launch labview the first time after I boost into windows, and I runs the vi no.1 as the first thing, it will hang up labview and only thing I could do is to force the labview windows close. But if I run the vi no.2 as the first thing after labview lanuched, then load the vi no.1 to run, it runs well.
   I put a few indicators in the vi no.1 and get rid of the contents in the time-loop to simplify the problem. I could notice that, when a hang-up happens, only the first and second indicators of CTR tasks and first indicator of AI task is lit, which means all the task not started actually when hang-up happened. I also put another internal timed time-loop runs in the background as a watch dog and it will counting its iterations while other tasks hang-up there.
   I have no clue about what cause this strange behaviour. But this is a critcal problem for me as this is part of our profuct delivery and I couldn't ask customer to run some unrelavant stuff to 'warm up' the machine before run the program. Any thought is very appreciated.
   To run my vis, you need to feed a signal (I am using 1PPS from a signal generator) to PFI9 line.

Many thanks

Feilong

Message Edited by feilong on 01-18-2008 10:26 AM

[mallorim]

Hi Feilong,

It sounds as if you are going through a lot of complicated work just to get the time stamp for each data point of your analog input task. Is this the case or are you trying to get the timestamp for when a specific event occurs?

Have you considered using the Waveform instance of the DAQmx Polymorphic Read VI? This instance of the Read VI can be seen in the attached screenshot and returns the data points in waveform format. You can change the indicator so that the data is displayed as an array of amplitudes with an initial start time and the delta t, or change in time, value. I have attached this in the second screenshot.  This way, by selecting your sampling rate, you can control how much time elapses between each data point, and then using the index of the data array, determine at what time that data point was recorded.

                             

I simply used the LabVIEW example VI Cont Acq&Graph Voltage-Int Clk. These examples can be found by navigating to the Help Menu>> Find Examples>> expanding the Hardware Input and Output folder>>expanding the DAQmx folder>> expanding the Analog Measurements Folder>> and then looking in the Voltage file. When you click on an example VI, a brief description will appear in the Information box to the right of the Example Finder.

Hope this helps, Mallori M.

Message Edited by mallorim on 01-21-2008 05:49 PM

[feilong]

Thanks mallorim for your advice.

I think this is a feasible way to timestamp the data in general case.

But what I need is to timestamp data in term of GPS time, as my other data comes with GPS timestamp. so I could synchronize them together in post-processing.

Also, to ensure no time drift over long lasting test, I have to correct the t0 periodically. This is why I have 1PPS signal from GPS receiver to "reset" counter base regulaly.

BTW, I think I found the problem in my application. The reason is I was using two "create timing source.vi". Now I keep only one and other task is changed to use while loop/"wait until next smpclk.vi". And now it works fine.  

Feilong

[Neal M]

Hello Feilong,

I am glad to hear you got your application working!  It seems like you may good to go, but I just wanted to point out that we do have our own device that allows you to do synchronization with GPS timestamps, the PXI 6608.  This could make it easier to synchronize things (especially if you are using a PXI chassis) and you can export the signal if you wish as well. Let me know if you want more information about this.

Again, I am glad to hear you got your program running, good luck with your application!

[feilong]

Thanks Neal, actually i thought about that board before but just due to cost I haven't made my mind to try it. It may be my option in future anyway.

Feilong