LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW hang in Serial communication !!

Solved!
Go to solution
Highlighted

Thank you angry man Smiley Wink

as you said I change my mode from run continusly to jast run but still my problem has exist !!! Smiley Indifferent

I don't know what happend to my program. Data on chart and read buffer suddenly freeze and next data isn't show !

0 Kudos
Message 21 of 28
(531 Views)
Highlighted

Before we go any further, I think we have to have a bit more info.  Like, "What is the thing on the other end of the serial connection?" and, "Does it have a manual or a programmer's guide?"

 

If we have those two bits of info, I'm sure we can zero in on what's wrong very soon.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 22 of 28
(523 Views)
Highlighted

I send data from ARM MCU to PC and LV 2013. data is 27 byte and every 10us (minimum time) it changed and updated with new value. thus I must send new data to LV for figure it. but in current design minimum time is approximately 300us. Thus I sent data to PC. In the other programs like hyperterminal every thing is ok and data receive until MCU work but in LV suddenly data read stop and everything like read data, figure on chart pend and I should close LV and open it again.

I put a 5ms delay in my program beetwen each 27 byte sending and LV work longer (approximately 1 minute) and finally freezed again !!  

0 Kudos
Message 23 of 28
(498 Views)
Highlighted
Solution
Accepted by topic author ajapyy

So your MCU sends data all the time without your LabVIEW program having to request any from it!!! Then you have in a loop Bytes at Serial Port and only execute anything if there are EXACTLY 6 bytes waiting!!! Suppose your MCU sends data a little faster than your milliseconds to wait timer in the loop. At some point there will be really more than 6 bytes of data in the serial port buffer and your program loops idling from that point on forever!!!! It could look like the same interval in ms according to your CPU clock but both the timer clock on your PC as well as your MCU are derived from a crystal clock with hardly more than maybe 2000 ppm accuracy and in the case of your MCU possibly extra jitter because of software timers!

 

The right way to deal with this type of scenario is to drop Bytes at Serial Port alltogether and call VISA Read with number of bytes set to 6 and a timeout that is somewhat longer than the interval your MCU sends data. Then everything will go smooth!! As I have kept posting many times already, Bytes at Serial Port in VISA is almost always the wrong thing to use when doing serial port communication.

 

And since VISA Read will then do the throttling of the loop, you can even forget the millisecnods to wait timer completely.

Rolf Kalbermatter
Averna BV
Message 24 of 28
(487 Views)
Highlighted

rolfk wrote:

The right way to deal with this type of scenario is to drop Bytes at Serial Port alltogether and call VISA Read with number of bytes set to 6 and a timeout that is somewhat longer than the interval your MCU sends data. Then everything will go smooth!! As I have kept posting many times already, Bytes at Serial Port in VISA is almost always the wrong thing to use when doing serial port communication.


That is assuming that you don't start the program when the microcontroller is in the middle of transmitting.  You will be out of sync.  So some intelligence needs to be added to make sure you are in sync.  I like the idea of just adding a checksum to the end of each message.  This will be 7 bytes transmitted.  If you fail the checksum, you will need to read some extra bytes and append until you find your appropriate checksum and then go on as normal.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 25 of 28
(475 Views)
Highlighted

Indeed, synchronization will also be important but if that hadn't been done in some way so far (probably manually) then the existing program couldn't have worked at all as it is.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 26 of 28
(471 Views)
Highlighted

well, a short look at your block diagram ...   a case with =6 (or 27?)  ????  what happens when you have more bytes at the port??

 

rethink your code! 

 

 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 27 of 28
(464 Views)
Highlighted

I want to appreciate from all of friends that participate in this post and I finally find my way. I learn many Things in this post.

0 Kudos
Message 28 of 28
(438 Views)