graph update speed

[rmaletsky]

Hi all,

I am attempting to collect information from a joystick in one loop and periodically dispay the position (with a target) on an X,Y graph in another loop. I have tried to use the suggestions in other threads incoporating queues and is seems the problem I am having is not with this method. When I run the program without the graph (all the code, just delete the graph) it runs at the speeds I expect (data points are ~1-2ms apart). When I run the code with the graph there, the time between data points increases to 20 - 30 ms periodically. It appears to be when the graph updates. I was under the impression that running in seperate loops should prevent the graph update from interfering with the collection of points. Am I implementing this method incorrectly? Does the graph update always cause this delay no matter what method is used? I understand there are some optimizations I can do with me video card to help and have tried a few, but nothing that reduces the problem significantly. Any suggestions will be appreciated!

I have attached a much cut down version of the program which just demostrates the main loop code , but isn't executable. I hope this makes the question clearer.

Thanks,
Rebecca

[tst]

Just to make sure I understand you correctly - When you have the graph in the upper while loop, your lower while loop runs slower? If so, I think the problem is that updating the screen takes its toll on the processor, appearantly enough to slow your second loop. But this is just a guess. Is it really critical to read the joystick coordinates every 2 ms? Most humans don't move that fast...

[shoneill]

Even if the graph update isn't too much for the processor to handle, it might be possible to keep the producer and consumer loops in different VIs. This way you can force them to run under different threads (Queues run across different programs running within the same LV space), which may help in fixing any thread conflicts. If both loops update indicators, they'll have to run in (or switch to) the User Interface thread, where both loops are again sharing the same thread.

Hope this helps

shane.

[falkpl]

After looking at your code there is a problem with the loops running concurrently. You have placed two seperate loops inside a single for loop. This breaks the natural parallelism inate to labview's dataflow model. for each itteration of the for loop each while loop must complete before the next itteration must complete. This will cause the graph to update every time before the next joystick data is collected. Make two loops one fast loop for joystick information (no delays runs as fast as possible, this is machine and resource dependent though, or slower if you desire) and a slow loop (place a delay of atleast 30 milliseconds inside of the loop) for the graph update routime. There is absolutly no reason for the graph to ever update faster than 30Hz since the user (human) will be unable to detect visual stimuli faster than this. Use a queue to pass joystick events between loops. This is a simple producer-consumer architecture whit asynchronous threads. Also remember that each graph update will take some time (on your machine it appears to be 15-20 microseconds)and these loops (threads) are concurent NOT parallel keep the graph refresh rate lower if your PC cant support the full 30 Hz. Hope this helps
-Paul

[rmaletsky]

Thanks to all for the reponses. I'd like to answer the questions and also make sure I understand the replies. First, the time issue I am having occurs about every 50ms. This is how often the second (consumer) while loop is set to actually plot data (it checks the stop global every 2ms, but doesn't update the plot until 50ms has passed). So, it seems this behavior indicates that these loops are not running in parallel (the consumer and producer), which was explained by falkpl's response? I thought that I had designed simple producer/consumer loops, but it sounds like if they are both in the same for loop, this eliminates the benefit? In Shane's response, he seems to say that I could make each of these loops a subvi, but won't the same problem occur if I run them inside a for loop? It seems it may be possible to move the plotting (consumer) loop outside the main for loop. I am still not clear on whether I can make these two paralell or not.

Here's why I am running the joystick collection so fast: The task is run in an fmri scanner and the timing of 1-2 ms is critical to synching the behavoral and imaging data. Also, the timing resolution is important when you are talking about response times (though not neccessarily to 2ms).

Thanks again for the help.
Rebecca

[falkpl]

I have attached a very simplified version using a mouse. I did not use event structures since you want to poll the joystick. I used the mouse (which can be reworked with a few simplifications to work with the joystick)because I do not have a joystick on this PC. It is in LV7.0 and doesn't use any specialized subvi's. There may be a way of creating a user event which can be linked to the joystick event. Possible using an activeX event (activeX joystick control?) and creating a subvi to handle the callback event but I am not sure about this.

Paul