How to check Windows timing in Labview

[bjorn1985]

Hello everyone,

I am currently working on a project to measure reaction time. The time has to be measured in ms, and I need to know when the display actually displays my information. As the display is a standard monitor, I expect it to be 50 hz. This means the measurement could be as much as 20ms off. How can I check in Labview 8 when Windows displays my information on the monitor?

Yours truly,

Bjorn van Steenbergen

[smercurio_fc]

That's not something you can directly do in LabVIEW, or any other language for that matter. You're talking about knowing something that occurs outside of the control of the application. The closest you could come is knowing when the video card has sent out the information on its output port, if that's even possible. Even then you have to take into account the fact that there's going to be a certain amount of time for the monitor's electronics to process the signal and update its display. This information isn't directly accessible as far as I know. I think your best bet is to look into using a camera that monitors the screen so it can detect when the image has been physically updated on the monitor. You would need to take into account the response time of the camera, but this should be, more or less, a known delay.

[Conseils]

You could connect two (nominally identicle, cables etc...) monitors to the display output.

Arrange to have a light sensor fixed by sticky tack to the screen, feed this sensor signal back to a LabVIEW digital input on a timer card.

When you send data / image to the screen set the counter running. Now you can measure the delay between sending the data and when it actually appears because when the display changes in a specific way the sensor could stop the timer. You might have to adjust the colours etc. for best response. You will need to use a card with a timer on it for high precision timer counting. You can then do this during your test sequence without interfering with the test, because your measurement is occuring on a seperate monitor.


This will also allow you to handle the variability of the operating system performing other tasks and take it into account for your measurements of rection time.

Hope this help solve your problem

[bjorn1985]

My problem has been solved.

I used Active-X controls to access DirectDraw for the GetVerticalBlankStatus. So now, I can measure the time between when Labview sends the output and when the monitor is refreshed. The only problem I face now is to get the input devices to millisecond accuracy. The PS/2 ports are refreshed every 16ms so now I'm trying the USB inputs. I welcome any other ideas .

[Conseils]

What is the "DirectDraw - GetVerticalBlankStatus" giving you and to what resolution?

[bjorn1985]

GetVerticalBlankStatus gives a "1" whenever there is a vertical blank, otherwise a "0". The resolution is 1ms. The problem is, that I dont get all the Vertical Blanks when Labview is slower than 1ms. However, with the timed loop it's working fine.

[Conseils]

Presumably then you could detect the error condition and use GetScanLine to work out the timing if you missed one of the GetVerticalBlankStatus events?

I have always used the parallel port fairly directly with the PortIn and PortOut commands for parallel port access so I can't help much with the timing. I thought that it was better than your indicated rate though.

[bjorn1985]

I am now using WaitForVerticalBlank in a seperate VI. The main VI runs the timing VI and communicates via a global variable VI. When the timing VI runs, it first saves the start time. Then, it waits for a vertical blank and saves the stop time. To check the timing, the VI reads the current line. When the line is not either 0 or 768, depending on the vertical blank mode (begin or end event), the timing VI calculates the error in timing and corrects the stop time.

Now, can I assume that my picture is put on the monitor the very first vertical blank? Or is a delay over 16ms (on 60Hz) reasonable? Sometimes the VI returns a delay over 16ms, which is corrected.