Highlight Execution

[jabano]

thanks for the suggestion! i'm not sure how to do this though since i just want to use case 0 and 1 once, (the case structure around the other cases), and leave it on case 2 for however long the person wants to use it.

on the front panel i start the program by using the ok button and then rely on the VI to read the hot plate continuously. the other programs i saw online feels as if the front panel should be interactive in order for the other states to run but i just want to leave it alone and let it run it's course.

[RavensFan]

You create an enum that has all of your cases.  You start the state machine with case0 initializing your state machine shift register.  When it runs, it puts case 1 into the shift register.  Case 1 puts case to into the shift register.  Case 2 puts case 2 into the shift register.  So the order of execution becomes 0, 1, 2, 2, 2, .......

A lot of your inner "stacked sequence structures disguised as For loops" inside your cases don't even need to be sequence structures.  Just do the write, delay, read, all in a row in the case using error wires and the Express time delay VI (because it gives you error terminals that the normal wait function does not have) to enforce the order of execution.

[Yamaeda]

---

@smercurio_fc wrote:

---

@Yamaeda wrote:

Your wait will occure after the read due to LV optimization,

---

????

---

I guess parallellization is more correct to say, but the end result is in this case the same, he'll read instantly after sending the write command and then wait.

/Y

[RavensFan]

Remember, if you are doing what this user is doing which is a VISA read of 6 bytes, the VISA read will wait until

1.  A termination character is received if the termination character is enabled.

2.  The number of bytes requested (in this case 6) is received

3.  The timeout value has been reached.

The only situation where Write and immediate read is an issue is in those situations where you are doing a Write, immediately determine bytes at port, then read that number of bytes.  This is the situation where you need to put a Wait between the Write and the check on the number of bytes at port so that you give the device time to respond and the number of bytes is not Zero.

While the Basic Write and Read example uses the "bytes at port" method, I find this is actually a poor example and most real world programming situations should not need this.  The bytes at port method is really only good in situations where you don't know how many bytes you are expecting, you don't know how long it will take, and you aren't getting any termination character to mark the end of a message packet.  In these cases, use bytes at port to continually in a loop reading whatever is there, then storing and building up the messages in a loop using a shift register until you've determined after the fact you've got the message you were looking for, at which time you can parse out the message and pass it on to you next piece of code.

[smercurio_fc]

---

@Yamaeda wrote:

---

@smercurio_fc wrote:

---

@Yamaeda wrote:

Your wait will occure after the read due to LV optimization,

---

????

---

I guess parallellization is more correct to say, but the end result is in this case the same, he'll read instantly after sending the write command and then wait.

/Y

---

That makes even less sense. How can you have parallelization with a for loop that has a case structure inside that calls each case sequentially?

[Mark_Yedinak]

---

@Ravens Fan wrote:

You create an enum that has all of your cases.  You start the state machine with case0 initializing your state machine shift register.  When it runs, it puts case 1 into the shift register.  Case 1 puts case to into the shift register.  Case 2 puts case 2 into the shift register.  So the order of execution becomes 0, 1, 2, 2, 2, .......

A lot of your inner "stacked sequence structures disguised as For loops" inside your cases don't even need to be sequence structures.  Just do the write, delay, read, all in a row in the case using error wires and the Express time delay VI (because it gives you error terminals that the normal wait function does not have) to enforce the order of execution.

---

This is excellent advice. I did want to add a couple of things. First, when you use a ENUM like this you should always create a typedef for it and use that typedef. Otherwise if you just use a simple ENUM constant you have to update every instance of it when you make changes. A typedef will do this for you automatically.

Secondly, make sure you use descriptive names for the states/actions you define in the ENUM. Generic terms like "Case 1", "Case 2", etc. are meaningless and don't convey any information about your code. Use names such as "Get Hot Plate Temperature", "Set Hot Plate Temperature" and similar such descriptive names. It will make your code more readable and easier to understand.

[Yamaeda]

---

@smercurio_fc wrote:

---

@Yamaeda wrote:

---

@smercurio_fc wrote:

That makes even less sense. How can you have parallelization with a for loop that has a case structure inside that calls each case sequentially?

---

I was answering to Temp1.vi or what it was called, the temp2 one doesn't have that problem.

/Y