IMAQdx image acquisition slow when using remote desktop

[MichaelWestwood]

Hi,

I'm writing an app that acquires and records from 3 x GigE cameras using IMAQdx for a mobile surveillance type application. I would like this app to run on an embedded machine with no UI and I'd like to use remote desktop to configure and monitor it. It is desirable that an operator can verify during recording that the images appear ok, but not that they are displayed at full frame rate. I had envisioned using a tablet with remote desktop client or laptop.

I find that when I connect with remote desktop the image acqusition slows down dramatically even though the processor does not appear to be working too hard (its a quad core i7 and the max load reported on any processor is 20%) . Each acquisitiion runs in its own thread and is event driven and each camera is connected to a seperate NIC as is the remote desktop connection . I find that if I don't display the images, the acquisition rate is much better .

Any advice would be greatly appreciated in terms of sorting this problem out or recommendation of an better method of creating a remote user interface on an android tablet and laptop.

My setup is:

64 bit Windows 7 embedded

Labview 2013

IMAQdx device driver 9.8

IMAQdx 4.3.5

NI Vision 2012

Neousys 3100 fanless PC

Intel i7 2.3GHz

4G RAM 

Thanks,

Mike

[BlueCheese]

What do you mean by "event driven"? Doing things in event loops occupies the UI thread and this thread might slow down due to latencies over Remote Desktop. You should also check if your image display controls are in snapshot mode, as having this enabled will cause he display to block as it updates over the network. You probably would be better off making a separate VI that connects over shared variables or VI server to your remote system.

[MichaelWestwood]

Hi,

My solution has been to use VNC which does not have the same problem. 

I am however, very interested in what the best architecture for this type of system would be.

By event driven I mean that each acquisition is in a separate thread (while loop) which contains an event structure which waits for an acquisition event. This seemed the most efficient architecture since these loops are using no processing power between acquisition events, is this incorrect?

I then have another UI loop which displays the images and also writes them to disk. My thoughts on a single loop wiriting to disk was that it eliminates the possibile conflict of multiple loops trying to write at the same time. I'm not sure if this is a valid argument.

Any input would be greatly appreciated.

Thanks,

Mike

[MichaelWestwood]

Incidentally, I found that the embedded machine which was shipped with win7 embedded had its power profile set to "balanced". I changed it to "high performance" and all my problems went away. It uses a lot more power of course, but it seems strange that by default a machine would be set to perform at well below its possible capabilities. I had a similar problem on a different system and a  rough benchmark indicated that the image processing was about twice as fast on "High performance" as apposed to "Balanced"