that helped me understand sending string by serial a bit better now. earlier i had the idea that if each data value can be stored in a single byte then it wouldn't be so much of a problem. i'll be in lab tomorrow so hope to get it solved soon. i've got only 1 week left to complete my project.
anyway i can first show u some samples of data collected earlier which is written to txt file from my VI. the values stored in txt is accurate with no unusual intermediate values like those observed from the table and graph which receives it's values from the array function.
when looking at the text file with standard editor like notepad they look ok. But when using some hex viewer you will notice the zero byte after each number which may disturb the string to number conversion (don't have LV at hand, can't check). In the text you read something like "0 0 " which shows in hex as "30 00 0D 30 00 0D". The 0x00 is a string termination char in C, it's not needed for LV. So either you don't send that zero byte from your PIC or you filter it in LV...
You can easily recognize such things when you switch your "read string" to hex display (right click menu of the indicator).
Best regards, GerdW
using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
hi, so i guess the problem now is due to the zero byte. so how do i solve this problem? i don't really understand how the zero byte occur and is it possible to remove it using C programming since u said it's used as a termination character? or from labview how do i to filter it? really didn't expect that trying to do a simple GUI to read from serial can be so complicated. sorry very confused haha.
maybe the zero comes from this C command: UARTWriteBuffer(szName, strlen(szName)+1);
With my rudimentary C knowledge I interpret this as sending the string with length of the string plus the additional (termination) zero...
This simple GUI isn't the problem, it's the unwanted zero from your PIC! When I get back to my office I will write a small vi demoinstrating the filtering of the zero...
Best regards, GerdW
using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
hi, i've just tested it out with my VI but still having the same problem..
i did some testing with the filter string VI that u made but i found tat the 00 zero byte does not affect the values of the array or even the chart converted from the spreadsheet string to array function. in tat VI i added in some \00 in between some of the values and tested with two displays of each with and without the filter. even without filter, the conversion to array and also from the plotted graph has no difference from the filtered one.
now i'm thinking could it be possible this problem is due to reading speed by labview? i can only think of this possible reason now. i tested sending my signals at a different rate and saw differences in the data obtained. attached are the files from my testing including different rate of data transfer(1ms and 50ms)
new possibility.. do you think baud rate can cause this problem? i'm currently using the default 9600 baud rate for transmission. maybe it's not fast enough? i'm really going crazy with this.. one more week left. arghh so dead 😞
when the conversion is ok than the serial read is the problem...
One more problem found in your code: you read the byte count available at the port and then you read those bytes from the port. When the "bytes at serial port" gives you back zero then you read zero bytes resulting in an empty received string resulting in a zero stored in file and shown in plot... That's why I added the case structure...
I also removed the express vi- there's always a solution only using simple functions
Best regards, GerdW
using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
hi gerd, thx alot for the help so far. i'll test it out when i get back to lab tomorrow. but anyway i was looking through some post about scan string so i was wondering if it'd be easier to solve this problem if i were to include a certain character/alphabet accompanying each of my data and use scan string to separate them accurately. eg. A123\nA345..
cause i'm thinking that i need to do that as well when i'm sending multichannel data by serial even through currently i'm only testing using single channel of my ADC. so that means something like: A123 B345 C20 then use labview to separate the data for 3 different channels A, B, and C. maybe can provide me some samples of doing this?