"Failed to load shared library" error

[Tentotheminus9]

I know this is a pretty common error message when targeting an RT device, but my error is a bit different. I have no problem targeting my PXI-8186 device which has an IMAQ 1409 installed, and I also have no problem in running certain vi's such as grabbing images etc. However, if I try and run the example 'grab and save to avi' I get an error saying 'Failed to download IMAQ Avi close', followed by the "Failed to load shared library NIVision.dll" error. This also appears if I try and run any of the Vision examples. I've read all the other posts and have tried editing the ni-rt.ini file, and have reinstalled all of my software. I have NI IMAQ on my host PC and on the PXI box, but I only have IMAQ Vision on the host. When I got to 'install software' on the PXI box there is no option to install IMAQ Vision. Please help!

Cheers,

Rob.

[Stuart_R]

Sounds like some sort of driver issue on the target.

Could you post the versions of all of the NI software that you are using?

[gregstoll]

Tentotheminus9 -

I know you said you had problems with other Vision examples as well, but keep in mind that AVI functionality is not supported on RT devices.

Greg Stoll
IMAQ R & D
National Instruments

[HenryBryantBigelow]

snip...
but keep in mind that AVI functionality is not supported on RT devices
snip...

Whoa, say that again? Does that include the CVS 1450 as a RT target?

I am having the same problem with uploading the AVI Close to a RT target (CVS 1450). This system is LabView 7.1, IMAQ for 1394 2.0, and Vision 7.1. When we purchased this we were advised that AVI would be the file format of choice for streaming images to disk.

Any suggestions?

Thanks, Ben

[Brent_R]

Ben,

The IMAQ Vision AVI functions require Directshow and thus are only compatible with Windows platforms. The standard IMAQ Vision file I/O options such as BMP, TIFF, JPG, PNG, are compatible with LabVIEW RT and should be used for writing images on the CVS. In many cases you will see equivalent throughput writing individual image files as writing AVI files. The only significant penalty is the large number of files to manage.

Regards,
Brent

[BruceAmmons]

Another possibility which could get your speed up is to use the same utility that is used for compressing images for sending over a network, and streaming it to disk instead. Basically, for each image the routine returns a string which is the equivalent of a JPEG image file. You can store these strings in a single file, which reduces the file IO time in Windows. I don't know if it would reduce the time in RT, but it would reduce the number of files. You can even post process the single file and split it into all the individual JPEG files if you want. All you have to do is read each string and write it to a separate file.

Bruce

[HenryBryantBigelow]

Thanks Brent and Bruce,

It is dissapointing to learn about the AVI limitations, but I am glad that we have other options to pursue. We have found that simply streaming 1600x1200 8bit images (in lossless format) to a firewire disk hanging on the CVS that we can achieve 3 frames per second. If we store the same images to a lossy format we see a performance drop to about 1 or 2 frames per second. Of the standard IMAQ formats we have seen the AIPD (NI proprietary format) is the fastest. We get a little bit more speed if we simply open a file once and write raw images data to it in the ring. I'm not familiar with the network compression protocol but will certainly investigate it - thanks for that tip.

Our situation is complicated (at least we think so) in that the ultimate analysis task to segment, extract and automatically classify marine particles. For classification, the devil is in the details (literally) so we want to retain the highest resolution possible. That requirement must be balanced against the requirement to sample meaningful (i.e. big) volume of water.

There is another issue involved which I confess I don't understand clearly, and perhaps it is off-topic. IMAQ online help has a couple of ring acquisition examples - but none for the IAMQ 1394. Happily I found an recent example provided by Steffan Hoog (you can find it at http://tinyurl.com/6j2vt). If have attached a modified (and simplified) example. In the modified example, the two rings always take about the same amount of time. For our setup, we can acquire the images and make the histograph at 133 mS. If an IMAQ Write Image is introduced in the bottom ring the time increases to 300+/- mS for *each* ring. Why is that? I suspect that I am mistaking parallel while loops for independent thready-kinds of things.

Thanks again,
Ben

[Brent_R]

These are in the same ballpark at the writing rates (~5.5MB/s) I've seen on the CVS with a 1394 HD. The file writing throughput is dependent on the image size. For smaller images (eg. 640x480x8bpp) I have observed about 3MB/s. As the image size gets larger, the writing rate seems to asymptotically approach about 7MB/s for images of 5-10MB. You can achieve higher writing rates with small images by tiling multiple acquired images into one larger buffer and writing the large image. For example, I was able to acquire images at 640x480, tile 20 of them into a large buffer (640x9600), and write them off at about 7MB/s (with no other operations). The tiling operation (using IMAQ Copy) is quite fast, but you will need to run some tests to see if it makes sense for your application.

I believe the change in your loop rates are related to the way the RTOS handles threading, but I really couldn't tell you much beyond that. Perhaps someone on the RT forum could explain it better. I did have two quick comments about the code. The number of buffers is set to 10. This is probably excessive. Also, with 1394 v2.0, occurrences are no longer required (or even recommended)

Regards,
Brent

[HenryBryantBigelow]

Thanks for sharing yours thoughts and suggestions.
Cheers,
Ben