hardware push button

[smm]

I had to mention one more thing about the heat pass led in every mode. What this is used for is that if at anytime, the operator hits the start/stop hardware button, the process should stop. hence it is a true in the stop mode but false in the remaning modes.

I cannot understand why you let the heat pass be a control and go from one end of the case structure to the other

[smm]

I noticed one thing with the string.

If you see the message for every tstat is the same at all times. Then why does it flas every time. I had usedthe global variable of the string initally but ravens fan said I should do it as it is now. But I really do not want the message to flash. It should stay till the specified time (as in the code).

Also after every mode I saw the heat_read, cool_read etc arrays are going off. I would like them to stay on after the completion of the mode as I mentioned previously.

I am sorry I am bothering you with so many doubt/queries and questions but I really need the help.

Thank You.

[smm]

For the reads, I think there should be separate read VIs for each subvi, since we are using similar no. of lines per subvi. Tjis is just a modification to the mux_try8  vi, but I am definitely going to go with mux_try demo version. But I think the read vis should be separate for each vi, so that all the indexes can be 0-5 and select signals as required as shown in tsat_subvi3[2]. Please take a look at this attached copy only as a read vi view.

[johnsold]

I only have a few minutes right now so I cannot respond to all of your questions.

The reason I removed the DAQ reads and writes is so that I can run the demo. I do not have any DAQ hardware and DAQmx is not supported on my platform. The reads and writes are not essential to understanding the structure and operation of the program.

More later.

Lynn

[smm]

Alright.. Sorry to rush you and keep messagin you continuosly. I will wait for your response. Thanks.

[johnsold]

I will try to respond to your questions in the order asked. I will refer to the message numbers to allow anyone using the Web interface to the Forum to see where the questions were asked.

Message 55: Dialog conflict: If the power is common to all units, this will not be an issue. I had assumed that each unit had its own fuse and that each could be on or off separately.

- Parallel execution: If they are really all going to be in the same state at the same time, a single state machine with data "channels" for each unit might be better than six separate state machines. Thanks for the data port listing in Message 60. That clarifies things.

-Timing required: I understand that the timing is required for your devices being tested. I just shortened everything in the demo so that I would not need to wait minutes to see what the program itself is doing.

Message 60: DAQmx Reads and Writes: As I said in Message 64, this just allows me to run the demo without having hardware available.

-Loop Done light: The simple demo does not have a mechanism to stop the loop which monitors the Stop button when the main loop is done. The light just lets the user know that the main loop has stopped so the user can push the Stop button to stop the entire program.

-Start button: The Start function is not implemented. The purpose of this loop was to demonstrate that the Button could be monitored without putting the reads inside each state machine.

-Arrays should stay on: You need to put the Unit displays on shift registers. The Tsat_subVIs have a Unit in connection which is not connected in the mux_try VIs. This means that each time the subVI is called, the displays are reset to default values except for the parts changed in that particular state.

-Cool_read array, write, check: The data for cool_read is read outside the subVI. The same array is passed to the display after the write. It is not read again. Additionally, the display does not update until the subVI completes the execution of the state (Cool mode).

-Units do not execute in the same order: Welcome to the world of dataflow programming! LV nodes execute only when all their inputs have data available and the scheduler passes control to them. Search the LV Help for "dataflow" if you are not familiar with this concept. Several of your other problems are likely also related to not fully understanding dataflow.

-Heat pass in every case: I used a constant, not a control. By wiring it through, I did not need to put a constant in every case, only in the Stop case. Another option is to set the tunnel to use the default value (which is False for a boolean) and only wire the True constant in the Stop case. These are personal preference items. What you had works perfectly well. I was trying to shrink the width of the case structure and eliminating the False constants was less work than moving each >1000 pixels to the left.

-Flashing string: This is part of the dataflow behavior. Since each subVI writes to the string first a message then a blank, the message flashes as each subVI gets its turn to execute. The parallel execution item above offers a possible solution.

Let me see if I can put together another demo showing how this can work.

Lynn

[smm]

johnsold wrote:
- Parallel execution: If they are really all going to be in the same state at the same time, a single state machine with data "channels" for each unit might be better than six separate state machines.

I didn't quite follow this. I believe that because every unit undergoes the same process, they should notrmally be in the same state only unless given that there is a faulty tsat and it does nto generate some signal, nin which case it fails and the process for that unit stops.

johnsold wrote:
-Cool_read array, write, check: The data for cool_read is read outside the subVI. The same array is passed to the display after the write. It is not read again. Additionally, the display does not update until the subVI completes the execution of the state (Cool mode).

---

So what does that imply? The execution will still take place and we'll still be able to see the updated result right? If not what should be done?

johnsold wrote:
-Units do not execute in the same order: Welcome to the world of dataflow programming! LV nodes execute only when all their inputs have data available and the scheduler passes control to them. Search the LV Help for "dataflow" if you are not familiar with this concept. Several of your other problems are likely also related to not fully understanding dataflow.

I understand what you are saying, but like I said before the process remains the same for every unit, then why does the data not become available together or atleast in the correct order?

I am sorry that I have been bothering you but am so glad you are helping me. A lot of things have become clearer. Thanks. I'll be waiting for that demo. Thanks again!

[smm]

---

johnsold wrote:
-Arrays should stay on: You need to put the Unit displays on shift registers. The Tsat_subVIs have a Unit in connection which is not connected in the mux_try VIs. This means that each time the subVI is called, the displays are reset to default values except for the parts changed in that particular state.

---

Where does the unit in connect? Whenever I try to connect the unit in to the left side of the wall, it gives me a broken wire and an error stating

"You have connected an output loop tunnel to the input of a subvi. Change the input to an output"

[johnsold]

While I am working on an updated demo to show some of these things (easier than trying to explain in text), I suggest you look at some of the LV tutorials. They will explain how LV works and where it differs from other programming languages.

The Unit displays show Heat_Read, Fan_Read, .. as 4 element arrays. That adds up to 16 bits per Unit but the Port list you posted earlier only shows 4 bits per unit (labeled Y, W, GL, and GH). Do the different bits represent different data at different times? If so, how does the hardware know what state the software is in?

Lynn

[smm]

It is 4 bits per unit. here are Y, W, Gh and Gl signals for every thermostat unit. So the heat read , fan read etc arrays show these signals.. Like in the pdf i had attached, in heat mode i check for W, in fan for Glh, in cool for Y and Gl, in fan auto hig for Y and GH.

They are the same 4 signals monitored at all times. So in an a wrokign tsta, inn the heat mode you'll only see W, in fan only GH so on and so forth.