James

Here are all the files for D Download File:post-1372-1106509520.zip

I have done a similar thing, only I stamped the time and five readings. see the code at http://forums.lavausergroup.org/index.php?showtopic=1060&hl= The basic idea I used was to count miliseconds and insert that into the array of other readings before writing to a file. Good luck James

Randy, AWESOME!!! You are amazing! :worship: I thought I was getting fantastic resolution when in fact I was skipping time and getting rubbish. Now I realise that 200-250Hz is about the limit because of the mike-drive control. Thank you for your time, patience and wisedom. James.

It does it for me all right!! I have changed the code and run the program with the little lightbulb on to see how things are running... I can see that each cycle of the loop does everything once and therefore the time for sampling, updating motor and writing to file is all contained within the loop. However, the output shows timestamps being the same and then jumping up to 16ms (I originally thought the jump was 1 - hence the need for greater resolution). I have attached the VI and output for clarification. Thanks James Download File:post-1372-1106106723.vi Download File:post-1372-1106106725.txt

Do you mena that because I've set the sample rate to be 200Hz, every sample will be at 1/200s? I would have thought so too, but when I had the rate at 100Hz and timestamped my output file using the tick-counter, I found uneven steps at the millisecond resolution of the counter. I rationalised this by the fact that the acquisition, feedback system, mike drive commands and file writing takes time. That is why I put the writing of data to the file all in one place (so it would get written at the same time). But because I'm using the tick-counter and a sampling rate where I write samples faster than a millisecond apart, it is difficult to know the exact (relative) time each sample was taken / written... So I want to replace the millisecond (tick counter) timer with a sub-millisecond one... I have tried to increase the sampling rate of the AI but the buffer fills up causing the system to slow down and stop! Hope we don't confuse eachother too much Thank you muchly!!! James

Randy, That makes sense... BUT if I have the AI, control system and motor control in the same loop then there is a significant delay before the motor responds to the force change. I am aiming for (and have achieved) a response time of less than 1s. But because of the timing inconsistance, the timestamp stamps more than one entry with the same millisecond count, sometimes three, sometimes for or five. Thus it is hard to know exactly what the timestamp is. Also the plotting on a waveform chart takes significant time and by removing it I can at least double my sampling rate... I can plot the results in excel after the data gathering Thanks so much, James

Thanks guys. But I am now a bit more confused... I'm not sure what the difference between LV and RT is? - I'm using standard Labview 6.1?? I have used the LV "AI config", "AI Start" and "AI Read" for acquiring the analogue force measurements and written some custom VI's to interact with the digital mike drive. I have attached the main VI (not including the digital ones for size reasons). Thank you so much forr your help!!! James Download File:post-1372-1105912480.vi

I have written a Labview program in 6.1 to control a force-displacement setup in order to measure material properties of muscle. I have refined the algorithm to sample at a rate >100Hz and I want each sample to have a timestamp so I can accurately plot the data. At the moment I'm using the "tick count" feature but that only incriments in milliseconds - too slow for me. I have looked at the "Get attributes" in the "Counter" vi's but cant seem to get them to work. I'm using a Lab-PC+ analogue card to capture the force data and another NI digital IO card to control the mike-drive. If there are any suggestions as to how I can stamp each sample I'd love you forever! Cheers.