09-21-2010 08:09 PM
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
09-21-2010 08:26 PM
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.
09-22-2010 12:11 PM
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.
09-22-2010 01:54 PM
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.
09-22-2010 03:19 PM
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.
09-22-2010 06:08 PM
it ended up being transfer rate limitations on the hardware side:(
09-24-2010 02:44 PM
So it was not a hardware limitation it was a constant that was out of place it is not working fine
Thanks
09-27-2010 10:04 AM
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!
09-28-2010 10:07 AM
Ben,
it was the Open/Create/Replace file.vi and the constant was connected to the operation function.
09-29-2010 08:56 AM
Harold,
Thanks for the info!