Design a VI for giving a warning signal followed by a go signal for a Simple Reaction time task

[mikeporter]

One additional refinement of your wait+.VI:

Create a case structure on the block diagram then wire the error cluster to the selector node. Finally, put the wait in the No Error case.

Now if you request a long timeout and there is an error coming in the wait will be bypassed.

Mike...

[johnsold · Accepted solution]

Here is a way to eliminate the sequence structure (and gain significant versatility) and eliminate the local variables. I converted your VI to a simple state machine. This Vi will stop one state after the stop button is pressed. It does not need to go through the entire sequence (twice).

The SRT State.ctl is a typedef enum listing all the possible states of the state machine. By making it a typedef any changes (such as adding a state) will automatically update all the constants.

I also changed the time indicators to show the actual time in each state. The output of Wait (ms) is tick count, not elapsed time. To get elapsed time you need to subtract the previous tick count from the current tick count.

When you get to running this for your actual measurements, you may run into limitations of the OS timing. Neither you nor LabVIEW has any control over exactly when the OS will update the screen. You will know when LV wrote data to the Go and Warning indicators but not exactly the time the display updates. Similarly, you do not know the exact time between the test subject clicking on an button and the time the OS reports that information to LV. Latencies of a few to a few tens of milliseconds are common.

Lynn

[sth]

This is always a debatable item.  NI convention says to do it that way.  But it depends if that is the desired functionality.

The issue here is not the perfect Wait+.vi but using error terminals for serialization.  That is the take away message.

[billko]

---

@mikeporter wrote:
One additional refinement of your wait+.VI:

Create a case structure on the block diagram then wire the error cluster to the selector node. Finally, put the wait in the No Error case.

Now if you request a long timeout and there is an error coming in the wait will be bypassed.

Mike...

---

According to the education board, the error passthrough is not a refinement, but a requirement.  At least it was for the CLD.  😉

[sth]

---

@billko wrote:

According to the education board, the error passthrough is not a refinement, but a requirement.  At least it was for the CLD.  😉

---

Yes, why I predate the education board by a huge number of years and am not certified....  🙂  I don't always agree with dogma.

Actually my first wait+.vi predated the existence of the error cluster.  Or actually clusters in general.

[billko]

---

@sth wrote:

---

@billko wrote:

According to the education board, the error passthrough is not a refinement, but a requirement.  At least it was for the CLD.  😉

---

Yes, why I predate the education board by a huge number of years and am not certified....  🙂  I don't always agree with dogma.

Actually my first wait+.vi predated the existence of the error cluster.  Or actually clusters in general.

---

We had a lively discussion on error passthrough in the Cert forum.  Wish I could find the thread.

Anyway, you have a long and illustrious career to show you know your stuff; I have to wave a pieve of paper in front of someone's face to get them to see me.  😉

[mikeporter]

Actually, the refinement was the addition of the case structure. I assumed that the error pass through was there. Error clusters should be on any VI that:

1. Can generate an error
2. Might reasonably need to respond to an error.

Mike...

[JÞB]

Again?

No, I'm not dissapointed.  There will be a free package available from 8-Ball someday.   I'm thinking of namig it "%95 code"  It would be code templates and framework thingies that NI could not garuntee would be advisable for %5 of your applications... and they should not support that!

PM me some ideas.  I'll get around to them maybe

[sth]

---

@JÞB wrote:

No, I'm not dissapointed.  There will be a free package available from 8-Ball someday.   I'm thinking of namig it "%95 code"  It would be code templates and framework thingies that NI could not garuntee would be advisable for %5 of your applications... and they should not support that!

---

I like that.  Could be the most useful package!

[sth]

Not to beat a dead horse, but to get back to the OP question and make a subtle point about the structure of LV and a difference between that and traditional languages.

Docas, in the long flat squence structure you have, the sequence that has a random 1 to 3 second wait is technically a bit off since the calculation of that wait is inside the sequence.  So that frame of the sequence will take the wait time plus the calculation time.  In this case it is neglible and added to a random number anyway, but in general, you want the calculatoin to be outside the sequence so that the calculation time is not part of the timing.

This is also true of the timing for Lynn's state diagram, moving the random calculation outside the state with the actual wait and doing the calculation in parallel with one of the other waits and passing it through another shift register would increase the timing accuracy.  In this case a minimal amount but it is something to consider in more complex applications.

The Wait+ subVI (and all of the suggestions for improvments are good, I just took your wait statement and used Create SubVI) ensures that this happens and that any wait is in parallel with other operations in your main diagram.  LV is an inherently parallel programming language as shown by the 2D nature of the block diagram.  Forcing sequential actions with a sequence is in general bad since one tends to put more in a sequence step than necessary as in your example.  It is making LV revert to a simple text based language which loses one of the main advantages.