Picture-refreshing frequency issue

[Chudy]

Hello,

I got this problem: I display 3 different pictures in a sequence. Whole sequence last 1 second (0,3333 per picture) and is repeated continuously. While doing this, I've got some displaying issues - some white flahes occours on the pictures. This is easily visible, as pictures have black background. Those flashes appear as white stripes or fields oriented horizontally in different part of picture. I think this is some refreshing issue, but I'm not sure about it and don't know how to check it. I did not succeed at making print screen of those flashes, which I think confirm this is some displaying issue. I want to know what You guys think about it, if can it be solved, is this my hardware issue or some kind of LabVIEW limitation. I've checked it on 3 different displays (my laptop screen, my PC LCD screen, projector) with 50-60Hz refresh frequency and results were the same. I've tried with different picture resolutions and I think these flashes are more common in bigger pictures.

I attach all VI I use to display those images and some reference pictures for You to check if You too got this issue.

Few words about how this VIs work:

There are 2 VIs - controling one and displaying one. I need it this way as I want to have pictures displayed on second monitor while being able to adjust them from front panel on 1st monitor. So there is this Displaying VI which only displays images, and Controling VI which sets all parameters. To get it work, You need to open Displaying VI and make it run. Then You open either ControlingPredefine or ControlingGenerated, set:

Interval value (time between changing pictures, 333 is my case),

VI path (this should be path of Displaying VI)

monitor (0 - main screen, 1 - second screen if You have. I made it this way as I've been checking it with different monitor configurations (laptop only vs laptop + projector))

and run it. When set correctly Displaying Vi should be fullscreened on monitor set in monitor control and display 3 pictures in Interval

There are 2 Controling VIs:

Predefined works on existing jpg pictures chosen from hard drive (there are 3 additional path controls which need to be set before running)

Generated generates pictures in the real time, you can chose between 2 figures (circle/square) and set 3 sizes (each for each picture in sequence)

Stop button from Controling Vi stops both VIs (Controling and Displaying).

I attach 2 sets of pictures (small and big) made in paint.

My LabVIEW version is 2011

[johnsold]

I cannot run the ControlingGenerated VI because some of the subVIs are missing.

If I run the Displaying VI first, It runs full screen and I cannot get to the Controlling VI to run it.

I added a Run VI invoke node to the Controling VI to start the Displaying VI so it is not necessary to start it manually. I also put a Wait (ms) function inside the while loops in each V so they do not try to run as fast as possible and so that they share CPU resources better. I also added a Close Reference after the while loop in the Controling VI.

I never saw flashes you report.  They may be from running the VIs much faster than the screen refresh rate. Or they may be due to different OSes.  I tested this on my Mac.

Using a set of photographs for images pushed the memory allocation to about 900 MB and made the program excruciatingly slow.

Lynn

[Chudy]

Thanks for Your feedback Lynn, I will try to reproduce Your suggestions now. If You could provide some screenshots with those additions it would be perfect.

I think i will manage to reproduce those, but want to be sure if all is done right way, I'm new to LabVIEW, that's why i wanna see how others get along with problems.

I thought that Interval will be enough, but yeah, I've forgoten about second VI, it doesn't have any delay in it. This might be a good place to start. Non-closed reference can lower my performance too? Resources Managment is a black magic to me. It's not my intention to display more than white figures on black background in reasonable resolutions, thou.

My orignal project includes communication with Arduino Board, so whole displaying process is synchronized with readings from Serial Port (which in practice means I will get new picture every 1/3 second). I made simple versions of Controling VIs without serial read implemented, to post it here on forums. I'm writing this to highlight that those waiting times before each loop iterations can't be long, so all data from serial port is read.

The fullscreen (without toolbars etc.) of Displaying VI is intentional - in the long run I want it to display picture and only picture on second monitor. With dual monitor this is not an issue, when working with 1 monitor I bypass this by alt+tab or Windows button, which shows me bottom windows toolbar. I think there is something similar in Mac. I'm working on Windows7

I attached all needed SubVIs, please check again the ControledGenerated VI as I think it is more memory-needing.

[johnsold]

I do not have the time to dig into ControledGenerated tonight.  Here are screenshots of the changes to ControlingPredefined.

The Ctrl Val.Set sets the Loop Terminator to False so that Displaying.vi does not stop immediately the second time it runs.  Then the Run VI Invoke Node starts it running.

This shows the Close Reference and the Wait (ms) functions.  A simple rule for closing references is that if you opened it explicitly (as by Open), then close it.

Invoke and Property nodes can be slow, so often it is best to only write to them when something changes.  Writing Loop Terminator only when stop is True is one example.  Similarly, if all the images are the same size, only write to Final Picture: DrawAreaSize once.

It is fine to set up your VI for fullscreen and so on, but it is courteous when posting to the Forum to avoid things which can complicate life for those trying to help you.  VIs which run when opened and which have the Abort button removed are also settings which are often used on the deployed VIs or applications but which can be problematic in a troubleshooting environment.

Lynn

Lynn

[Chudy]

Thank You for Your suggestions Lynn, I have to learn a lot about LabVIEW.

I have implemented all Your suggestions - closed the reference, took what I could outside the while loop (invoke nodes), added Run VI node. Sadly, I've spotted little improvement only when using low resolution jpeg pictures (those 0a-0c). With bigger ones and generated in real time (Generated VI) flashes are probably still the same, or maybe slightly less common, but this can my my subjective opinion. I don't know if this is important and if this isn't me being blind, but I got the impression that when testing on dual monitor, those flashes appeared in different moments and time intervals on every monitor.

I've implemented wait function. I can't say if it make things better, but i cannot go above 100-150 ms as I start losing readings from serial port (as I mentioned, there is also serial reading part in the while loop in my final version, I can share it here if needed). I've implemented all the changes in VIs I had posted here and VIs I work on (with serial reading) - results are the same, I keep getting those flashes, so I think serial reading doesn't influence the VIs performance so much.

I will try and take as much as possible outside of the while loop (but I'm afraid there is not much to do) or try to recreate my algorithm, so it does the same thing but works in some other way, maybe my current code is just overloading my laptop.

I would like to apologise for providing misleading VI (fullscreened without Abort Button) but I wanted to reproduce as close as possible circumstances in which my VI should work. But yeah, Your right, this didn't help You at all, I will try no to make such mistakes again. I removed serial reading part and thought that's enough.

I can make a video showing those flashes on my monitor if needed. I have to correcto some information - I'm working on Windows XP, I got XP on my laptop where I work with LV and W7 on my pc, so somtimes I provide wrong OS.

P.S. all the VIs I had attached in previous post should be in same localisation as Controling and Displaying VI (if this matter)

Chudy

[johnsold]

Chudy,

I looked at the ControlingGenerated VI and do not see the flashes.  I did add the Run VI node and similar changes.  I tried it with your original Displaying VI and with one I modified to include a delay.  When I set both delays to zero or very small values, it appears that the two images can get out of sync.  I suspect that this is due to the screen update rate by the OS and not specifically something in the VI.

It really does not make any sense to update faster than the OS will write to the screens.  The excess data will be ignored.

Similarly, you should separate the communications with the serial port from the screen updates.  Look at the Producer/Consumer Design Patterns which come with LV.  Read the serial port in a parallel loop which is dedicated to just that task. Typically queues are used to pass data from one loop to the other.

Here is a version I modified to use a queue and to call Displaying as a subVI rather than via an Invoke node.  Notice that the Displaying VI no longer uses the Loop Terminator and that the timing is set by the Dequeue wait.  The Displaying loop will run the same number of times and at the same average rate as the main loop.

Lynn

[Chudy]

I downloaded Your VIs Lynn, run them and still got the flashes. Luckily, with higher waiting times those flashes were less common and appeared more like a horizontal wide line coming from the bottom of the screen to the top (rather than very wide line, or even spacial flashes) which makes me think this is more of an issue with my hardware configuration rather than VIs optimalization. I even tried with huge waitng times (1 second and more) and got the following results: while being displayed images were perfectly ok (this is 100% expected), and after the change to another image occur, there can be caught a glimpse of this horizontal line (as in those flashes). I don't know if I understand it right, but it seems to me as the VI is totally ok and only my laptop have problems with displaying those pictures at once. This would be really odd, as these are just black backgrounds with white circles on it, nothing memory consuming I think.

After writing this post I will start implementing the changes (queue, producer/consumer etc.) to my VIs, but I will have to do some massive reading and learning before, as this are new thing to me.

I will try to run those VIs on other machines to check if same problems occur. This will maybe confirm "my flawed hardware" theory.

Besides this I would like to thank You for showing me how this project could be done in better way.

Chudy

[Chudy]

Sorry for double post, didn't make it on time to edit the previous post.

I would like to discuss the time between loops. I understand this is wrong to refresh pictures faster than OS refresh rate, but still, with 60Hz screen refresh rate set in screen settings, 16,6 ms between loop iterations (or multiply of that) should be ok, am I right?

[johnsold]

Chudy,

I agree that the flashes may be a combination of OS and display hardware.

I have not used the image generation VIs much.  One thing you might try is to use a shift register to pass the same picture from iteration to iteration of the loop. Then ratther than writing an entirely new image each time, leave the background the same and just overwrite the circles.  I think you might need to write two circles - one black one in the old size to remove the old white circle and then a white one in the new size.  Some experimentation may be required.  Also read the detailed help files for the picture control and the image generation VIs.

There is a lot to learn. You will find that having learned effective techniques like producer/consumer will save you a lot of time and frustration in the future.

Lynn

[GuenterMueller · Accepted solution]

Hi Chudy.

Can you please turn off the picture property "Erase First"?  As long as this option is set, the picture will erase each time you write a value to the picture.