LabVIEW
Data Loss in Serial Read during Multiple Ports read situation
You've missed the guide line where it says "don't use bytes at port". (For example here: Bytes-at-Port-Property-Node-When-to-use-it-and-when-not.)
That one is evil.
The first iteration of the loop, the 1st device might not have bytes ready. The 2nd iteration had to wait for the 1st, so more bytes will be available. Etc.
Use end termination characters, if they are available. Or read a fixed number of bytes, if the message is fixed size. But do no use bytes at port.
I'd use the for loop's build in parallel execution. That will make the 4 devices read in parallel.
Search LabVIEW like a graph! 
Hi Madan,
@MadanMohan wrote:
I have used all the guidelines mentioned by the seniors in this forum in terms of configuring the ports and reading from the ports and all. But, I need to know why there's discrepancy in my datalog.
Then you need to debug: do you really read the same data for both group of COM ports?
Additionally you also clear any errors: how do you want to detect any problems with reading those COM ports?
On your VI(s):
Use plain ZIP to attach code. (Win)RAR is not used that much and needs to be paid for, while ZIP comes for free with each Windows/Linux installation!
IMHO you are using way too much local variables and references! Why do you use control references to forward values to all those configuration subVIs? Why not use simple wires connected to the control terminals? This would simplify all those subVIs as you don't need to use property nodes to read the "value" from controls…
You should clean up the code: use straight wires, especially for all those shift registers…
Hi Madan,
@MadanMohan wrote:
I'm clearing the errors after the Serial Read because I'm getting the error 'An overrun error occured during the transfer. A character was not read from the hardware before the next character arrived.'
Oh boy…
You get an error telling you you missed to read some data, but your only action is to clear that error message.
Now you wonder about missing data in your log files?
Really?
And you don't even mention this fact in the first place???
@MadanMohan wrote:
I'm not sure how to handle this because I have seperated my data parsing loop to another case in the case structure which was mentioned in another thread for fixing the issue but still it didn't solve in my case.
Read the COM ports more often!
Employ a producer-consumer scheme to separate COM port handling from data parsing into their own loops…
Hi Madan,
@MadanMohan wrote:
And I don't clearly understand how to separate the read loop from other processes. My action sequences in the data capturing is as follows,
1. Get the port config cluster data from the enum ring input
2. Open the file prompt to mention the file name of data log
3. Read the raw data
4. Parse the raw data based on the available data structure as frames read and update it in GUI else add it to the shift register for the future case
5. Log the raw data to the datalog, goes again to step 3 (continuous loop)
Since, the visa read is also a part of case structure according to the sequences mentioned above. I'm not clear on how to take it as separate process.
Put steps 1&3 into it's own statemachine "SM1".
Put steps 2, 4 and 5 into their own statemachine "SM2".
Send raw data from SM1 to SM2 using a queue…
LabVIEW comes with a huge example library. There are also a lot of example projects. There are examples explaining how to implement statemachines, and there are examples for producer-consumer scheme. Please examine them…
.png){kind=link}
Ok, we need to take a step back. What is the format of the data frame? It appears you are using a raw/binary scheme. So for that reason, make sure the termination character is turned off. Next, we need to exact frame definitions to properly read the data.
You might also want to watch this video: VIWeek 2020/Proper way to communicate over serial
