[HELP] problem with receiving data through rs232

[suxu]

    When I connect my VI with MCU (using proteus to simulate), why does it run stable in only 20 seconds? After that, it seem to be unstable. And when I stop simulation in proteus, why does my VI still run and stop after about more than 10 seconds?

   thanks!

[RavensFan]

What do you mean by "run stable" and "unstable"?

Give some specific details on how your VI is not working properly.  Do you get any error messages?

[suxu]

thank you for reply!

there is no error message. in first 20 seconds, values in array are the same. u can see the image in anh.zip (426 and 426), but in the unstable status, they are different. can u open the code in uart.zip? those values are always the same.

[suxu]

can anyone help me?

[Shane-C]

I am not sure which file you are refering to in your zip file that is always staying the same, seeing as how there are a great deal of files in that folder.  Is the VI you included example code from somewhere, or something that you wrote?  I am not sure that I understand this unstable behavior you are describing.  Your VI appears to be simply reading data off the serial port, doing some processing on it and then modifying your images.  One thing I noticed is that you are configuring the serial port with each iteration of you loop, that should not be necessary.  I don't know if that has something to do with the problem, but still.  I saw that there is an array output on your VI, is that the array that is showing you stable data for 20 seconds, and then unstable afterwards?

Shane C

[suxu]

please check this video.

https://www.dropbox.com/s/esbfl8mck5pdyw3/IMG_1343.mp4

it is unstable after forty seconds.

thanks for reply!

[RavensFan]

How fast is your device sending data?

How are you reading data?  (I can't open your VI because it was saved as LV2013)?

Try putting some error indicators on the error wire coming out of your VISA functions.

Seeing the video and seeing how fast data is flying in, I'm suspecting that your device is sending data faster than you are reading it in LabVIEW, you are filling up the buffer, and thus losing bytes.  If you disable the part of your code that generates the picture, does it seem to run any better?

Put in a "Bytes at Port" property node and put an indicator on that to see if the number is staying consistently low, or if it is continually growing.

[suxu]

Reading and sending speed are 9600. you are right, the buffer was filled up, but I don't know the reasons. If I read 22 bytes in Labview, it will run stable for 20s, when I decrease the byte count, the stable time increase. If sending and reading speed are the same, why is the buffer filled up?
When I stop simulation in Proteus, it still run for several seconds before stop (I think, it run by the data in the buffer). But, if I connect with PL2303 module then disconnect, it will stop immediately.

[billko]

May I ask your experience with instrument communications?  With LabVIEW?  We can probably give better advice if we knew.  🙂

[camerond]

---

@suxu wrote:

Reading and sending speed are 9600. you are right, the buffer was filled up, but I don't know the reasons. If I read 22 bytes in Labview, it will run stable for 20s, when I decrease the byte count, the stable time increase. If sending and reading speed are the same, why is the buffer filled up?
When I stop simulation in Proteus, it still run for several seconds before stop (I think, it run by the data in the buffer). But, if I connect with PL2303 module then disconnect, it will stop immediately.

---

It sure would be easier to read your pictures if your wires were somewhat straighter, didn't go backwards, didn't run under other wires or structures, appear to enter subVIs at the wrong terminal, or just appear or disappear at the edges of structures.

If your program stops after approximately 53,000 bytes (422,000 bits) no matter how many you read in a chunk, then I'd look at the sending end rather than the receiving end. But I don't have LV 2013, as many of us don't yet, to look at the VIs you sent in the first message.

Cameron