case statement evaluation order

[pchaopricha]

Tom, thank you for the explanation.   That's the most clear and concise answer.  It makes a lot of sense that the Execution Highlights would only show single threaded exectution and therefore could lead to my incorrect assumption.

We added the wiring as you mentioned and that should completely control the flow.

[pchaopricha]

I also think I know why I never had trouble even with 30,000 times of code execution in a row.  The RTS state is always the same (unasserted) after one execution so the race codition actually doesn't impact whether DTR or RTS is set first in the code.   However, I think the problem we would run into is that both would be trying to use the same VISA resource for setting the serial port at the same time.   I don't how the internal workings of the VISA vi are, but perhaps it can lock up the port when both try to access the same resource.

[JÞB]

Both property nodes run in the UI Thread so one will always wait for the other to complete before starting (which runs first is unknowable) but the calls cannot happen "Simultaineously"

[crossrulz]

What are you doing in the TRUE case?  If you are setting the DTR State to Unasserted in the TRUE case, then you could get away with a single property node.  Expand the first property node to show a second property and set it to the DRT State.  Just use the Select function to choose which value to set it.

[pchaopricha]

Jeff,

    That's a very good thing to know.  Thank you for the explanation.   This is the sort of subtlety that I'd like to know since it's not explained anywhere.  So simultaneous resource sharing cannot happen in LabView then, I presume?

Thanks,

Patrick

[crossrulz]

---

pchaopricha wrote: So simultaneous resource sharing cannot happen in LabView then, I presume?

---

That can't happen in any programming environment.  The OS or driver should stop that.  Only one command at a time.