hardware push button

[smm]

---

johnsold wrote:
3. The DAQ routine would also be in parallel and feed the data to the six state machines via an action engine. You would have several options for separating the data. I do not know how the data is currently configured, so I cannot offer a suggestion on the format.

---

How do you implement an action engine. I just cannopt seem to figure that out.

[johnsold]

Universal stop. The action engine can help here. When the Stop button is pressed, the DAQ loop reads it and sets the boolean value of the Stop Action Engine VI to True. All loops read this AE on every iteration. If True, the loop goes to the shutdown state(s). A simple AE VI is attached. The simple AE is a VI with a while loop which executes one iteration each time the VI is called. It has an uninitialized shift register which stores the data. The Action input selects one of several cases inside the while loop to perform the action requested on the data.

Timed waits. The reason for this is so that the loops do not need to wait 180000 ms for a Wait to finish before responding to the Stop button. Look at Wait interruptible.vi.

If all the Units are going to be synchronized, then it seems a single state machine with six sets of outputs would be sufficient. What happens if one unit has an error and others are still running?

Sorry about the confusion. We are trying to help. For a project of this complexity it has not been that long since your first post. Of course I do not know how long you worked on it before posting.

Lynn

[smm]

---

johnsold wrote:
Universal stop. The action engine can help here. When the Stop button is pressed, the DAQ loop reads it and sets the boolean value of the Stop Action Engine VI to True. All loops read this AE on every iteration. If True, the loop goes to the shutdown state(s). A simple AE VI is attached. The simple AE is a VI with a while loop which executes one iteration each time the VI is called. It has an uninitialized shift register which stores the data. The Action input selects one of several cases inside the while loop to perform the action requested on the data.

---

The thing is, the operator should be able to stop the process whenever he/she feels like by hitting a hard start/stop button. If 1 unit fails, the major process for testing other units must go on. Hen ce I had implemented that heatpass2 logic in the subvi.

For my code, can u tell em how exactly should this action engine be implemented?

I'm sorry I have been bothering you'll with petty issues,, but i can't figure this out.

And the confusion is not because of you'll. I'm just generally confused because something new comes up with this project in my code.

[johnsold]

These are not petty issues. They are keeping your program from working!

I am still having some trouble understanding what you are doing.

Let's say you have started all six units simultaneously.

After initialization all six subVIs advance to Dialog1. Each of the six writes the Dialog text to the Step indicator (before or after a 3 minute wait). Then each of them writes an empty string to Step (before or after a 3 second wait). All go to Power ON state where each writes to a different line as specified by the DAQmx Global Channel. Next is the Power Check state. A boolean bit in "data" is used to select Dialog2 or Fuse Check states.

Here is where things start to get confusing (to me). If some units go to Dialog2 and others go to Fuse Check, what happens? First, Step gets "Slide system switch to HEAT mode" from some units and "Check the fuse" from others. Most likely this will happen as fast as each subVI can gain access to the control reference. One of the messages will display very briefly (maybe not long enough to be seen by the user) before being overwritten by the other. The Fuse Check state has 30 seconds of wait and Dialog2 has 33, so the loop iteration will take at least 33 seconds. The user may never have seen one of the messages. How does the user know which unit has sent the message which is seen?

After the Heat Mode state another branching is possible. Now the system could have subVIs in at least three different states and conflicting messages and undesired timing may continue to occur.

Have you drawn a timing diagram or a state chart for this system? Such documents are very helpful in determining what the system should do in these situations and that, in turn, helps the programmer get the code to do what the customer (or boss) wants it to do.

Lynn

[smm]

---

johnsold wrote:
Here is where things start to get confusing (to me). If some units go to Dialog2 and others go to Fuse Check, what happens? First, Step gets "Slide system switch to HEAT mode" from some units and "Check the fuse" from others. Most likely this will happen as fast as each subVI can gain access to the control reference. One of the messages will display very briefly (maybe not long enough to be seen by the user) before being overwritten by the other. The Fuse Check state has 30 seconds of wait and Dialog2 has 33, so the loop iteration will take at least 33 seconds. The user may never have seen one of the messages. How does the user know which unit has sent the message which is seen?

---

So the fuse check is for power. We are supplying power from a separate power unit to the interface. So once power is turned on, it checks if the power is really on or if the fuse is blown. So in the event power is not on, it won't be on for either unit. So I don't see where the dialog conflict for heat mode and fuse check might take place. Please correct me if I'm wrong.

---

johnsold wrote:
After the Heat Mode state another branching is possible. Now the system could have subVIs in at least three different states and conflicting messages and undesired timing may continue to occur.

---

I assumed that it would be parallel execution and all of it would go on together. What happens for one unit will happen for the rest (except in the event a unit fails).

Also I wanted to mention one more detail. The timing that I have used in the VI is required. It incorporates the time required for the heat/cool call and for the capacitor to discharge and things like that.

I don't have a timing diagram or state diagram per se, but i have an inital document on which I had based my design(code) for one unit, which had worked. Only once  I knew the code for 1 unit works did I try to use it for 6.

[smm]

I have been trying to make sense of how the action engine would fit into my design, but somehow it just isn't clear. Do you think it's asking for two much, if I ask you to show me the implementation on my code for maybe one mode atleast please...

I am attaching the new sub vi with the while loop and the main vi without the while loop.

[johnsold]

I will try to put something together as an example for you.

The mux_try9 version won't work. It only reads the Read1 .. Read6 tasks once each before entering the Tstat subVIs. Those DAQ reads must be inside the loops also to be consistent with your earlier VIs.

Lynn

[smm]

So what needs to be done there? Should it be just like it was in the earlier mux try8?

[johnsold]

In the attached files you will find a mux_try_demo.vi which is based on mux_try8_subvi.vi and a Tstat_demo.vi. I replaced all of the DAQmx stuff with "nothing" for the writes and random values for the reads. I reduced the delays to a few seconds rather than minutes. The StateMachineState.ctl is a reconstruction of your typedef because I did not find a copy of yours.

Note that you need to push the Stop Button (simulating the hardware stop) after the Loop Done light comes on. I did not put anything in to automatically stop the loop which monitors the stop button.

Run it several times and watch the front panel. Note that it does not always execute the units in the same order. Notice also that all the delays run sequentially.

Are the Heat_Read, Fan_Read,... arrays supposed to go off after that part of the code has executed?

Which bits of the digital data go to which Units? I could not tell by looking at the DAQ VIs, so the simulation probably does not handle that quite right.

You should be able to see how the Stop Button drives the AE and how the AE stops the main loop. In your system the loop with the stop button would have the Dev1/port0/line6 Digital Read VI in place of the button. (I think that is the one monitoring the hardware switch.)

I think this demo shows some of the things I have been talking about. I have some ideas about fixing these things, but I want to be sure that you and I both understand what you need the system to do.

Lynn

[smm]

Lynn,

Thank you so much for your help. I took a look at the files you sent.

---

johnsold wrote:
In the attached files you will find a mux_try_demo.vi which is based on mux_try8_subvi.vi and a Tstat_demo.vi. I replaced all of the DAQmx stuff with "nothing" for the writes and random values for the reads. I reduced the delays to a few seconds rather than minutes. The StateMachineState.ctl is a reconstruction of your typedef because I did not find a copy of yours.

---

Could you explain to me the reason for replacing the reads  and writes? I know it's for the demo but what are you checking for by doing this?

---

johnsold wrote:

Note that you need to push the Stop Button (simulating the hardware stop) after the Loop Done light comes on. I did not put anything in to automatically stop the loop which monitors the stop button.

---

What does the loop done light do? The hardware start/stop has the following purpose: When the operator hits the start button, the program should start execution (note that at no point do we really let the operator use the Labview "run" button function). Now during the process, if the operator wants, he/she should be able to hit the same button to stop the process. Dev1/port0/line6 Digital Read VI was used as the line to read from the hardware start-stop button.

So the process basically stops in the event that all units are done testing  or the hardware start-stop button is pushed. Also as I had mentioned earlier, if one unit fails during any mode, the rest should still continue to be tested. The process should terminate only when all the units have been tested.

---

johnsold wrote:
Are the Heat_Read, Fan_Read,... arrays supposed to go off after that part of the code has executed?
Lynn

---

The arrays are supposed to stay on after that part of the code is executed. You will notice that in the cool mode, the cool_read is rewritten twice. So those changes will be made but the final values should stay on the arrays.

Also, I noticed that in the Tstat_demo, you mention that a calculation is duplicated again. If you see the Tstat_SubVI3[2] that I had attached earlier, you will see the chages I have made. The thing is that first you rad the cool_read array - the lines, then I do a write operation, which makes a change in the cool_read array and hence is supposed to be checked.

Now let me tell you for the DAQ- PCI 6515, what lines I am using for what purpose.:

Unit 1: P1.0 - Y, P1.1- W, P1.2- GL, P1.3- GH

Unit 2: P1.4 - Y, P1.5- W, P1.6- GL, P1.7- GH

Unit 3: P2.0 - Y, P2.1- W, P2.2- GL, P2.3- GH

Unit 4: P2.4 - Y, P2.5- W, P2.6- GL, P2.7- GH

Unit 5: P3.0 - Y, P3.1- W, P3.2- GL, P3.3- GH

Unit 6: P3.4 - Y, P3.5- W, P3.6- GL, P3.7- GH

Now for the output ports:

P4.0-P4.5 (for units 1-6 respectively) are the temperature change lines. These are intended to use for change of temperature for test purposes. It is used for the mode that is called Reset 93. (3 implies the temperature in Fahrenheit, which will be changed. That means that we check the ambient temperature w.r.t the simulated temperature. These lines are basically used for simulating some temperature like 93 or 47 for checking the functioning of the T'stat.

P5.0-P5.5 is where the power is started to the tsat units. These lines turn power on to the units.That is when a "1" is read at thhese lines, it impies power is on and the process can continue. In a condition where power fails to turn on, the fuse check mode comes to action. This is where the operator is told to check the fuse.

Input ports P0.0-P0.5 check for the above power. They check if the power is turned on to the units. When these lines do not read a high, fuse check takes place.

Thus what I was doing was reading all lines simultaneously (read VIs) and then indexing the arrays to read specific lines for each mode of each unit.

---

johnsold wrote:
Run it several times and watch the front panel. Note that it does not always execute the units in the same order. Notice also that all the delays run sequentially.

---

I did notice that the u its do not execute in the same order. Why does this happen?

---

johnsold wrote:
You should be able to see how the Stop Button drives the AE and how the AE stops the main loop. In your system the loop with the stop button would have the Dev1/port0/line6 Digital Read VI in place of the button. (I think that is the one monitoring the hardware switch.)

---

This is one thing I couldn't follow really well.

I hope I have made myself a little more clearer as compared to before. I really appreciate your help. Ot's great. Thank you so much Lynn. I will be awaiting your response.

Thanks.