(Hex 0xBFFF003E) Could not perform operation because of I/O error.

[ggoatman]

I am seeing this error in the code attached.  I have tried to implement the fix using the following link

http://digital.ni.com/public.nsf/allkb/60DDFED7EFEFE7188625705700750821?OpenDocument.

 to no avail.

I am at a loss as to what is happening; this is a very very simple VI that is not yet even close to completion but all I am doing is starting up said board and waiting for an initial power up string to appear and I check for 4.8.0 in the string.  Where the Error first occurs is after the first read in the case structure that is looking for the start up string.

The while loop with the empty case structure is for furture commands, so there is nothing in there at this time.

Anyone have any ideas as to what my issue could be?  I feel this has to be something stupid that i am doing incorrect.

Thanks,

Bill

[RavensFan]

Are you sure the rest of your serial parameters are correct?  (data bits, stop bits, parity)  The correct VISA resource is selected?  Do you want the termination character enabled?

Are you sure you need to flush the VISA buffers?  I have never found a case where that would be necessary.

One odd thing about your VI.  Why do you convert the string "4.8.0" to a number, search for that in the string, and also turn the result of that search into a number.  It will turn out to be just 4 since the datatype is integer.  If you want to see if 4.8.0 shows up in the string, just search for it.  The offset past match terminal will return a -1 if it doesn't show up in the string, so just do a boolean test on that.

[ggoatman]

Thanks for the criticism Ravens fan, I appreciate it, being that i am somewhat of a novice with LabVIEW it helps. 

"VISA:  (Hex 0x3FFF0006) The number of bytes transferred is equal to the requested input count. More data might be available."

The above warning I got to appear when I restarted the computer and ran the test again.  I then set the expected bytes by hand and the original error appeared again.

Thank you for pointing out the dumb mistake I had with my converting to a number, I am still trying to figure out why I did that...I think I was going to try putting this into test stand for some sort of numeric limit test, but ya I don't need it.

I don't Think I need the flush buffer either here, I took it out and still no help with the error.

Also, what I didnt state in my first post was that the data is being given to me at the port, so i can perform my string test on the data in the buffer, it's just after the read the error appears so I can not continue executing the rest of my code without passing the error (Yes I can just clear the error, but that seems to not be a smart thing to do).

I also have the right port settings set and I have had problems with termination characters in the past screwing up my vi's with this particular board so I just automatically disable the termination character.

I am wondering if there is a flush buffer call in the Visa read vi?  Would this cause me my error?

Could null characters in the data being sent back give me the error?  My data from the buffer is as seen below in code display

\00\00XXXXX\s"XXXXXXXXXXX"\s\s4.8.0\sFT\r

[RavensFan]

That message is not an error but just a warning.  The error code is actually a positive number (when looking at it in decimal instead of hex.)  A true error is a negative number.  It means you asked for 15 bytes and received back 15 bytes, but there could be more data in the buffer than that.  You can safely ignore that warning and it shouldn't prevent any other code from running.  It is a little bit annoying of a warning because it is warning you that you got back exactly what you asked for.  But it is typical when you are using the Bytes at Port method to return a specified number of bytes.

I don't think null characters are giving you any kind of problem unless somehow you are getting them and not expecting them and it inteferes with your string display.  If you were reading a binary string of data, null bytes would be a normal expectation for the data stream.