LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using an event structure for a UI, how to smoothly update plot overlays after multiple scale range changes

Hey Mark,

 

Thanks for having a look at this. I implemented nathand's suggestion, and like you mentioned there was still some flickering. It is ver obvious when you zoom, then grab and drag, pause movement while still holding the grab and then drag again.

 

I still feel like I should be able to do something clever with the "Cursor Grab", "Mouse Down" or "Drag" portions of the event structure, along with the nathand's timeout suggestion. Can anyone point me to some documentation as to what these various events are?

0 Kudos
Message 11 of 16
(555 Views)

ColeVV wrote:

You are correct that I am not using the suggestion from the link in this case for the mapping function. Inserting this section of code directly would avoid data copies. However, and maybe I am venting a bit here, I find this practice to be incredibly frustrating. I would like to be able to develop modular, reusable, readable code such as the subvi's I have included here, which I do use in other projects. However, because LabVIEW does not allow passing by reference as an option on the subvi, I suppose I need to write all of my functions using the techniques described here. Most of my main code, which this was taken from, extensively uses queues to try to avoid these copies. I just find my block diagram is filled now with queue vi's which make it very difficult to arrange the block diagram in a readable manner.


I can't figure out what you're talking about here. I don't see queue VIs all over this code. I do see one obvious misuse of local variables, though - why are the terminals for "Intensity of Sine Curve," "Number of X Points," and "Number fo Y Points" unwired in the event case, and then referenced through local variables in the display loop? Use the terminals there.

 

I'm not sure why there's a misconception that LabVIEW doesn't pass data to subVIs by reference. This is incorrect; it might be more accurate to say that it passes all values by reference. LabVIEW memory management is copy-on-write - a copy is made only when an operation needs to modify a value and some other piece of code is still holding onto the original. So if you pass an array to several subVIs and those functions only read values from the array rather than modifying it, no copies are needed. If only one VI modifies the array, and the calling VI no longer needs the original array, then the one subVI that makes changes will modify the original array without making a copy, so long as the compiler can schedule all the other subVIs (that only read) to run first. Usually the compiler will schedule subVIs to minimize copies.

0 Kudos
Message 12 of 16
(548 Views)

You can also use DVR to pass references to your data.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 13 of 16
(542 Views)

@nathand wrote:

I can't figure out what you're talking about here. I don't see queue VIs all over this code. I do see one obvious misuse of local variables, though - why are the terminals for "Intensity of Sine Curve," "Number of X Points," and "Number fo Y Points" unwired in the event case, and then referenced through local variables in the display loop? Use the terminals there.

 


Hi nathand,

 

You are right, I was completely unclear, which usually happens in a vent! In my original post, I mentioned this is a code snippet from a much larger code. In the larger code, I take very large 2D arrays from a camera (150000 x 1000) and then process them (something akin to an FFT). From there, I need to trace a signal across this 2D array. As a user zooms in and moves around to examine the data, that is where I was having these issues of upating this image I put on my intensity graph.

 

 Regarding the local variables, my understanding (and I wouldn't doubt if it was wrong) was that when you use the "variable change" event, the control is supposed to be located within the event structure. Now that I think about it, I can only remember seeing that written about the "stop" control for the loop so this is probably a misconception on my part.

 


 

 

I'm not sure why there's a misconception that LabVIEW doesn't pass data to subVIs by reference. This is incorrect; it might be more accurate to say that it passes all values by reference. LabVIEW memory management is copy-on-write - a copy is made only when an operation needs to modify a value and some other piece of code is still holding onto the original. So if you pass an array to several subVIs and those functions only read values from the array rather than modifying it, no copies are needed. If only one VI modifies the array, and the calling VI no longer needs the original array, then the one subVI that makes changes will modify the original array without making a copy, so long as the compiler can schedule all the other subVIs (that only read) to run first. Usually the compiler will schedule subVIs to minimize copies.


Thank you for clearing this up for me. I am very used to languages like C++ (where I should know and be able to control what all of my memory is doing) and Matlab (where I might be making temporary copies of a large matrix A with statements like A=A+1). I guess Matlab would be similar to LabVIEW in this case? Even then, in Matlab you still have the option of looping over the elements, but I guess that is similarly true if you use the LabVIEW "in place element" structure.

 

Regardless, the final intention of this section of my code is for a user to view a large dataset and try a number of different processing algorithms on it (each contained in a subvi). Currently, I store the the array in a queue, pull it out and hand it to the processing subvi, and the put it back in the queue. The subvi processes the data, and then hands back 3 arrays corressponding to the x, y and z, points identified by the processing algorithm. I have attached example snippets of this process as well as one of the simplest processing algorithms (find N maxima that are greater than the threshold). My biggest worry is that doing this has uncontrolled copies of my large array that are now associated with this subvi. Maybe I am worrying about nothing, but I really can't afford extra copies of that array hanging around. In reality, the application of this code will always be trying to make the first dimension of that array as large as possible until we reach a memory limit. I know I will have to throttle the users somehow to ensure that they never reach that limit but that is a whole other conversation...

Download All
0 Kudos
Message 14 of 16
(532 Views)

Thanks Mark, I didn't know about Data Value References

0 Kudos
Message 15 of 16
(528 Views)

@ColeVV wrote:

 Regarding the local variables, my understanding (and I wouldn't doubt if it was wrong) was that when you use the "variable change" event, the control is supposed to be located within the event structure. Now that I think about it, I can only remember seeing that written about the "stop" control for the loop so this is probably a misconception on my part.


This applies only to boolean controls that have a latching mechanical action (commonly true for "Stop" buttons). Reading the terminal releases the latch, so it's common to put the boolean terminal inside the associated value change event case. However, so long as the boolean terminal is read somewhere after the user clicks it the latch will release, so putting the boolean in the event case is not an absolute requirement.

 

About the queues - did you benchmark your code before you put queues all over the place? I don't want to generalize too much from the two small images you provided, but at least in the code you've shown I would expect that eliminating the queues and passing the arrays directly will not increase memory use. Give it a try.

0 Kudos
Message 16 of 16
(516 Views)