How to be sure that an event start before an other ?

[Dennis_Knutson]

One valid reason for making your own wait VI is to place the wait(ms) inside a case structure with the error in wired to the selector.

[billko]

---

@Dennis_Knutson wrote:

One valid reason for making your own wait VI is to place the wait(ms) inside a case structure with the error in wired to the selector.

---

LOL thanks for trying to bail me out, but now that i know of the express vi's existence, I like it better.  😉

[crossrulz]

---

@Dennis_Knutson wrote:

One valid reason for making your own wait VI is to place the wait(ms) inside a case structure with the error in wired to the selector.

---

I actually took mine a step further and left an option to wait even if there is an error.

Plus, there's a lot of people that say "Express VIs are evil".

[Mark_Yedinak]

---

@crossrulz wrote:

---

@Dennis_Knutson wrote:

One valid reason for making your own wait VI is to place the wait(ms) inside a case structure with the error in wired to the selector.

---

I actually took mine a step further and left an option to wait even if there is an error.

Plus, there's a lot of people that say "Express VIs are evil".

---

There is one thing about Express VIs that I learned recently that makes me try to avoid them. Any VI containing an Express VI must and will be executed on the UI thread. You cannot specifiy any other thread for it.

[altenbach]

---

@Mark_Yedinak wrote:
There is one thing about Express VIs that I learned recently that makes me try to avoid them. Any VI containing an Express VI must and will be executed on the UI thread. You cannot specifiy any other thread for it.

---

 Can you elaborate on this statement? I don't think this is true.

[Mark_Yedinak]

---

@altenbach wrote:

---

@Mark_Yedinak wrote:
There is one thing about Express VIs that I learned recently that makes me try to avoid them. Any VI containing an Express VI must and will be executed on the UI thread. You cannot specifiy any other thread for it.

---

 Can you elaborate on this statement? I don't think this is true.

---

Actually, what I said wasn't accurate. I was confusing something else with the threads. What I do know to be true is that any code containing an express VI can have it's compiled code separated from it's source code. We had a handful of VIs that would regular state they needed to be saved even though they weren't modified. We separate all of our compiled code from the source to make source code control useful. All of the offending VIs turned out to contain Express VIs.

Sorry for the confusion. Juggling too many balls today.

[Yamaeda]

---

@billko wrote:

Yeah, made mine one connector high, also.

---

You can also add a Boolean with "Wait on error(F)" which can be clever to not slow the program down in case of error propegation.

/Y

[crossrulz]

---

@Mark_Yedinak wrote:

What I do know to be true is that any code containing an express VI can't have it's compiled code separated from it's source code.

---

I ran into this issue as well.  I believe it was fixed in 2012 though.

EDIT:  Yep, just confirmed.  This is fixed in 2012.

[yomo]

A lot of thanks to all !

I did not realize that the error cluster can be useful to control the flow of events. Thanks crossrulz.

I did not realize also that for analog output  "Once you write the new value, it stays there until you write something else."  Thanks altenbach.

Knowing that I have coded Capture1.png but it still didn't work because of the Grabbing vi that doesn't grab a new image but grab the last one viewed by the camera (can be before the LED is ON)

So I have coded Capture2.png with a start-camera and stop-camera before and after grabbing to force reinitialization, and it works.

all comments are welcome

[crossrulz]

What happened to the Wait you said you needed?