LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Even structure/Mouse Selection

Solved!
Go to solution

This is my first attempt at a .vi that seems to need an event structure. I am a student in a research lab and my LabView experience is really learn as you go up till now. The program is designed to track a scanner using two linear pots and read in the voltage measurement. I am using an intensity graph to show the values recorded. What I was told to look into doing was replacing the intensity graph with picture functions so that we had more freedom in the movement of the scanner, which so far seems to be true.

 

Currently I am blocking the analog measurements because we don't have the parts, and modeling the movement with controls. The step I am working on now is to be able to select part of the picture and get the data from it. This can be done by saving part of the picture or reading in the data itself corresponding to that part of the picture or (preferably) both. I don't have any experience thus far with even structures except for playing around with them to try to get this to work. The way I have it set up currently seems to completely bog down the system because with it enabled the other functionality appears lost (or just takes forever). 

 

So basically I'm looking for help to correctly implement what I have attempted here. As usual I would also appreciate general design critiques (gently). 

0 Kudos
Message 1 of 9
(3,834 Views)
Also, the coordinate math is off in that, the input to the subtract vi should be swapped. Just wanted to point out that has been fixed already.
0 Kudos
Message 2 of 9
(3,831 Views)

I've also found and tried to implement this thread

 

http://forums.ni.com/ni/board/message?board.id=170&message.id=242266

 

because it seemed like it would help to limit when the even structure would execute, but it doesn't seem to help. I'm not going to include the updated code because I just put a reference for the picture into the register event block as it was done in the thread. 

0 Kudos
Message 3 of 9
(3,802 Views)

Thanks for referencing my previous post!

Here's a snippet that should help you lot.

Selectin2D.png

 

What it basically does is replacing the data inside the selected area.

 

This is only something to get you started.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 4 of 9
(3,788 Views)

To avoid starting another thread, I am attempting to better explain what I was doing in the above posts. Here is a much simplified trial code that is doing only what I am having problems with. Basically, we will be having data read in and displayed on a picture so that we have more freedom than with the intensity graph. We then want to be able to select part of the picture and zoom in for more detail. I think I did a poor job explaining this before and so didn't get much out of the replies.

 

The block diagram does this how we want it (or at least close enough that I know I can modify it), with one exception. The picture will never update unless the mouse is clicked to allow the while loop to complete another cycle. If it would update continuously and still allow the same zooming functionality I would be well on my way to getting what I want, but I don't understand enough about triggering the events to know how to go about this.

 

 

zoomtrial.png

0 Kudos
Message 5 of 9
(3,689 Views)
Solution
Accepted by topic author ScottC.

ScottC. wrote:

To avoid starting another thread, I am attempting to better explain what I was doing in the above posts. Here is a much simplified trial code that is doing only what I am having problems with. Basically, we will be having data read in and displayed on a picture so that we have more freedom than with the intensity graph. We then want to be able to select part of the picture and zoom in for more detail. I think I did a poor job explaining this before and so didn't get much out of the replies.

 

The block diagram does this how we want it (or at least close enough that I know I can modify it), with one exception. The picture will never update unless the mouse is clicked to allow the while loop to complete another cycle. If it would update continuously and still allow the same zooming functionality I would be well on my way to getting what I want, but I don't understand enough about triggering the events to know how to go about this.

 

 

zoomtrial.png


Ah cardinal sin of new LabVIEW users. I have a post on the forum from my early days where I did the same thing. No need for two event structures in one loop. You can add multiple event cases by right clicking and choosing add event case. Then add your mouse down event to the same event structure as the mouse up event is in already. However, I know why you are doing it. It is so the rest of the code doesn't execute until the mouse up event happens. If you have only one event structure, as soon as you press the mouse down your code will execute, but you won't have the mouse up coordinates. Yes, this will create a problem ;). However, a better (more complex, but better) way to do this is to dynamically register and unregister mouse events. This is demonstrated in an example that ships with LabVIEW called "dynamically register for events". It is easier to understand than it may seem when first looking at it, but if you need help, continue to post questions.

 

And to answer the bold part, it sounds like you need parallel threads. Look at producer consumer architecture which will allow the graph to keep updating while the user is clicking around. The forum is littered with posts on this.

Message Edited by for(imstuck) on 06-07-2010 03:26 PM
Message 6 of 9
(3,669 Views)
I should add, you can also use a shift register to store the starting coordinates like ton does. I think though, the true root of your problems comes from not having parallel loops. That is what you want to look into.
Message Edited by for(imstuck) on 06-07-2010 03:29 PM
Message 7 of 9
(3,653 Views)

I hate to keep jumping around when you guys are giving advice, but stupidly I suggested a different functionality for our zoom that my supervisor liked, so the .vi has changed quite a bit. Because of this I haven't gotten a chance to make it back to the issue of registering events, but I wasn't making much progress anyway. I do think I am missing a basic understanding; that is, what exactly does registering an event do? This was further clouded in my mind when I looked at the example shipped with Labview and it talked about preparing a registration but not actually registering....

 

But the new design has allowed me to play with Producer/Consumer architecture quite a bit, and I am happy with the results at this point. I would really appreciate it if someone would look over the design, however, and point out where I could potentially have problems that I am not seeing at the moment. Instead of a window selection, this zoom tool chooses an area around the cursor to fill the selection window with. I have added some test code to make sure the zoom is updating live (or so I think).  Thanks everybody.

zoomtrial.png 

0 Kudos
Message 8 of 9
(3,607 Views)
I don't understand why you are continually adding new pictures to the front of the queue, but never do anything but preview the queue.  You never actually remove pictures from the queue.  The queue just grows endlessly with copies of the picture.
0 Kudos
Message 9 of 9
(3,575 Views)