I'm looking for example code to use with Cont ACQ to File for Pocket PC

[arvin_labrat]

I would like to create a vi similar to Cont Acq to File (binary).vi for Pocket PC 2003 using Labview PDA Modual. I would also like to create a vi to read the acquired file.

[Tiptop]

Hello,


I can not find an example already written to do this. However, you can modify an existing example.

If you in the following folder,

C:\Program Files\National Instruments\LabVIEW 7.1\examples\daqmxbase\PDA\Ai

you should see Cont Acq&Graph Voltage-Int Clk.vi in this folder. This example could be modified so that it does something similar to the Windows example. You can get the raw data by going choosing More>>RAW>>1D I16 on the DAQmx Base Read VI.

Hopefully, this helps get you started in the right direction.

Let us know if there is a stumbling block when writing this program.

Best regards,

Justin T.
National Instruments

[arvin_labrat]

Justin
Thanks for your help. Instead of using the vi you suggested I used Cont Acq&Graph Multiple Voltages-Int Clk.vi and every thing is working but my read vi is not very flexible. I would like to strip the task name info to write the # of ch and the scan rate to the data file so the read vi will pull the info automatically.

If you have any idea how I could do that please let me know.

I've attached the vi's to this message just in case my description was not clear enough.

Thanks again, Eric

[Tiptop]

Hey Eric,

I have attached two VI's that I have modified. They should allow you to programatically read out information about your task. Please look over these and see how I changed them.

Let me know if you have any further questions about DAQmx Base!

Best regards,

Justin T.

[arvin_labrat]

Hello Again,

I'm having a problem with the scan rate timing on the PDA.
The model # of the PDA is IPAQ h5550 with Pocket PC 2003 and 128MB of Memory. The daq card is a 6062.

For an example, I used the NI-DAQmx Base Task Configuration Utility and set the scan rate to 1 hz (sample/sec). I set up my vi to read 1800 samples then stop. At a scan rate of 1 Hz acquiring 1800 samples should take 30 min. But when I ran my VI it acquried all 1800 scans in about 6 min.

I did notice that in one sub vi Eseries--Config Timing.vi that an unbundle cluster was wired with a scan rate (kHz) then went back to Hz.

If you have any suggestions on how I can verfiy my timing is the same as what I set in the configuration utility please let m
e know.

I would also like an explination of how the internal clock works vs. an external clock.

Thanks for your help

Eric

[Bill B]

Hello Eric,

Have you tried using the ai finite buffered task that is already completed in the the configuration utility?

The internal clock works by first supplying the sample clock. The sample clock marks the start of samples to be taken on all channels selected. Then a second clock which is faster converts each channel from analog to digital. Typically, the convert clock's frequency is the frequency of the sample clock mulitplied by the number of channels to be sampled. If you want to use an external clock, your external clock will be your sample clock, if you are sampling a single channel, you do not need a convert clock. If you are sampling mutliple channels, you need to specify the frequency of your external s
ample clock so the driver can determine the frequency that should be used for the convert clock.

Regards,
Bill B
Applications Engineer
National Instruments

[arvin_labrat]

Bill

I tried the ai finite buffered task that you suggested but I got the same result. Do you have any other suggestions?

I've attached a VI I made to determine the scan rate and the results of an experiment I ran to determine the calculated scan rate vs the set scan rate. I would appreciate your feed back on the results and any suggestions you might have.

Thanks again
Eric

[Tiptop]

Hey Eric,

I appreciate all of the testing and the posting of the code. Using this information I was able to reproduce the error that you are seeing. I looked through the driver, but the problem is not apparent to me. At this point I have filed a report with R&D so that they can look further into this issue.

When I hear back from R&D, I hope to be able to post more information about the issue on this thread.

Thanks for you patience,

Justin T.
National Instruments

[Tiptop]

Hey Eric,

I have heard back from R&D and understand what the problem is now. If you notice, all of your calculated scan rates are reasonable, except for the 1 Hz rates. The reason for this is that the driver does not actually support any rate slower then ~1.21 Hz. I have already left feedback with R&D that an error message is needed for this limitation.

If you really need a scan rate slower then 1.21 Hz, I would strongly suggest over sampling and disregarding the excess data in software. However, if you would like to know why we have a limitation of ~1.21 Hz, or are curious as to what a possible solution is, please read the rest of this post.

Explanation---

E Series DAQ boards contain a 24-bit scan down counter that they use for AI, and if you look through the driver, you can see that this counter is loaded with a value inside of the DAQmx Base Start Task.vi>> DAQmxBase Start Task ESeries.vi>>ESeries-- Config Timing.vi. Inside of the ESeries-- Convert Clock Rate.vi, the count down value is determined. Another point to note is that this scan down counter runs on the boards 20 MHz clock. So if you want a 1 Hz signal, then the initial scan down value should be 20 million. If you want a 4 Hz signal, the initial scan down value should be 5 million. The problem lies in that a 24-bit counter is limited to 2^24 - 1 (16,777,215) as its highest count value. So when you go to load the register with a value greater then ~ 16 million, you do not get an error, it simply ignores bits in positions greater then 24. So trying to load 19,999,999 (0x1312CFF) effectively loads a value of 3,222,783 (0x312CFF) because of the missing bit. If you divide 3,222,783 by 20 MHz, you get .1611 seconds, yielding a scan rate of 6.2 Hz, which is what we are seeing. Now the slowest possible rate is found by setting the board to the maximum count of 16,777,215. If you divide 16,777,215 by 20 MHz, you get ~.83 seconds, or ~1.2 Hz. At this point, you have probably wondered �why can DAQmx acquire at 1 Hz?� The reason is that DAQmx uses one of your general purpose counters, which can use the internal 100 KHz signal. If you divide 2^24 by 100 KHz, you get 167.77 seconds, or .0059 Hz. If you try and use a rate slower then .0059 Hz, or you reserve counter 0 for a DMA operation, then DAQmx will give an error or a warning. The problem now becomes that DAQmx Base 1.0 does not support using an external clock for analog input. So while it is possible to generate a 1 Hz pulse train with counter 0, the driver will have to be modified in order to support this. If this is of interest to you, then please let us know, and we can look into helping you modify the driver.

I know this is a lot of information. Please let me know what questions you have over the material that I have posted.

Best regards,

Justin T.
National Instruments

[arvin_labrat]

Justin

Thanks for the info. I don't need to run at 1hz I'll make an adjustment to 2hz. The only reason I was interested was because I was writing all my data to a file and I was worried about my files getting to big over a long period of time (8 hrs). I have been doing some testing at other faster scan rates and found that my files are still manageable if I use the raw i16 data format. Thank you for the explanation, it will make my future developments a lot easier.

Eric