fast communication using visa / serial

[RavensFan]

In your VI, you are searching for 113 and 114, but you have those constants set for normal display which means 3 bytes of a "1" "1" "3" or "1" "1" "4".  Clear at the constants and enter Alt 113 where you type 113 on your number pad.  Now you will have the byte 113.  If you change the constant to Hex display, that will look like 71.  114 will be 72 in hex display.

Now you know your data always ends with the byte 114.  So enable your termination character and set it for hex 72.  Now read a large number of bytes and it will stop when the byte 114 is read.  However, could 114 be a valid byte in your data stream or checksum byte?  If so, the VISA read would terminate early.  What I would do is inspect the data you received and see what the N byte is and determine if you received all the data.  If so, move on.  If not, do another VISA read and repeat until you determine have received the N bytes you are looking for.

PS.  You have a Stop button wired to the Continue if True termination terminal of your while loop.  That means you wind up pressing Stop for it to run, and leave it alone for it to stop.  That is backwards logic.  Change the termination termina to be Stop if True.

[JoJa]

Thanks Revans,

My data frame is continous and has order like the picture I attached : byte "113" - byte "N data" - byte "Data" - byte "checksum" and byte "114". But the problem is that I have to change byte to read suitable to byte. Firstly, I have ONE byte for header "113", next ONE byte for N-data (maybe it has many bytes) and then the numbers data I want to read. After recieve data from data frame, I have to check ONE byte for "checksum" and finally check for ONE byte Footer. So what can I do to change byte to read suitable to those parameter ?

P.S: Sorry Revans, I can't to change one byte for "113". Could you please tell me about changing it more detail

Regards,

JoJa

[RavensFan]

Take your string constant that has "113" in it.  Right click, then Hex display.  Now you will see it is 3 bytes of 31 31 33.  The ASCII values for the characters 1 1 and 3.  Delete that.  Now enter 71.  You now have the hex value 71 which is 113 in decimal.  If you wind up changing it back to Normal display, you'll see it looks like a lower case q.

I don't know what you mean by "change byte to read suitable to byte."  If you pick the N-byte out of your string, you can use the String to Byte Array function, or use Typecast with a U8 constant wired into the top to convert that string character to a numeric value you can use to determine how many more bytes to read.

[Mark_Yedinak]

Given that your data is continuous I would recommend that you have one task which simply reads data. All data read would be post to a queue. The second parallel task would actually process the data. Use a simple state machine to find the header, then your byte count parameter, then the data, then the check sum and finally the termination character. Continue doing this while you have data. If your data is coming in fast enough and you are not reading it quickly enough the device could encounter buffer overruns and you could potentially drop data. This is quite possible if your data processing takes some time. By separating them you allow yourself to read the data quickly and reduce the risk of dropped data due to buffer over runs.

[JoJa]

Hi, thanks for your reply

I have a problem is to make my VI faster because COM port send data faster than my VI accept so some data will miss

Regards,

JoJa