Read from Excel File and Write to Digital Port

[Anthony_Wong]

Hi Charlie,

It's been 5 days, and I have not yet resolved this problem yet, can you shed any light on it?

The attached file was in my previous post.  

Thanks for your time and help.  

[Charlie S.]

Hi Anthony,

I cannot apologize enough for taking so long to reply. Our internal database agent stopped working sometime last week and we were not receiving new developer zone post notifications. I took a look at your code, and I believe I've narrowed down the problem to how you are converting the 1D array of booleans into integers to write to the DAQPad. The way you had the code written, it was converting the first 32-bits (essentially all your boolean data) and writing it to both port 1 and port 2. That is, it was writing exactly the same data to both ports, which is why it appeared as though one port was correct, while the other was not.

I have modified the code to "reshape" the 1D array into a 2D array of booleans. Now, each row of the 2D array will correspond to a new port on the board. By performing a modulus (quotient & remainder) function on the size of the 1D array, we can determine how the data should be split between ports.For example,

1 0 0 0

2 0 0 0

will now write 8 bits to two ports.

1 0 0 0

2 0 0 0

1 0 0 0

will write 8 bits to three ports.

1 0

0 1

will also write to 1 port.  I put the modified code as an attachment below. There are some comments on the block diagram, but let me know if anything is confusing.

Hope this helps & thanks for your patience!

[Anthony_Wong]

Hi Charlie,

Thanks for the response, your help is appreciated.

You have solved the mirroring of the outputs to both ports, the reshaped data does not seem to be working as was intended.

I have attached a file ("test2.xls") that you can load when this VI is run (it will load some data).

The parsed data looks something like:

2 0 0
0 1 0
0 0 0

In this case, the raw binary does show that it is being recognized, however, the parsed binary does not recognize this data anymore (i.e. I only see one LED being lit up)  

[Charlie S.]

Hi Anthony,

I looked at the code I posted again, and it appears that I overlooked some use cases. Sorry for the bug! I have attached modified code that should parse the 1D array correctly now. Note that I fill any "extra" lines with zeros. In the example you posted above:

2 0 0
0 1 0
0 0 0

would leave the last six bits (lines) of port 3 set to zero. I hope this clears up some confusion - please let me know if you catch anything else.

Thanks!

[Anthony_Wong]

Hi Charlie,

I get this error when I try to run the VI you posted:

Error - 10010 occurred at Digital Single Write

Possible reason(s):

NI-DAQ LV:  The count is too small or too large for the specified counter, or the given I/O transfer count is not appropriate for the current buffer or channel configuration.

[Anthony_Wong]

Hi Charlie,

I've managed to correct the Error 10010 by restricting the bounds of the Digital Channel List from 0:7 to 0:1 (or however many ports I will actually be using)

Is there any way to set the Digital Channel List to automatically configure itself by (say) reading the number of elements in the parsed array, dividing by 4 and rounding up to the nearest whole number to determine the number of ports?

i.e. If I have a 4 x 6 matrix with 24 cells, I will need 24/4 = 6 ports (a total of 6 * 8 = 48 lines), so the Digital Channel List should be 0:5.

Again, thanks for your help  

[Charlie S.]

Hi Anthony,

I think you may have already answered your own question here! I wrote a quick VI that performs the calculation you just posted and returns with a string with the appropriate channel(s). You may have to modify this slightly for your application, but the idea is there. Let me know if you have questions.

Thanks!

[Anthony_Wong]

Hi Charlie,

I took a look at your code to determine the final port to write to, and it has given me some ideas.

However, while looking at this, I have determined there is a (major) bug in the VI. If the number of cells in the matrix is a multiple of 8 (i.e. 8, 16, 24), an extra port is required.

For example, a 4 x 4 matrix should only require ports 0:3, but the digital channel list must be set to 0:4 for it to work.

Note that I have modified the VI slightly so that a matrix of any size can be accomodated (i.e. m x n dimensions). However the bug still remains (i.e. a 4 x 2 matrix would also require ports 0:2 rather than 0:1).

I have attached the current version of my VI, as well as a 4 x 2 matrix that I have generated just for testing purposes.

Message Edited by Anthony_Wong on 06-22-2006 11:41 AM

[Anthony_Wong]

Hi Charlie,

I did some further testing, and I was mistaken, the error does not occur for multiples of 8, but for multiples of 4.

So a 4x2, 4x3, 4x4, 4x5 and so forth will generate the error that requires it to use up an extra port. So respectively, the port settings would have to be 0:2, 0:3, 0:4, and 0:5.

This means that if I wanted to use a 4 x 12 matrix (theoretically using all 96 lines on 12 ports), it would be impossible, as I would need 0:12, which is impossible.

This problem, however, doesn't occur for any matrix that has a cell count not equal to 4 (i.e. a 5 x 2 matrix would have 10 cells, and is correctly activated with a digital channel listing of 0:2)

[Charlie S.]

Hi Anthony,

It looks as though we are running into a DAQ issue here now. If your matrix is 4x2, that would be 8 cells which equates to 16 lines or two 8-bit ports. You should only need 0:1, not 0:2. To verify that the the driver VI's are mishandling this, can you try to isolate the behavior? It could very well be that we have a mistake in our parsing logic to make the 1D binary array properly formed. However, to be sure, you can try wiring an array of two integers to the DIO Write.vi with 0:1 as the channel list.

Alternatively, you could probe the inputs to the DIO Write.vi to verify that it's not trying to write more than two integers when you have a 4x2 matrix. I've tried playing with the code I posted earlier and I do not immediately see the problem. If you can provide a simple VI that demonstrates the issue, we'd be happy to investigate.

Thanks!