Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

Graph data to UI thread from acquisition thread

Hello,

 

I am very new to measurement studio (started using it 3 days ago, along with c#...but have a few years experience with LabWindows/CVI) and I know this type of question has probably been beaten to a pulp in one manor or another, but I cannot seem to find an example in the measurement studio libraries, or an example from the forums, that can connect all of the pieces together.

 

I am attempting to make a very bare-bones "oscilloscope-like" program that can alter graph resolution while sampling several channels continuously from a couple analog inputs (2x pxie 4300s, 1x pxie 6358).  I've been able to create a thread from a win form button, setup my instruments properly, configure some asynchronous callbacks every n samples read, and properly receive the data across channels.

 

I've now been beating my head into a wall trying to figure out the proper method for getting the data to the UI thread, efficiently.  After exploring a lot of options, i "think" the right approach is to make a ConcurrentQueue on the UI thread, and have the acquisition thread write to the queue each asynchronous callback, with some type of thread lock.  Then, create some type of synchronous callback on the UI thread that can take the data and plot it continuously to several waveform graphs (I may add a processing thread(s) later to clean up some of the data /simplify things for the UI thread in the future).

 

My questions are:

  1. Is this a decent first attempt approach at trying to simply read data on one thread, and graph data on the UI thread?
  2. If so, I've been able to make the concurrent queue and write to it, but I am unsure of properly reading it on the UI thread.  I've attempted making a System.Action that reads the queue on the UI thread...but if it runs in a loop, it will obviously lock up the UI/UI thread, so maybe the System.Action, in conjunction with a synchronous callback, would do ok?
  3. If this approach above is not ideal or there may be better/cleaner options, what are some other plans I should consider?

I've been mostly looking at the ContAcq examples in "\National Instruments\NI-DAQ\Examples\DotNET4.5.1\Analog In\Measure Voltage", along with "\National Instruments\MStudioVS2013\DotNET\Examples\DAQmxWithUI".  These examples have been very helpful in learning, but again, I can't seem to find something that connects everything together in a multi-threaded application (unless I am missing something/not looking at the right examples/forum posts?).

 

Any suggestions would be greatly appreciate,

Thanks

0 Kudos
Message 1 of 2
(2,398 Views)

Hello,

 

 Is this a decent first attempt approach at trying to simply read data on one thread, and graph data on the UI thread?

 

Yes, I'm using it all the time (but not with measurement studio)

 

 > If so, I've been able to make the concurrent queue and write to it, but I am unsure of properly reading it on the UI thread.  I've attempted making a System.Action that reads the queue on the UI thread...but if it runs in a loop, it will obviously lock up the UI/UI thread, so maybe the System.Action, in conjunction with a synchronous callback, would do ok?

 

I'm using synchronous callbacks only (and yes, with System.Action to create the delegate to pass on to Invoke), but concurrent queue is an option too, it all depends on the logic of the main app running on GUI.  If timing is not critical you can use a timer to periodically check the concurrent queue otherwise synchronous callbacks will be more efficient. And with synchronous callbacks you can still set up a queue if needed, with a one-line callback function just appending the data object to the queue.  My advice is to invest in learning  GUI-synchronized callbacks anyway.

IMHO you won't learn much about threading from NI examples. To understand threading in .NET  I would rather recommend this excellent reference:

http://www.albahari.com/threading/

Note that to synchronize a callback on the GUI thread you need a proper synchronization context, and this depends on the GUI you are using.  In WinForms check the  InvokeRequired  property.  In WPF the synchronization context is provided by a Dispatcher object created on the GUI thread.

 

 

0 Kudos
Message 2 of 2
(2,282 Views)