Check out this program I made in LabVIEW!

[Ben321]

This is an event structure. The output tunnel is set to "use default if unwired" so all other cases will output a false, keeping the loop running.

The hourglass is used to wire a timeout value (in cases where a timeout case is used) and the "source" is an event terminal. You can resize it for more features. Here you can get information about the event that just happened. E.g. in a "value changed" event for a numeric control, you could get the old and new values if desired. In my code these are not used.

You can right-click on any structure and select "help" to get more information. You can also enable the context window (ctrl+h) and you'll get more information on anything you hover over with the mouse.

These are all good questions and I'm sure you'll learn fast once get get the hang of things and see the full power of all the available tools. 🙂

---

Thanks for the info. But could you show screen shots of the other events in your event structure? I'd like to see what else you have there so I can try to duplicate it to see if it works with my setup.

[altenbach]

I have also attached the VI. Have you tried to open it? 🙂

(I thought you have LabVIEW 8.5)

[Ben321]

---

altenbach wrote:

I have also attached the VI. Have you tried to open it? 🙂

(I thought you have LabVIEW 8.5)

---

Acutally it is LabVIEW 8.5.1 and it DOES have an an event structure that I can place in the block diagram.

And I just looked at your modified version of my VI. I see on the edges of the while loop, you are using the shift register items. Why did you use them?

Why did you use the event loop for loading the image file AFTER the image is displayed? Shouldn't it be placed BEFORE the image is displayed so it has an image to load?

Message Edited by Ben321 on 11-16-2008 05:19 PM

Message Edited by Ben321 on 11-16-2008 05:24 PM

[Ben321]

---

altenbach wrote:

I have also attached the VI. Have you tried to open it? 🙂

(I thought you have LabVIEW 8.5)

---

And one last thing. WHY is the button for saving an output image file (which is in one of the events in the event structure) actually NOT connected to anything in your VI? I see no wires coming from it.

[altenbach]

---

Ben321 wrote:
And I just looked at your modified version of my VI. I see on the edges of the while loop, you are using the shift register items. Why did you use them?

Why did you use the event loop for loading the image file AFTER the image is displayed? Shouldn't it be placed BEFORE the image is displayed so it has an image to load?

---

 

You don't need to copy everything I do, this is just my programming style. Typically everything I do has a good reason. 🙂

If you display the image first, it ensure that the display is correctly updated every time you run the VI during debugging. For example of you run the VI and load an image, then stop the VI, change the bit level in edit mode, and run the VI again, you'll get the correct display immediately. If the display were after the event structure, you get a stale image display until the first time you change one of the controls again. If you want to display to be cleared every time you run the VI, yuo can initialize the shift register.

Alos, if you place it after the event structure, the display will be written once more when you press stop. If the display is before the event structure, it will stop without any other useless detours. As I said, you don't need the sequence frame if the code is before the event structure.

---

Ben321 wrote:

And one last thing. WHY is the button for saving an output image file (which is in one of the events in the event structure) actually NOT connected to anything in your VI? I see no wires coming from it.

---

It does not need to be connected to anything, because the event structure executes whenever you press the button. The button is latch action, meaning it will reset to false automatically once it is read by the code (that's why the terminal needs to be inside the event case. If you would place it outside the loop, it will never reset, because it gets only read once when the program starts). Since the event can only execute if the new value is true, we don't need to check it's value, because we already know it. It is TRUE 100% guaranteed so it would not change the outcome of the logical AND that you had originally.

[Ben]

Hi Ben,

Quoting from the 23rd Psalm "Thy rod and thy staff, they comfort me."

It is an honor to be wacked by Christian and Ton.

BTW: You may find this thraed interesting. It contains links to other Picture Control threads.

Have fun,

Ben

[Ben321]

---

altenbach wrote:

---

Ben321 wrote:
And I just looked at your modified version of my VI. I see on the edges of the while loop, you are using the shift register items. Why did you use them?

Why did you use the event loop for loading the image file AFTER the image is displayed? Shouldn't it be placed BEFORE the image is displayed so it has an image to load?

---

 

You don't need to copy everything I do, this is just my programming style. Typically everything I do has a good reason. 🙂

If you display the image first, it ensure that the display is correctly updated every time you run the VI during debugging. For example of you run the VI and load an image, then stop the VI, change the bit level in edit mode, and run the VI again, you'll get the correct display immediately. If the display were after the event structure, you get a stale image display until the first time you change one of the controls again. If you want to display to be cleared every time you run the VI, yuo can initialize the shift register.

Alos, if you place it after the event structure, the display will be written once more when you press stop. If the display is before the event structure, it will stop without any other useless detours. As I said, you don't need the sequence frame if the code is before the event structure.

---

Ben321 wrote:

And one last thing. WHY is the button for saving an output image file (which is in one of the events in the event structure) actually NOT connected to anything in your VI? I see no wires coming from it.

---

It does not need to be connected to anything, because the event structure executes whenever you press the button. The button is latch action, meaning it will reset to false automatically once it is read by the code (that's why the terminal needs to be inside the event case. If you would place it outside the loop, it will never reset, because it gets only read once when the program starts). Since the event can only execute if the new value is true, we don't need to check it's value, because we already know it. It is TRUE 100% guaranteed so it would not change the outcome of the logical AND that you had originally.

---

I'm still unsure why you chose to use a shift register in the while loop. What does using the shift register accomplish?

Message Edited by Ben321 on 11-17-2008 02:51 PM

[TCPlomp]

---

Ben321 wrote:

---

I'm still unsure why you chose to use a shift register in the while loop. What does using the shift register accomplish?

Message Edited by Ben321 on 11-17-2008 02:51 PM

---

I assume (I have not opened the VI) Christian has value change events for the Bit and Colour values as well. By using a shift register he keeps the picture in memory and the program doesn't have to reread it from disk.

(and I assume you know what a shift register does).

Ton

[Ben321]

---

TonP wrote:

---

Ben321 wrote:

---

I'm still unsure why you chose to use a shift register in the while loop. What does using the shift register accomplish?

Message Edited by Ben321 on 11-17-2008 02:51 PM

---

I assume (I have not opened the VI) Christian has value change events for the Bit and Colour values as well. By using a shift register he keeps the picture in memory and the program doesn't have to reread it from disk.

(and I assume you know what a shift register does).

Ton

---

Well as far as I know, a shift register is a digital logic circuit that shifts as series of bits in such a way that the either:

1) go out one side and come back in on the other

or  if configured differently then 2) the data bits go out one side and binary zeros fill in the missing bits.

As far as I know, such a mechanism isn't needed in my VI, as all it does is isolate a specified bit plane of an image and display that bit plane. All of the digital binary manipulation stuff needed to accomplish that was already taken care of in my VI.

So I'm still unsure of how he was using the shift register.

I've only had this program for 1 to 2 weeks so I'm unfamiliar with a lot of it.

[RavensFan]

---

Ben321 wrote:

Well as far as I know, a shift register is a digital logic circuit that shifts as series of bits in such a way that the either:

1) go out one side and come back in on the other

or  if configured differently then 2) the data bits go out one side and binary zeros fill in the missing bits.

As far as I know, such a mechanism isn't needed in my VI, as all it does is isolate a specified bit plane of an image and display that bit plane. All of the digital binary manipulation stuff needed to accomplish that was already taken care of in my VI.

So I'm still unsure of how he was using the shift register.

I've only had this program for 1 to 2 weeks so I'm unfamiliar with a lot of it.

---

NO NO NO NO!

There are functions that do bit shifting.  But that is not at all what a shift register does.  A shift register takes the value at the output tunnel at the end of a loop iteration, and makes it available at the beginning of the next loop iteration.  If you add a loop that took a number and added 1 to it, with normal tunnels if it came in as 0 , it would go out as 1 no matter how many times you ran the loop.  With a shift register 0 become 1 in the first iteration, 1 becomes 2 in the second, 2 becomes 3 in the third, and so on for however many loop iterations there are.

I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours