Images displayed in Labview do not stay synchronized across multiple frames

[adrian.spanu]

Hello,

I'm a little new of a poster, but a long time lurker. I'd like to thank everyone that answers here for all of the questions that I have previously read and from which I have learned so much.

I am creating an Labview FPGA based solution in Labview 12.0 32bit on Windows 7. I have a target FPGA module which captures data from an external apparatus, does some processing locally, and then uses a DMA FIFO to send this data to the host, one sample/pixel at a time.

The host takes this pixel data, does a little bit more processing to it and adds each row to a queue. This queue is then looked at, some more processing is done to the rows and they are combined together, finally resulting in a 2D array that is displayed using the 'intensity chart' indicator.

I have managed to get this running at around 10 fps, creating essentially a movie. The synchronization is done via a trigger signal sent from my external apparatus to the FPGA to keep both each row and each frame displaying correctly.

The problem has been that as I try to add a little bit more functionality to the host (specifically - I'm trying to send across 2 channels simultaneously from the FPGA by combining them into a U32, and so I need to pull that combination apart and translate it back into fixed point in an automatically indexed for loop, at which point I pass one of the channels through same processing as before before displaying just that one channel), I have seemed to hit some sort of wall of functionality in that my synchronization no longer works. That is, my image, instead of being properly centered, it is skewed so I see only half of each frame each time I display the image. Finally, when I move my mouse around, or scroll my front panel, or even hover over the start bar (and have the Windows 7 window previews pop up) or do pretty much anything else with the Windows UI, my frames start 'skipping' and they change where they overall in the horizontal and vertical direction.

This leads me to conclude that there is some resource that I am unaware of that is limited and that overflows whenever I do anything with the UI. This resource then overflows and drops some lines of pixels. When the program recovers, it goes back to displaying full frames, but by this point things are out of synch already, so I never return to a 'correct' image, although this is just a hypothesis.

Question:

Does anyone know if there is a hidden resource that Labview is using that would cause degradation of performance tied to UI changes in Windows or in Labview proper? If so, is there anything that I can do to increase this resource? If not, then is there another approach that I should be using for these type of high throughput requirements?

Thanks everyone!

Adrian

[Florian.Ludwig]

Hi,

there are some things to consider when performance is of the essence. Without seeing any code it's hard to comment however.

First thing that comes to mind from your description: Autoindexing can be hard on memory and it consumes time to because the memory manager is called each iteration. Maybe you can utilize previously initialized arrays in shift registers that you can then perform inplace operations on.

Could you give us more to work with?

Regards

Florian

[adrian.spanu]

Hi Florian,

Thanks for your response!

I can try that - thanks.

In terms of giving more, unfortunately, I am unable to post the actual code, or else I would have already. I will try to describe the problem as much as possible:

I am processing data points in the FPGA, then transferring to the host. At the host, I am combining the elements together into a 2D array, transposing them, and sending them back to the FPGA. On the FPGA side, I am again operating on each element, before transferring back to the host. Now that the final values are at the host, I am displaying them.

1. Is there a quick way to transpose a 2D array on the host? I assume that I will need to gather all of the elements together into a 2D array and then transpose it, before splitting it up again. Is that correct?

When I split it out again, is there a faster way to do it than to auto-index this array in a for loop and feed that into a DMA FIFO back to the FPGA?

2. My assumption is that the host cannot process things fast enough and that it is the cause of the dropped pixels. Is there a way to see where a buffer is dropping data during operation? Other than the 'timeout' states on the DMA FIFOs, is there a way to check on queues or other host constructs? Would this be purely through the queue 'get number of elements left' method?

3. My algorithm is reliant on a transpose, which is why I have a back and forth between the FPGA and the Host. Do you know of a good way to apply a transpose on an array purely in the FPGA? That would eliminate a round trips and thus reduce a lot of the load on the host.

Thanks for your help!

Best,

Adrian

[Florian.Ludwig]

Hi Adrian,

unfortunately I have no experience with FPGA whatsoever.

Transposing the data on the host should be quick because only rows become columns and vice versa - the array data is left alone.

Maybe the way to the 2D array (or back) is suboptimal. I don't know what can be fed into the FIFO though.

Regards

Florian

[adrian.spanu]

Hi Florian,

Not a problem - and thanks so much for staying up late (or so I assume?).

I thought that the transpose wouldn't be too difficult an operation, so I'm not sure why it appears to be giving me some grief. I will continue to tinker with it and see if I can get anywhere, especially in terms of tightening up the method of combining the array into 2D. I have now tried using the 'build array' module, which was very slow, and have instead opted for the 'Replace subset' module based on a pre-defined array. I have now seen multiple sources confirming that to be the quickest method.

Thanks again for all of your help!

Best,

Adrian

[Florian.Ludwig]

You're welcome.

Replace subset sound promising compared to build array.

I posted early this morning - I'm from Germany.

[adrian.spanu]

Thank you again from Korea!