error -1073807298 with serial read operations.

[AlanK]

Hi Folks,

I'm having trouble getting serial read to work on Labview.When i use the 'property bytes at port' it always seems to return one more byte than i expect (having checked the incoming transmission using an oscilloscope i know i am receiving 10 byte packets with no terminating character). Whenever i then try to read these bytes (any number of them from 1 up to bytes at port) I am getting 'error -1073807298', the error message is pretty non-descript - Could not perform operation because of I/O error.

From reading about on the forums here I suspect it is related to the termination character setup but i have tried all suggestions with no success. As far as i can tell i've got it configured to not require termination characters.

Could someone have a look and confirm i've got the termination characters disabled correctly? Any ideas where the extra byte is coming from when i check the 'bytes at port'? Any other suggestions greatly received.

Cheers

Alan

[JÞB]

I believe you are seeing the "Stop bit" on your o-scope.

[johnsold]

Alan,

It certainly appears that you have killed off any termination characters.

You always read one fewer character than is available.  It might be better to read all the characters and discard any that you do not want.  Seeing Flush Buffer inside a loop usually indicates that the process is not handling all the data correctly.  Since you do not have the error clusters wired, do you know which node is throwing the error? 

Other comments: - The Array property nodes at the bottom of the while loop should be outside the loop.  The data going to them never changes, so there is no need to execute them more than once.

- In the for loop Array[i] AND True = Array[i].  The AND gate does nothing.

- What does the for loop do, anyway?  It appears that it finds the index of the first True element, delays 100 ms and sets the array to a single False element.  Search 1D Array function is what you want. Also property nodes are the slowest way to change the value of a control.  This is an appropriate place to use a local variable. What is the purpose of the delay?

- The case structure with the Read can have the Bytes at Port value wired directly to the selector input. It works fine for integers. The upper case structure in the image below is a copy of the orignial showing the other case.

- You will eventually get a memory overflow error if the user does not clear the buffer, although it may take a long time if the number of bytes received is small. It can also cause memory fragmentation as the size of the string grows.

- You do not monitor the number of bytes received (except as the user looks at the Byte Count indicator).  It is possible that you parse partial packets. It appears that you are using 9600 baud which is about 1 byte per millisecond.  Although unlikely it is possible for the 100 ms Wait in the Write case structure to execute before the Write and Flush functions. Who know how long the OS takes to flush the buffer or how many characters the remote device has started to send while that is happening.  If that buffer is flushed while data is coming in, what happens? Could this be the source of your mysterious error?  Do you always see the correct number on the Byte Count indicator, especially when you get the error?  Does the device send a specific number of bytes for each time you write to it, or can it send data at other times, or continuously?

Lynn

[AlanK]

Hi Everyone, Thanks for the prompt responses. Sorry for the delay, I posted this late in the day forgetting I was heading off on leave over the festive period.

The reading fewer characters than expected was something inserted after i noticed that i was seeing 1 more character being returned from the 'characters in buffer' than i was sending from my external device.

The error is coming when the 'visa read' is called for the first time. The error clusters were disconnected to isolate where the error was coming from.

Cheers for the other comments, this VI is a bodged together modification of a previous one and much of these comments are things that were left from the previous array that havent been cleaned up yet (e.g. AND true used to be ANDED with another variable, constants inside loop werent always constants...). Good points in there though and i will go through and implement when tidying things up.

I'm actually using 115K2Bps, the 9K6 is just the default. I originally didnt include the flush receive buffer and i was still getting the same issue. I introduced the flush to try and clear the mystery byte i was seeing.

I've had some thoughts over the holidays and it occured to me that the mystery byte may be coming from the external device. This unit is intended to work in an RS-485 chain so the transmitter on the external device is disabled when it is not actively sending to allow other transmitters on the bus to send (receive data, enable transmitter, transmit response, disable transmitter). I have seen issues with labview before where it didnt like the sending serial node having its power cycled while the labview is running and i wonder if this could be related. I havent had a chance to test the theory with the hardware yet. I'm thinking that the enabling of the transmitter may be causing a single edge on the PC Rx linewhich is being interpreted as a byte at the buffer. I will test and post some findings.

Cheers

Alan

[johnsold]

Alan,

I have not worked with RS-485, but the scenario you describe seems plausible.

Lynn

[AlanK]

Hi everyone,

Thanks for the assistance. I finally traced the issue to bad setup on the RS485 hardware. The PC Rx lines were left floating under certain circumstances and this appeared to be causing issues with labview detecting spurious data. I pressume that the data being detected had some edges but was failing the parity check and this is what the error labview was throwing was about, although i would have thought in this case the error might have said something related to parity.

Either way, adding bias resistors to the bus to hold the Rx+/Rx- lines high/low respectively when the slave device powers off has resolved the issue.

Thanks for your time and the other useful points picked up in the VI.

Cheers

Alan