回复： How to avoid long user interface response time in long measurements ?

[Petri]

Hi

I tried to find more information regarding techniques how to avoid long user interface response times in case of extremely long measurement times with an external instrument communicating over GPIB, so I post this hoping to get some hint or a link to a guideline. I guess this is quite normal problem.

Problem is that when I want to measure long time in order to get an average result from the instrument, I have to wait until the result is returned from the instrument. Obviously that makes the user interface response very slow in traditional technique. 

My restriction is the old GPIB 488 instrument driver that I would not want to modify, but I have source code to it.

What would be the best way to improve the response time for user interface ? I have looked into the few things:

* multithreading

* callback in main program for GPIB events

* modifying instrument driver e.g. to support VISA and creating a VISA callback

regards,

Petri

[menchar]

Several ways to do this:

If you're getting several measurements, you could have the instrument generate an asynchronous interrupt (an "SRQ" in GPIB terms), then collect the data in response to the SRQ callback.  While you're waiting for the SRQ's, you can have your main thread running the interface so responsive GUI.  You don't have to spinlock on the GPIB read waiting for instrument data.

Or, as you mentioned, you could spawn a thread to manage the measurements, and use a timer in the main thread to periodically allow you to check the status of the measurement thread.  Again, the main thread mostly just runs the user interface.

Either way, the idea is to keep the main thread freed up most of the time to run the GUI, and have it periodically check for completion of your measurement sequence.  While you're waiting in the main thread, you may want to make sure the user can't inadvertently re-trigger another measurement sequence until the active one is complete.

If you do find yourself doing a dead wait, you'd want to break this up into a series of shorter waits, and in between each wait, do a ProcessSystemEvents from the main thread to keep the GUI active.

Menchar

[Gerryli]

hi,

if you measurement and analysis takes long time i suggest you use multithreading. however, be careful for exchanging data between you UI and measurement part.

Hope can help !

Gerry

[Petri]

hi,

Thanks for response.

I took a look to the multithreading and would guess that once learned how to program it in CVI it is more future proof solution for single-threaded instrument drivers.

Unfortunately NI papers I found are referring to old v5.0 CVI in multithreading information. Fortunately some examples seems to follow with recent CVI.

regards,

Petri