LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Not able to save all the data to a text file in the vi running at 1 kHz

Solved!
Go to solution

Are you sure your producer is creating values that fast? I don't know what function you're using to acquire data.

 

Try swapping to either a constant or a random number or something you know is fast (no hardware IO) and see if that speeds it up.

 

With 100 elements per write you're saying you can only write to the file 4 times per second, which seems low to me. Then again if you're running a desktop window manager and a bunch of other stuff on the Pi you might not have enough oomph to do it. Still, I'd guess you can get faster than you are seeing.

 

One other way to tell- when you click Stop, does your system immediately stop? If so, then your producer is the limiting factor, not the consumer. If the producer was generating data at 1 kHz and your consumer was consuming it at 400 Hz, you'd have 600 data points per second getting buffered in the queue. After running for, say, 5 seconds, you'd have an extra 3000 data points queued. When you hit Stop, you'd quit generating new data, but the queue would continue to run until it empties, taking an extra 7.5 seconds to continue writing to the file.

Message 11 of 14
(532 Views)

It could definitely be a hardware issue. Try using a fast SD card or a fast USB drive on the Pi and see if that improves performance. Many cheap SD cards and USB drives have very slow write speeds.

 

Additionally, you might consider checking out Jeff K's Channel Wires. They bundle some of the often used features (like a stop message) into the native queue and can simplify your VI. Check out the attached snippet.

 

Charles

0 Kudos
Message 12 of 14
(523 Views)

@BertMcMahan wrote:

With 100 elements per write you're saying you can only write to the file 4 times per second, which seems low to me. Then again if you're running a desktop window manager and a bunch of other stuff on the Pi you might not have enough oomph to do it. Still, I'd guess you can get faster than you are seeing.

 

One other way to tell- when you click Stop, does your system immediately stop? If so, then your producer is the limiting factor, not the consumer. If the producer was generating data at 1 kHz and your consumer was consuming it at 400 Hz, you'd have 600 data points per second getting buffered in the queue. 


I was reading about I2C on raspberry pi and it says that bit rate is limited to 100 kHz (100 kbit/sec). I am trying to read 6 bytes or 48 bits (x,y,z acceleration) of data and each byte needs 9 clock signal. So we get around 462 S/s, which is close to what I am getting. Theoretically I should be able to increase I2C speed to 400 kHz but apparently due to some production error it is not possible on the raspberry pi model 3. 

 

The thing I don't understand is that read sub vi is not just reading acceleration data but also gyroscope and temperature (in total it is 13 bytes) so Sample/seconds should be even lesser. 

 

With 100 elements per write you're saying you can only write to the file 4 times per second, which seems low to me. Then again if you're running a desktop window manager and a bunch of other stuff on the Pi you might not have enough oomph to do it. Still, I'd guess you can get faster than you are seeing.

 

One other way to tell- when you click Stop, does your system immediately stop? If so, then your producer is the limiting factor, not the consumer. If the producer was generating data at 1 kHz and your consumer was consuming it at 400 Hz, you'd have 600 data points per second getting buffered in the queue. After running for, say, 5 seconds, you'd have an extra 3000 data points queued. When you hit Stop, you'd quit generating new data, but the queue would continue to run until it empties, taking an extra 7.5 seconds to continue writing to the file.


No, pi is running in headless mode and there is nothing else on pi. 

 

System stop immediately when I press stop. If I add a time delay just before while loop stop condition, maybe it gives enough time to write the data in the queue?

0 Kudos
Message 13 of 14
(511 Views)

If it stops right away then your consumer is consuming data (i.e., writing to file) as fast as the producer is letting it. Your producer isn't generating data at 1000 Hz. It's producing data at 400 Hz, and the write loop is writing it just as fast as it comes in.

0 Kudos
Message 14 of 14
(498 Views)