hardware push button

[smm]

I think the error is with the daqmx read. I broke it down to test just one unit instead of 6. I kept it as simple as possible without the start/stop button anything. Just one while loop with 1 subvi and the read daqmx and create channel outside the loop. It still gives me that error. I think it cannot comprehend lines coming in from two ports. I maybe entirely wrong but thats just my guess.

Can you help? Sorry to keep bothering you over and over again.

[smm]

I have been trying to test one unit as of now before jumping into all 6. So as of now I have notived that the mux_try_demo[4] atleast doesnt throw the error of the daqmx read since it uses the task made from MAX.

But for some reason the power on is not taking place. IIf I cannot get power on then the code won't progress. Do you think the way it is defined Read1...Read6 is what is causing the error? It is not a global virtual channel in MAX but a DAQmx task. Please advise.

[RavensFan]

It is definitely good to take a step back and just work on one at a time instead of 6.  (I think someone even suggested early on to get one test unit working before expanding the program to 6.  )  It may be because the the reads are defined across different ports.  The definition in MAX may handle it differently.  No one in the forums will be able to troubleshoot this for you because we don't have the same DAQ hardware as you do, or real world hardware to attach it to.

Pick one path of either defining your read operations either in MAX or in your program.

Try to read just one port at at time to see if that works.  Add another port.  If that causes errors, try to read the other port in a different read operation.

Once you know you can read all of your ports or channels of interest, then manipulate the data as necessary to pass it into your sub-VI's.

Message Edited by Ravens Fan on 02-26-2008 05:31 PM

[smm]

So I have been debugging the code. But I know for a fact (or atleast I think that is it ) that there is one problem witht he index arrays. My problem is, if you see the heat mode for example. In the flat sequence structure,the 1st frame has a write daqmx vi. And the array subset vi in the next frame has the data line coming from the putside (the main vi inherently). Now the operation that the write vi does, actually changes the data read. But as of now because I cannot show that the write vi comes before the array subset, i cannot see the change. Hence reads incorrect results.

I want to be able to make the write vi run first and change the data read instead of the write vi and data read run in parallel.

[smm]

My question refers to this subvi.

[RavensFan]

Best bet would be to take that Heat mode and break it into 2 separate states.  The first state  to run (call it heat mode A) would be the one that writes the boolean then it will tell it to go to Heat Mode B next  The sub VI will exit.  The main loop will iterate.  The DAQmx reads will happen again.  The sub VI will reenter as Heat Mode B and in that state you will do all the stuff in your second sequence.  That will tell the next state to be Dialog 3 like it does now.

[smm]

That is exactly a good idea and it seems to wrok. But you see, the heat mode is just a precursor to bigger prblems. The cool mode is where the major issue lies since there are about 3 writes on which consequent reads depend.

Having said that, my problem as of now also seems to be that the LEDs on the front panel (heat_read, cool_read....etc) do not illuminate for the correct signals even though the mode passes. It shows the 1st and 3rd led on often (1st i.e top LED almost always on).

I think its the read1 lines, that I am reading are in some conflict. Initially I had it set up to read from the mainn VI via the data control.

Then for testing purposes I disconnected the data terminal and instead am reading it individually in each mose as in the attached VI.

Do you think you could take a look and tell me what could be wrong.

Thanks.

[smm]

Ok so now I know for a fact my code works for 1 unit. It;s dng what is hould. I am attaching my updated code for 1 unit wid the subvi. The only thing that I cannot do is make the LED's stay on. The lights go off once the mode ends. I want the LEDs to stay on after the mode completes as well. Could you help me witht his. Once I get it ready, I want to test for multiple modules eventually.

I figured working with individual reads in every mode works better.

[smm]

In message 66 Lynn said:

---

-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.

What exactly does this imply. What am i supposed to? I'm sure this will work but I can't follow what Lynn was saying

[smm]

I tried them all together along with the start stop button and all that and it all works. Thanks to you guys. But I still ahven't been able to figure what to do with the unit in. I know lynn said that it's supposed to be connected to a shift register but when I connect the unit in htp the left or roght wall of the while loop, it gives me a broken line and an error saying you are connecting 2 different data types.

Also why don't the units get tested in order. As in the states run randomly for any unit instead of doing a unit 1, unit2....unit6. It runs randomly like unit6, unit3, unit4, unit5, unit2, unit1 etc.

Please help.