Can you continuously read digital inputs on NI9425?

[sam18]

I'm not sure how to verify this capability of NI9425 module, but here's the scenario: 

1. I have a program to cycle through turning on a panel of LEDs. This seems to be working properly based on an indicator array I have placed on the front panel. 

2. The input to the NI9477 is in an array that is read from shift registers on a while loop. I can see that the array being sent to the card is accurately updating

3. I have the output of the NI9425 displayed on indicators to show whether the LED lit up. 

Only the last state of the array (after all the switching) is displayed on the front panel. In other words, the front panel LEDs are not switching the same way the digital output array is switching. 

I have both processes in the same while loop.

Is this even possible in LabVIEW to read various inputs based on various outputs?

Due to the nature of my work, I can't paste my actual VI, but here's a similar structure (minus the shift registers and continuous switching through all) 

[RavensFan]

Your inner while loop is pointless.  It only runs once since a True is wired to the stop conditional terminal.  Remove the inner while loop and your VI behaves the same.

The rest of the VI is basic.  You read controls, write to a digital output, read from a digital input.  Does this simplified VI demonstrate the problem you are having?

If it does, please explain more clearly how what you expect to have happen differs from what actually happens.

[sam18]

Forgot to remove the true constant on the inner while loop. 

Simplified VI is having a similar problem. If you were to leave the VI running and try to control the panel of LEDs on the front panel with the controls, there seems to be a "delay" or some mismatch. if you turn all the switches on, run VI, then try to control the switches while VI is running, you'll notice that the front panel LEDs don't respond "instantaneously." The LEDs switch after an you click the state of other LEDs. 

The problem captures the essence of the real problem I'm having, which is that the input card only reads the final state of all the LEDs.

Does this explain my problem more clearly?

[RavensFan]

Can you attach your latest VI after you cleaned up the inner while loop?  You say you forgot to remove the true constant.  Did you also forget to remove the inner while loop?

Unfortunately I don't have a DAQ device to test your VI against, but a couple thoughts come to mind.

1.  You are using DAQ Assistants set up for 1 sample on demand.  That means they need to create the task, run it and close it.  Looking deeper into them, that delay of creating the task should only occur on the first iteration, but perhaps it helps explain why you see a delay.

2.  You'd be better off using the lower level DAQmx functions where you open the tasks before your while loop, execute the writes and reads in the loop, and close the tasks after the loop.

3.  You should consider using an event structure so that the DAQmx code executes when it detects the value of any of those boolean switches have changed.

I still don't know what you mean by "final" state of all the LED's.  Final as in after you stop your VI?  You have a 10 millisecond delay in there, which should seem pretty fast to normal human eyes.  How fast are you clicking the switches?

[sam18]

1. This is a good point. Changed my new version to continuously send samples. 

2. Implemented queue/dequeue so data isn't lost. There's a separate problem here that the dequeue only sends 1 element of the 5-element array. 

3. For your suggestion of event structure-- will this work if the value change of each channel on the array is triggered by a text file that's being read and not actual boolean controls on front panel?

By final state of LEDs, I mean that in my main code, the boolean states sent to the DAQ Assistant Output Module is the last state that's sent in a chain of commands. It doesn't continuously send the changing array values into the DAQ. Only the array values in the last iteration. I'm experiencing similar problems with this example one I'm trying to work though. I feel that once I figure out what to do about this, I can implement it into my larger project where the input is an array with continuously changing boolean values instead of 5 boolean switches. 

For example if I send these various values that will be updated into an array through shift registers:

[1 0 0 1 0]

[0 1 0 0 0]

[0 0 1 1 0]

[0 1 0 0 1]

The resulting LEDs turned on only reflect the [ 0 1 0 0 1 ] array. My intended result is for the panel of LEDs to change as the input array changes. 

[RavensFan]

There are some problems with your attachment.

When I opened the project, there was an issue with the only VI in it,  1D Array of Booleans to 1D Digital Waveform was trying to load itself and couldn't find it.  The LED_IO seems to be your top level VI, but wasn't in the project.

That subVI takes a 1-D array.  In then builds it into a 2-D arrays of 2 rows 5 columns when you build an empty array constant onto it.  So now you have row 0 with your original 1-D array, and row 1 being all False.  Then you replace array subset with a True at row 5 column, 1.  The problem is that your array only has 2 rows!

You also have no way to stop your VI.  If you have a DAQ error, the error dialog will keep popping up making it impossible to hit the stop button or the abort button.  You should Or the stop button with error wire.  Also, when you Queue runs out of elements, it will sit there waiting for another element that will never come, and no way for it to read the stop button to end the loop.

Your queue consists of 5 elements of 1-D arrays that are all the same based on what your feed into the while loop when the VI starts.  I see no way that your VI generates those 5 different 1-D arrays you show in the message.

I suggest you need to learn more about LabVIEW dataflow.  Run your VI with highlight execution turned on.  I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
Learn LabVIEW

[sam18]

I reworked the VI to remove unnecessary elements/created an accurate STOP. Now I'm getting these errors. Still don't think the correct numbers of elements are sending/being read/synchronized correctly. I do know how Labview dataflow works but I'm trying to create an example without spending too much time on it which is where the non-robustness/completeness of the VI is coming from. 

What I'm not so familiar with is how I can view the data going in to the DAQ modules? I don't know where to look to find information on timing it correctly with the arrays being updated...

Is this VI iteratively sending my arrays to the output module? Doesn't seem like it. 

Attached the error I'm getting...If i update the index of the array, getting a similar error (different # channels/lines/tasks)

[RavensFan]

Nothing is attached.

[sam18]

Here it is

[RavensFan]

Is LEDIO_Out a task you set up in MAX?  Post a screen shot of that setup.

The error message seems to be pretty clear in saying you have set up a task for a single line, but your data you are writing to the device is for 5 lines.