hardware push button

[RavensFan]

I think you would be able to duplicate your read functions that are outside the loop and move them inside.  They would use the same purple task wires.  Sometimes this won't work and Labview will raise an error about conflicting resources.  But I think that would happen if you were reading multiple samples at different places based on a clock.  Since these are all single point reads and aren't based on a clock, I don't think that would happen.  You'd have to try it to find out.

Another alternative would be to put the status of the digital inputs into another action engine.  Since you already have one of those in your program now, you are probably getting some experience with them.  Set up your DAQ tasks to run in a separate, parallel loop.  The values would be fed into an action engine to store the current values.  Use multiple copies of the action engine to read the current values of whatever inputs at any location where you need them.  This will allow the action engine to be write once, read many without  having a read many on the actual DAQ hardware.

[smm]

---

Ravens Fan wrote:

I think you would be able to duplicate your read functions that are outside the loop and move them inside.  They would use the same purple task wires.  Sometimes this won't work and Labview will raise an error about conflicting resources.  But I think that would happen if you were reading multiple samples at different places based on a clock.  Since these are all single point reads and aren't based on a clock, I don't think that would happen.  You'd have to try it to find out.

---

So are you impying that I should use 6 read daqms with 6 create channels inside the while loop? Alos if you look at messages 56 and 57, I tried somehting similar. Only instead of create channels and individual lines, I had used global channels for the lines, but in msg 57 Lynn suggested that it would not work since the lines would only be read outside and not inside the subVI. So could you tell me if I'm thinking the correct thing

---

Ravens Fan wrote:

Another alternative would be to put the status of the digital inputs into another action engine.  Since you already have one of those in your program now, you are probably getting some experience with them.  Set up your DAQ tasks to run in a separate, parallel loop.  The values would be fed into an action engine to store the current values.  Use multiple copies of the action engine to read the current values of whatever inputs at any location where you need them.  This will allow the action engine to be write once, read many without  having a read many on the actual DAQ hardware.

---

Again Lynn really did the AE and I tried to figure it out but almost in vain. So I'm not entirely sure how to do thi. Also the hardware start-stop which emplys the AE, is not reading the signal from the board?

[RavensFan]

---

smm wrote:

So are you impying that I should use 6 read daqms with 6 create channels inside the while loop? Alos if you look at messages 56 and 57, I tried somehting similar. Only instead of create channels and individual lines, I had used global channels for the lines, but in msg 57 Lynn suggested that it would not work since the lines would only be read outside and not inside the subVI. So could you tell me if I'm thinking the correct thing

---

Yes you can.  The problem in your msg 56 where Lynn said it wouldn't work is because you had the while loop inside your subVI, and the Read was occurring before your sub VI, thus before your while loop.  Thus you never read again.

Now with the subVI being a true statemachine, it runs through once, and it is inside the while loop.  But the only read you have right now is of the stop button line before the main while loop and in the parallel running while loop which updates the action engine.  So the start stop hardware button is being read once in that loop and updates the action engine variable.  That action engine is read wherever it is needed whether it is once or multiple times.  So your reading of the hardware stop button should work fine.

You need to add back in all of the reads of the other lines.  These would all be in the subVI T-stat which would all be effectively inside the main while loop.  Look at Lynn's T-stat demo VI.  You'll see notes scattered through out that say  "Digital Write
Bool, 1Line, 1Point"

It is here where the DAQ reads will go for your lines that you are testing.  In  Mux try 9 you called those tasks Read1 through Read 6.

One thing you may need to do is create the DAQ task constants that define the lines for each of the 6 tests and pass that into the T-stat subVI so that it reads the correct DAQ channel for each of the 6 instances of the subVI.

[smm]

This is the modified version of the demo versions with what I interpreted to believe what you were saying. Could you please take a look. I have attached the modified main VI and the subvi.

The main vi looks like a jungle of wires again, but that is onnly because of the create and read daqmxs. The rest is according to Lynn's demo version.

Also the start stop button does not seem to funstion well. I had to negate the logic to get it moving. I don't know why it wasn't reading it. Also could you tell me what the while loop witht he simulated stop button does? And id it the same thing as the stop in the main while loop(near loop done)

[smm]

---

Ravens Fan wrote:

One thing you may need to do is create the DAQ task constants that define the lines for each of the 6 tests and pass that into the T-stat subVI so that it reads the correct DAQ channel for each of the 6 instances of the subVI.

---

Could you also tell me what this means?

[smm]

On testing this I keep getting the error:

"Error -200463 occurred at DAQmx Read (Digital 1D Bool NChan 1Samp 1Line).vi:2
Measurements: Specified read or write operation failed, because the number of lines in the data for a channel does not match the number of lines in the channel.

If you are using the Digital Waveform datatype, make sure the number of lines in the digital waveform matches the number of lines in the channel. If you are using boolean data, make sure the array dimension for lines in the data matches the number of lines in the channel.

Number of Lines in Channel: 5
Number of Lines in Data: 1

Task Name: _unnamedTask<10>"

What am i supposed to do to avoid this error?

[RavensFan]

---

smm wrote:

This is the modified version of the demo versions with what I interpreted to believe what you were saying. Could you please take a look. I have attached the modified main VI and the subvi.

The main vi looks like a jungle of wires again, but that is onnly because of the create and read daqmxs. The rest is according to Lynn's demo version.

Also the start stop button does not seem to function well. I had to negate the logic to get it moving. I don't know why it wasn't reading it. Also could you tell me what the while loop witht he simulated stop button does? And id it the same thing as the stop in the main while loop(near loop done)

---

That is one the right track.  But a couple of key points.

1.  Create the channels outside of the loop.  Don't create them inside.  It will cause you to eventually run out of computer resources as you repeatedly create the same DAQmx references.

2.  When you add the new DAQ functions, don't forget to put the error clusters in line with what is already there.  Right now you have strands of error wires going nowhere.

3.  Please don't set the VI properties to Run when opened.  It causes it to run automatically, and I and the others don't have your DAQ hardware thus we get immediate errors.

As for the stop button.  What is wrong with its function?  If you recall, a while back in msg 35, I had mentioned that one place or another you would have to invert the logic of the boolean.

One question is what state of the button means what.  Is a button pressed and closed mean stop or does it mean go?  That would of course affect your logic.  And also what should be the initial state of the boolean in the action engine.  And whether you invert the logic for the initial wait loop, or for the stop of the main operating loop.

---

smm wrote:

---

Ravens Fan wrote:

One thing you may need to do is create the DAQ task constants that define the lines for each of the 6 tests and pass that into the T-stat subVI so that it reads the correct DAQ channel for each of the 6 instances of the subVI.

---

Could you also tell me what this means?

---

You have done this in your latest VI's.  You have passed in a set of task into the sub-VI so that the subVI know which said of lines to read or write to  when you do the DAQmx functions inside the subVI.

I have cleaned up your code.  See attached.

Message Edited by Ravens Fan on 02-26-2008 10:21 AM

[RavensFan]

---

smm wrote:

On testing this I keep getting the error:

"Error -200463 occurred at DAQmx Read (Digital 1D Bool NChan 1Samp 1Line).vi:2
Measurements: Specified read or write operation failed, because the number of lines in the data for a channel does not match the number of lines in the channel.

If you are using the Digital Waveform datatype, make sure the number of lines in the digital waveform matches the number of lines in the channel. If you are using boolean data, make sure the array dimension for lines in the data matches the number of lines in the channel.

Number of Lines in Channel: 5
Number of Lines in Data: 1

Task Name: _unnamedTask<10>"

What am i supposed to do to avoid this error?

---

This is related to the DAQmx Read that is ahead of the subVI for the Unit 5.  (Because of the :2 in the name, you have to look for the 2nd cloned instance of the DAQmx read VI.)  It's not jumping out at me as to why you'd get this error.  It looks like you have 5 lines in the channel.  I don't know why it thinks "1 line in the data".  Try running the cleaned up code and see if the error returns.  If it doesn.  But a Diagram Disable along that whole string of routines for that unit 5 and try again to see if you get the same error somewhere else.

Reenable it.  Put some probes on that error wire in several places to see if you are truly getting it at the DAQmx read or somewhere else.  It's going to take some debugging.

[smm]

I modified it again to combine the mux try 9 and mux demo versions. Could you take a look and tell me if it seems correct. I am trying to check it out but turns out there was a small error in the hardware. but i'll correct that in a bit, and thne i need to hopefully see correct results.

[smm]

I ran the cleaned up code you sent.   I am still getting that error. I will try deebugging thought but still. Also Ihave my hardware running well.

I tried testing the other version I sent mux_try_demo[4]. But for some odd reason it goes from power on to fuse check. Whihc implies that the power is not turning on, whihc i s not true since the led's which I have put for testing on the hardware are on indicating that the power is reaching the units. I dont know why the power is not turing on from the code DAQ?