LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

pda sd card problem

so this program started off writing to internal memory on the PDA and it ran fine now I need it to write data to and SD Card and I am having issuies when I want to view the data becuase the format is all messed up most of the data is not there and the data that is there is not in the correct format.

 

I have included a sample program.

 

 

   I am also using a CF-6004 all 4 channel, windows mobile 6.0, labview 2009, PDA Module 9.0

 

 

 

Harold Timmis
htimmis@fit.edu
Orlando,Fl
*Kudos always welcome:)
0 Kudos
Message 1 of 10
(3,843 Views)

also I will get this error acationally

 

app failed. Error code 170353002. uable to allocate memory. I have looked through the forum and found 1 thing with this error and it had nothing to do with what I was doing.

Harold Timmis
htimmis@fit.edu
Orlando,Fl
*Kudos always welcome:)
0 Kudos
Message 2 of 10
(3,840 Views)

Harold,

 

Sounds like a tricky issue!

 

I took a look at your code and my first reaction was to suggest that you use a producer consumer architecture to separate your DAQmx Base Loop from your FILE I/O loop via a queue as having them in the same loop could cause problems if the file I/O takes to much time compared to the DAQ Task. However, there is a known issue with Windows CE based LabVIEW Programs that, "When calling a shared resource from more than one loop, that resource is not executed in a round robin fashion. This could lead to unexpected behavior while the loops wait for the resource." In most RT OS's, the memory manager is a shared resource and putting your DAQ Task (which is using the CF slot and might be using the memory manger) in a separate loop from your file I/O to the SD Card (most definitely using the memory manager) might cause the issue mentioned above which might not resolve the problem you are seeing.

 

I would like to note that DAQmx Base hasn't been tested/verified in Windows Mobile 6 and thus isn't technically a supported thing to be doing.  However, as you've demonstrated with your original program writing to the internal memory, it is very likely to work anyways.

 

Have you tried slowing down your sampling rate and writing more samples to disk with each write?

 

I would also suggest timing the performance differences of your DAQmx read's when writing to internal memory vs. external memory along with timing the write's to file for both internal and external. This might give us a clue as to where the problem may be coming from.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ben Sisney
FlexRIO V&V Engineer
National Instruments
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0 Kudos
Message 3 of 10
(3,822 Views)

Hey Ben,

 

     The only reason we have not used a producer consumer architecture is because we generate serially to get away from the over buffering issue.

Right now I have just implemented code to send data in packets rather than send Samples/sec it works better but I believe data is still not being written when it should be.

 

For assistance I did a 10 min test that produced a 80K file

than I did another test at 20 mins and it produced a 50K file

 

I think it will come down to trying the producer consumer and hope I do not get the buffer overflow error.

Harold Timmis
htimmis@fit.edu
Orlando,Fl
*Kudos always welcome:)
0 Kudos
Message 4 of 10
(3,818 Views)

Harold,

 

Thanks for the info! Just to make sure I understand the issue. When you write to local memory on the PDA, you do not see discrepencies in file size like those you just mentioned. Is this correct?

 

A really hokey workaroud would be to see what happens if you write to a local file and then move that file to the SD card programatically. You would probably have to break up the data into many different files (once a minute or so) to be able to do this.

 

Let us know how the Producer/Consumer works out.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ben Sisney
FlexRIO V&V Engineer
National Instruments
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0 Kudos
Message 5 of 10
(3,813 Views)

it ended up being transfer rate limitations on the hardware side:(

Harold Timmis
htimmis@fit.edu
Orlando,Fl
*Kudos always welcome:)
0 Kudos
Message 6 of 10
(3,798 Views)

So it was not a hardware limitation it was a constant that was out of place it is not working fine

 

Thanks

Harold Timmis
htimmis@fit.edu
Orlando,Fl
*Kudos always welcome:)
0 Kudos
Message 7 of 10
(3,755 Views)

Harold,

 

Thanks for the updates! I'm glad to hear that it's working now. If you don't mind letting us know, what constant was out of wack? In case we see this again, it would be good to know to advise others. Thanks!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ben Sisney
FlexRIO V&V Engineer
National Instruments
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0 Kudos
Message 8 of 10
(3,726 Views)

Ben,

 

it was the Open/Create/Replace file.vi and the constant was connected to the operation function.

Harold Timmis
htimmis@fit.edu
Orlando,Fl
*Kudos always welcome:)
0 Kudos
Message 9 of 10
(3,698 Views)

Harold,

 

Thanks for the info!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ben Sisney
FlexRIO V&V Engineer
National Instruments
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0 Kudos
Message 10 of 10
(3,665 Views)