Use time as Event in Event Structure

[obr3ptox]

Goodmorning everyone,

It's still me trying to solve the issue with my project.

I am looking forward to create something which looks like a "slideshow". (The main aim of the whole project is something really different, but I need it to do this too).

I want to open a folder containing .jpg pics, and then slide through them every X seconds. 

Found a thread in this forum talking about cycling through pics in a folder by means of  "Next" and "Previous" buttons, and it looks like it could be useful for me. The main problem now is that I seriously can't find a way to """"press"""" those buttons using time.

What I mean is that I'm trying to find a way to trigger the "Next" event X seconds after the last "Next" event.

I'm attaching the VI I'm working on, and the VI I found on this forum (look at the Cycle Through Images vi to understand what to look for in the Thesis vi).

PS: I uploaded the right Thesis.vi right now

[majoris]

So, the Event Structure has a timeout case. The timeout event is under Application in the event selection. You set the timeout value in milliseconds by wiring a value to the hourglass. This is probably fine for your purposes.

However, there is another way though still leveraging the event structure. You can also create user events. Right click on the outer border of the Event structure and look for show dynamic event terminals. Now you can create a custom user event as follows:

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/creating_user_events/

Labview has a trillion ways to do the same thing. This is just two of them.

[obr3ptox]

Looked like using the Timeout worked to "slide" through picture. 

I noticed that I can't stop the Event structure. It is in a nested while loop, and I would like it to stop when the last pic has been displayed.

Any clues?

[GerdW]

Hi obr,

I would use a QMH (queue driven message handler): you can easily send commands to your message handler (like NEXT, PREVIOUS) at any rate you like. And you can easily filter such commands in your handler routine (like "no NEXT on last image")…

[majoris]

One of the weird things to me about the event structure is that, by default, wires that leave the event structure are automatically set to "Use Default If Unwired". This is seen on the block diagram by a box with a dot in it. I highly recommend you right click on those boxes and unselect that option. This will 'break' your VI. Now go through your cases and think about the logic that should be connected to those wires. For instance, in your timeout and your next, you probably want to stop the while loop AFTER the last image. And you already get a boolean output from your "In Range and Coerce" vi that you use that tells you if the value is in range or not... perhaps that will help?

[RavensFan]

---

@majoris wrote:

One of the weird things to me about the event structure is that, by default, wires that leave the event structure are automatically set to "Use Default If Unwired". This is seen on the block diagram by a box with a dot in it. I highly recommend you right click on those boxes and unselect that option. This will 'break' your VI. Now go through your cases and think about the logic that should be connected to those wires. For instance, in your timeout and your next, you probably want to stop the while loop AFTER the last image. And you already get a boolean output from your "In Range and Coerce" vi that you use that tells you if the value is in range or not... perhaps that will help?

---

There is an idea on the exchange to change that behavior.  Please vote for it.

Output tunnels from event structure should default to NOT "Use Default if Unwired"

[Bob_Schor]

As Majoris said, "Labview has a trillion ways to do the same thing. This is just two of them."

I'm going to suggest one more, but first I need to ask "Are you interested in becoming a good LabVIEW Developer?  Are you willing to spend a little time writing "stylish" code that is easy to understand, easy to debug, easy to document, but may take a little more effort to write?

So here are a few comments on your code (thank you for sharing it with us, even though I'm now going to make note of things I hope you change).

• Most LabVIEW Functions (and every 99% of all the VIs that you write) have an Error Line running through them.  Use the Error Line to sequence your functions (even if they are also "sequenced" by connecting Outputs to Inputs).
• A corollary of this is (almost) never use a Sequence Structure (an exception is when you need to "attach" a Timing Function to the Error Line).  Especially never use a Stacked Sequence.
• The alternative to a Sequence Structure is a simple "sequence" caused by putting sequential things on the Error Line!
• If your sequence is something like "Set up Something", "Loop and Acquire Something", "Close Something", consider a State Machine, basically a Case Statement (Setup, Acquire, Close) inside a While Loop.  Instantly recognizable to LabVIEW Developers, variables in Shift Registers (see next point), compact.
• If you are tempted to use a Local Variable, try to resist!  In many (most?) cases, a better solution is to put the variable in question on a Shift Register.
• Use sub-VIs to "encapsulate" sections of code and reduce the overall (bloated) size of your VI so that everything fits on a single screen.  Note that the Icon Editor allows you to make an Icon using Text or simple pictures that says what the subVI does ("Get Temp Data").
• Look for code where you basically do the same thing, or almost the same thing, and consider using an Array of Inputs and Outputs and putting the repetetive code in a For loop (that's what it's "For").
• Learn to use LabVIEW Project to "contain" your code, especially if you use multiple VIs and multiple TypeDefs (my code usually has hundreds of VIs and dozens of TypeDefs).

I'm going to show you one other way of handling your "Cycle" program.  First, however, note that your "Next" button is used to show the second, third, fourth, etc. Image, with the first Image handled as a "special case".  I'm going to suggest another method, where the Show Button is used to show all of the Images under the following three conditions:  (a) this is the first Image (and the User does not press Next), (b) the User presses Show (which means "Show Next"), or (c) "Delay" seconds elapses since the last Image was shown.

The key to this scheme is that LabVIEW Controls (such as the "Next" Button) have properties, one of which is to set the Value of the Control as though the User had changed it (this is called the "Value Signaling" property, Signaling because it can signal a Value Changed Event.

I'm going to attach a Project that illustrates what I've been saying.  Because I'm going to want to use a Value (Signaling) property for a Boolean Control, I have to worry about the "Mechanical Action" of the Control -- Latching Controls (such as the Stop button) are illegal for Value (Signaling) Events.  So I use a Boolean with Switch when Released, and in the Event for it, I use a Local Variable (gasp! -- and after I said "Almost never use Local Variables!") to make the Show Control "momentary".

Here's a Quiz -- why did I put the Stop Button inside the Event Loop?  [Actually, I forgot to do this when I first coded it.  I recommend that once you test this code yourself, you try wiring the Stop Button directly to the While Loop's Stop, deleting its Value Change case, and observing the result.  "Learn by Experience" is a good way to learn ...].

I've attached the Project I made, and tried to save it in LabVIEW 2013 (which seems to be the version you are using).  If you've not used Project, unzip this somewhere, open the Folder, and double-click the .lvproj file, which should tell LabVIEW 2013 to open it.  Then (in the Project Viewer) click Show Images and try it out.

Bob Schor

[obr3ptox]

First of all, I really wanted to thank you all for all the effort you put in your answers 😉

This is my thesis project, and almost the first time I actually use LabVIEW to do something. This is actually being the ground on which I am gaining the experience for my future.

Btw, I am now trying to work as majoris suggested, and it seems to work (excluding that I am struggling trying to make my VI show those images while doing all its other stuffs, and keep doing its stuff when the "slideshow" has finished).

Answering to you Bob_Schor, I will improve this VI appeareances when I'll finish the whole work. At this point, the chaotic-and-needlessly-big VI looks too much chaotic to me to calmly tidy it up. I will surely follow your advice, and maybe I will contact you when I will have finished it.

[cbutcher]

Without knowing what other stuff you want to do, it's hard to give a concrete answer, but if you're looking to do two things simultaneously, and they're not related (like, do a and b, then repeat) you probably don't want them in the same loop. As a result, the first conclusion can be - use two loops.

There are several very common LabVIEW architectures that use multiple loops to do multiple independent things. A description of some of them can be found in this post on Scalable Design Patterns in LabVIEW.

An alternative (and more complicated) solution might be to have asynchronously running (sub)VIs. In that case, you use a reference to a VI to start it running in a new process and it no longer blocks execution in your existing VI. A guide can be found in this LabVIEW help/documentation page on asynchronous vi calls.