serial only reads 2 characters....

[Zac_Acal]

Hi Guys,

              i am sending data back and fourth between a microcontroler and labview using rs232, but i'm having some trouble with some numbers, it works fine in teraterm but not my labview vi.

If i send "h1234E"  (E is the end char) the micro sends back "1234" as a test to prove that it is extracting the number out of the string... but in my labview vi i send "h1234E" and only get "h1" back.

any ideas ?

[Zac_Acal]

oh yea...

[Mark_Yedinak]

My first thought is that you are not giving the microprocessor enough time to send the data back. If the microprocessor will always echo what you wrote you could have your read look for that amount of data rather than how many bytes are available at the port. When you read the number of bytes available it is simply a snapshot of that instant in time. So, it will say 2 bytes are there even though more data is coming down the line.

[dan_u]

Wow, that's an interesting way to code...

You like sequences, don't you?

Anyway... are you sure 10ms is enough time for the device to respond? What does the "Bytes at Port" say? 2 bytes or 4 bytes? Where do you set the read control?

[dan_u]

Mark was faster 

Another point: make sure teraterm is not running when you talk to the serial port from LabVIEW.

[JÞB]

Is the control "Write"'s mechanical action set to "Latch when..."?

[Mark_Yedinak]

---

dan_u wrote:

Wow, that's an interesting way to code...

You like sequences, don't you?

Anyway... are you sure 10ms is enough time for the device to respond? What does the "Bytes at Port" say? 2 bytes or 4 bytes? Where do you set the read control?

---

I wasn't going to talk about the code itself. It could be improved quite a bit. Certainly most of the sequence structures could be eliminated. At least they aren't stacked sequences.

[Yamaeda]

Slight case of Sequentitis spotted. 🙂

You have nice flow control through the error wires which ensures stuff is done in order, the only sequence frame needed is the wait before Visa Read.

They setting the wait to 100ms and i'm sure you'll get all characters back.

/Y

[RavensFan]

I'd almost guarantee it is that 10msec wait.

I'll assume that the baud rate is 9600 bps.  With parity, start, stop bits.  That is generally about 1000 bytes per second.  Or about 1 msec per byte.  So the most you can get back is about 10 bytes in a 10 msec wait.

Factor in some milliseconds for the other device to get the command, process it, and generate the new message.  Perhaps even the time for the message to write to go out from the serial port, I can easily see getting only 2 bytes.  (What happens on susequent messages?  Do other bytes show up?)

For serial communication, I would wait 100-200 milliseconds before trying to read anything (assuming short return messages.)

[Mark_Yedinak]

---

Ravens Fan wrote:

I'd almost guarantee it is that 10msec wait.

I'll assume that the baud rate is 9600 bps.  With parity, start, stop bits.  That is generally about 1000 bytes per second.  Or about 1 msec per byte.  So the most you can get back is about 10 bytes in a 10 msec wait.

Factor in some milliseconds for the other device to get the command, process it, and generate the new message.  Perhaps even the time for the message to write to go out from the serial port, I can easily see getting only 2 bytes.  (What happens on susequent messages?  Do other bytes show up?)

For serial communication, I would wait 100-200 milliseconds before trying to read anything (assuming short return messages.)

---

The best solution if you know the format of the repsonses is to read the data based on either a known message length (read number of bytes) or read until a known termination character. Arbitrary delays may work but can easily fail if anything in the environment changes such as the BAUD rate. If you must set a delay value then I would at least calculate the delay based on the BAUD rate and the maximum message size plus some fudge factor.