not saving at required frame rate

[dispossessed]

Hi,

I want to save images directly to the hard disk during acquisition at a frame rate of 30fps. Although, this is a reasonable, not very high frame rate, im not achieving the frame rate im asking for. The maximum that i can get is about 14fps for 582x782, 10-bit images and an Ultra-320 15K RPM SCSI hard drive(which is empty; the OS is on another HD). According to my calculations, i should be able to easily save frames at 30fps, as all i am requiring is 17MB/sec, even if we assume that the bus speed is slow.

I am sure that there is something wrong going on. Could anyone please give me some advise or suggestions as how to fix this?

Using: Cohu 7700 Camera Link

PCI-1428

Labview 8.5.1

Thanks.

[crelf]

QUOTE (dispossessed @ Jul 2 2008, 08:33 PM)

I am sure that there is something wrong going on.

Show us your code.

[dispossessed]

QUOTE (crelf @ Jul 2 2008, 08:30 PM)

Show us your code.

I attached it. dont worry about the name of the vi; i started out with the LLRing vi but then modified it.

[crelf]

Firstly, you're doing all your timing in software - the card you're using has 16Mb of onboard RAM to buffer the image data in hardware - use that and then only get it all out when you need too. Also, how long does the conversion to TUFF take? You probably don't need to do that in the acquisition loop.

[dispossessed]

QUOTE (crelf @ Jul 2 2008, 09:14 PM)

Firstly, you're doing all your timing in software - the card you're using has 16Mb of onboard RAM to buffer the image data in hardware - use that and then only get it all out when you need too. Also, how long does the conversion to TUFF take? You probably don't need to do that in the acquisition loop.

yes, but 16MB is not enough space for my pictures. i need to acquire images for long times (scale of minutes. not less than 8min). and i need to save them in a certain file format, right? unless there is a way to save the RAW image directly. i know that TIFF is simplest kind of lossless format so it shouldnt take too much time. i could use JPEG which probably is faster, but i would lose information by doing that.

[LAVA 1.0 Content]

It's ok to cross-post to other forums but please mention it

Last I made an application LV8.20 that saves up to 50fps for 10minutes the flowrate was close to 120Mo/s with RAID0 system.

17Mo/s on a fast HD should really be fine, as Crelf said, show your code and it will be easier to help you.

What I did for my application is 2 loops running in parallel, one extracting images as they are ready and copy them into a queue, the second loop keeps dequeueing and saving to disk as fast as possible. To see it the systems goes fast enough, graph the "elements in queue" to make sure it does not incease too much.

Hope this helps

[dispossessed]

QUOTE (Antoine @ Jul 3 2008, 02:28 AM)

It's ok to http://forums.ni.com/ni/board/message?board.id=170&thread.id=337265' target="_blank">cross-post to other forums but please mention it

Last I made an application LV8.20 that saves up to 50fps for 10minutes the flowrate was close to 120Mo/s with RAID0 system.

17Mo/s on a fast HD should really be fine, as Crelf said, show your code and it will be easier to help you.

What I did for my application is 2 loops running in parallel, one extracting images as they are ready and copy them into a queue, the second loop keeps dequeueing and saving to disk as fast as possible. To see it the systems goes fast enough, graph the "elements in queue" to make sure it does not incease too much.

Hope this helps

i already posted the code above. please take a look at it and hopefully you might spot a glitch

by queing, you mean indexing the tunnel at the loop exit? if so, ive tried something similar, but still no success.

Thanks.

[LAVA 1.0 Content]

QUOTE (dispossessed @ Jul 3 2008, 09:36 AM)

i already posted the code above.

Woops... sorry I missed it... I'll take a look

[LAVA 1.0 Content]

There we are, I couldn't test it because I don't have the hardware available at the moment, but I think with this base you have a good chance to make it work.

Hope this helps

[dispossessed]

QUOTE (Antoine @ Jul 3 2008, 04:24 AM)

There we are, I couldn't test it because I don't have the hardware available at the moment, but I think with this base you have a good chance to make it work.

Hope this helps

Thanks a lot. i will try it today and inform you if it works or not. i hope it does! and thanks for the links above.

[dispossessed]

Antoine,

I tried your vi, but still no luck. i couldnt get more than 11fps. however, i did a speed test to my HD and found out that it is runing at a speed of 32MB/sec. this is much less than what is supposed to be doing (320MB/sec), but it should still be enough for my requirements.

[LAVA 1.0 Content]

QUOTE (dispossessed @ Jul 5 2008, 01:32 AM)

Antoine,

I tried your vi, but still no luck. i couldnt get more than 11fps. however, i did a speed test to my HD and found out that it is runing at a speed of 32MB/sec. this is much less than what is supposed to be doing (320MB/sec), but it should still be enough for my requirements.

Hi,

One Thing I just realize.. if you want a particular number of fps, I would recommend to trigger the camera, I think this is the best way to do since you know how fast the images are taken by the camera and then you just have to make sure you go fast enough to extract and save them to HD.

Can you try to find a trigger source ?

Second thing, I checked the camera specs, it appears that in 10bits config the max frame rate is 15fps and in 8bits config the max frame rate is 30fps.

So...

Also, as I said I couldn't test it because I don't have hardware at the moment. But with the same architecture I had very good results.

There are a few things that can be improved in the code I posted, first, to find the bottle neck, here is what I would do :

- check that the "extract loop" gets all the images, by placing an http://decibel.ni.com/content/docs/DOC-1106' target="_blank">history probe on the "buffer extracted" wire, if this is not continuous, increase the number of buffer you allocate for image acquisition.

- once you're sure that all the buffer are extracted at the rate you need, graph the Q size to make sure it doesn't no kep increasing... if it does, it means your HD is not fast enough (which I really doubt in your case, seeing the figures you gave :-o)

ps: here is the main VI with slight change to graph continuously the Q size.

Hope this helps