LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sending data via UART - Too quick, works only with WAITs

I am waiting for the string Hit any key to be received via UART. Then I send want to send two longer strings. If I omit the two wait for multiples of 200ms-constructs I get the string

 

i2c_write -b -0

on my UART. Nothing more. My idea is, that the write buffer can't handle the data. If I introduce the wait for multiples of 200ms-constructs it works.

 

But it's not nice. Is there a way to wait for a signal that my data has been transmitted?

0 Kudos
Message 1 of 12
(793 Views)

You would need a signal that your data were received, instead. However, there is no way to get this information unless the target replies.

Yes the code is rather ugly, however the most important thing is that it works. Beware that the Wait until multiple function can yield unexpected effects (it's more suitable for repeated cycles in a loop): use a normal Wait (ms) instead.

I would try removing the bulk delays and sending the string characters one by one - possibly with a small delay in the loop.

Paolo
-------------------
LV 7.1, 2011, 2017
Message 2 of 12
(776 Views)

 


@pincpanter wrote:

You would need a signal that your data were received, instead. However, there is no way to get this information unless the target replies.

I'm not so sure about this. I have the feeling that LabView writes the data too fast into the FIFO of the UART. I'm not yet talking about the UART transmitting and the RS232 sink receiving.

 

But anyway, thanks for your input. I will either leave it like this or give the send one char individually approach a try.

 

Christian


 

0 Kudos
Message 3 of 12
(736 Views)

The return count output of the VISA Write lets you know the number of characters written.

The only time I needed to do this change (sending characters one at a time), it was due to a very slow receiving device, a radio modem. Not to the UART itself.

 

 

Paolo
-------------------
LV 7.1, 2011, 2017
0 Kudos
Message 4 of 12
(733 Views)

@pincpanter wrote:

The return count output of the VISA Write lets you know the number of characters written.

 


I monitored this output! Smiley LOL If I transmit the very long string 

 

i2c_write\s-b\s0\s-a\s0x51\s-w\s-r\s0x1C20\s0x00\s0x00\s0x00\s0x00\s0x00\s0x00\s0x05\s0x00\r\n

without the 200ms wait states I get the value 77 as return count. This implies, all bytes are written. But still I receive on my physical UART

 

i2c_write -b -0

At the moment I can only assume that my High Quality 7€ UART is to blame. Smiley Wink

 

Christian

0 Kudos
Message 5 of 12
(725 Views)

You do realize the message you are trying to send is larger than the Transmit IO Buffer you set up, right?  That could cause all kinds of issues.  So my recommendations are to get rid of the setting of the buffer sizes and the VISA Open.  None of those are needed.

 

I am also concerned about your termination character.  A colon (Smiley Happy is kind of a weird termination character, especially since your commands end with a Line Feed.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 6 of 12
(717 Views)

@crossrulz wrote:

You do realize the message you are trying to send is larger than the Transmit IO Buffer you set up, right?  That could cause all kinds of issues.  So my recommendations are to get rid of the setting of the buffer sizes and the VISA Open.  None of those are needed.

 

I am also concerned about your termination character.  A colon (Smiley Happy is kind of a weird termination character, especially since your commands end with a Line Feed.


No, I didn't realize the error with the size of the Transmit IO Buffer. Thanks for pointing it out, I will correct or omit it. Regarding the VISA Open and Buffer Size: These VIs are in the Instrument IO-Panel under VISA/Serial. So I use them. They are confusing, because I know that my FIFO has already a HW-Buffer of 14 Byte, but there is nowhere a really detailed explanation how these VISA things work together.

 

Regarding the colon-character: My device sends the following strings

 

Serial Number: 521437076<CR>
<CR><LF>
<CR>
Type         : 52-7006<CR>
<CR><LF>
<CR>
HW-Rev       : 2<CR>
<CR><LF>
<CR>
MAC          : 00:0a:63:05:19:7a<CR>
<CR><LF>
<CR>
IP-Address   : 10.5.25.122<CR>
<CR><LF>
<CR>
IDstr        : 05-19-7AY7006AW521437076<CR>
<CR><LF>
<CR>
Baseboard<CR>
<CR><LF>
<CR>
Serial Number: 800002006<CR>
<CR><LF>
<CR>
Type         : 52-1190<CR>
<CR><LF>
<CR>
HW-Rev       : 0<CR>
<CR><LF>
<CR>
IDstr        : Y1190AW800000000<CR>
<CR><LF>
<CR>

14:40:28.230 [LabView] - <CR>
<CR><LF>
Hit any key to stop autoboot:  1
14:40:29.231 [LabView] - <BS><BS> 0<CR>
<CR><LF>
booting mmc...<CR><LF>

As you can see, after the most important phrase Hit any key to stop autoboot:, on which I want to trigger, there is no <CR> or <LF> sent by the device. And I only have 1 second to send a keypress to stop booting. CR and LF are being sent one second later, but then it's too late. So nothing is terminating my READ in this important phase.

 

I tried to set the timeout to 500ms. This didn't work. Then I tried to set the termination char to colon. This dit work. If you have another idea how to solve this I would be very thankful.

 

Christian

 

0 Kudos
Message 7 of 12
(659 Views)

@crossrulz wrote:

You do realize the message you are trying to send is larger than the Transmit IO Buffer you set up, right?  That could cause all kinds of issues.  So my recommendations are to get rid of the setting of the buffer sizes and the VISA Open.  None of those are needed.

 

I am also concerned about your termination character.  A colon (Smiley Happy is kind of a weird termination character, especially since your commands end with a Line Feed.


No, I overlooked the issue with the small Transmit IO-Buffer. Thanks for pointing it out. I used the Buffer Sizes, the Buffer Flash and VISA Open because they are in the VISA/Serial-Panel. They are a bit confusing, because I know I have a HW-Buffer of 14 Byte and don't know how they work together. I'll try to omit the buffers.

 

Regarding the colon as a termination character: My device sends the following strings:

 

Serial Number: 800002006<CR>
<CR><LF>
<CR>
Type         : 52-1190<CR>
<CR><LF>
<CR>
HW-Rev       : 0<CR>
<CR><LF>
<CR>
IDstr        : Y1190AW800000000<CR>
<CR><LF>
<CR>

14:40:28.230 [LabView] - <CR>
<CR><LF>
Hit any key to stop autoboot:  1
14:40:29.231 [LabView] - <BS><BS> 0<CR>
<CR><LF>
booting mmc...<CR><LF>

14:40:29.513 [LabView] - mmc2: registered mmc2<CR>

After the most important string Hit any key to stop autoboot: there is no <CR> and no <LF>. I have 1 second to send a keypress. By the time my device sends a <CR> and <LF> it's already too late. So I tried to set the VISA Timeout to 500ms. This didn't work. But setting the TermChar to : did the trick. If you have another idea how to solve this problem I would be happy to hear it.

 

Christian

0 Kudos
Message 8 of 12
(701 Views)

Since you can't rely on the termination character because of that one special line within the string, this might be one of those times where you will need to use "Bytes at Port".  "Bytes at Port" is the wrong thing to use 99% of the time.  This might be in the 1%.  Especially since timing is so critical in the communication.

 

Disable the termination character.  Use bytes at port.  Use the small wait (actual Wait (ms), not Wait on Multiple) inside a loop and use Bytes at Port and read that many bytes.  Concatenate what you got with a string of what you've gotten before and maintain in a shift register.   Continually analyze that string until you've found the colon you are looking for.  End the loop and send your key.

 

One problem with you snippet is that you are reading 35 bytes at a time.  Suppose the previous read of 35 got you to "Hit any k"   then when you read the next 35, you'll get "ey :"    You'll never see the entire message you are searching for because you threw away the first part of "Hit any key :" in the previous iteration.

Message 9 of 12
(691 Views)

@RavensFan wrote:

Since you can't rely on the termination character because of that one special line within the string, this might be one of those times where you will need to use "Bytes at Port".


I disagree.  It is proper to have the termination character be set to the colon at the instrument's boot up.  But once we get past that "Hit any key:" mess, use a VISA Property Node to set the termination character back to a Line Feed.  But the number of characters to read in that loop should be bumped way up to probably something over 100.  I am counting 87 characters between colons, so the risk of missing the message is really high.  Just to be sure, I would set it to 200.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 10 of 12
(683 Views)