08-30-2021 12:48 PM
Hey Guys,
i have trouble with my Visa Read.
Already tried to increase the time and Bytes to read.
The Source sends some Device information frequently.
My main goal is to affect the device Information and then read them out over the serial Port.
Hope you can give me some advise.
Im even not sure, if it is the right solution with the sequence structure or if there is a better way.
if there is any more information recommend to help me, i will share them.
Attached my Vi.
Thanks for help gotti
08-30-2021 01:00 PM - edited 08-30-2021 01:08 PM
Hi gotti,
@Gotti wrote:
i have trouble with my Visa Read.
Already tried to increase the time and Bytes to read.
Im even not sure, if it is the right solution with the sequence structure or if there is a better way.
So you get some Timeout errors? Where do you get them? When do you get them? For all cases or just for a specific case?
Does your serial device use the default TermChar as configured by you?
Does it need any commands before sending its responses?
What's the point of those wait functions in parallel to your COM port reading?
Why do you need to clear the COM port buffer each time?
I suggest to:
See this:

Do you really look for a string containing the chars "<\n><\r>"? (Yes those specific chars and not the LF/CR formatting codes…)
Why do you need to check for "==1" and "<>1" instead of using the NOT function (like shown)? Why do you need to negate at all when you can simply switch the look/colors of those boolean indicators (LED indicators!)? What's the point in using 2 LED indicators to show either "no error"/"error" condition? Why not use just one LED?
08-31-2021 05:37 AM
Thanks Gerd. I always appreciate your help.
Just tried with one case.
But at this point i didnt get voltage from the bench, but recieve the messages.
the bench loop works if i copy it in an new vi.
08-31-2021 06:48 AM
Ohh man i just put them in the same loop and it worked. didnt get the point that should be in his own loop parallel.
Did you mean it like that or is this still not the way to go?
Next step would be implementing the other cases and want to write the read data in to a file, but would like to know if this is on its way or i just walk again into an dead end?
greetings gotti
08-31-2021 07:22 AM - edited 08-31-2021 07:24 AM
Hi Gotti,
@Gotti wrote:
Ohh man i just put them in the same loop and it worked. didnt get the point that should be in his own loop parallel.
Did you mean it like that or is this still not the way to go?
The 2nd VI (Neu1) looks different than the 1st (neu), but both have their problems…
The 1st one will not work because you forgot to "THINK DATAFLOW!": when creating independent parallel loops you should not use wires from one loop to the other…
The 2nd one will work (atleast), but now both devices are handled within one loop, which is not my recommendation. You seem to hesitate to create nice looking code with all those bended wires. You should NOT try to configure your device in parallel to reading measurement data from it (those VirtualBench code does it right now)!
What's your problem to create nice looking and compact code?

Btw. I recommend to enable "subdiagram labels" in the LabVIEW options, so you can much more easily add comments to all structures in your code!
08-31-2021 09:31 AM
Hey Gerd,
as you probably know, im not a native english speaker. So at first i have the feeling i didn't get all information you offer to me.
As one of my biggest Problems i installed labview in german and so i didn't understand what you mean with "subdiagram labels". Is it the Beschriftung "sichtbar machen" for each Block?
How do you get smaller Blocks for the led´s then me?
"Provide more information about your Hardware." Means share with you?
I use an Virtual Bench and an ATMEGA16U2 for serial Kommunikation. Although an eletric load didn't mantioned in the last vi´s.
So communication Protocoll looks like(numbers for bytes):
19\n\r
25\n\r
14\n\r
15\n\r
12\n\r
12\n\r
17\n\r
13\n\r
26\n\r
44\n\r
33\n\r
12\n\r\n\r
and repeat .
So the idea is to read out the serial Communication, while simulate and manipulate the akkumulator, so we get the change in the communication and stop the programm. I thougt i can read the massages and search for the change and use this as stop argument for both actions.
Hopefully i explained my self better and you have some more great help for me.
08-31-2021 10:09 AM
You should watch this video: VIWeek 2020/Proper way to communicate over serial
08-31-2021 10:38 AM - edited 08-31-2021 10:43 AM
Hi Gotti,
I guess we both speak German fluently…
(Currently the German www.labviewforum.de is down, but you might post your questions over there to discuss them in German once it is available again.)
@Gotti wrote:
As one of my biggest Problems i installed labview in german and so i didn't understand what you mean with "subdiagram labels". Is it the Beschriftung "sichtbar machen" for each Block?
Subdiagram labels are "Unterdiagrammbeschriftung" in German. They are an option in the "Sichtbare Objekte" context menu of any structure, and there is an item in the LabVIEW options to enable them by default.
@Gotti wrote:
How do you get smaller Blocks for the led´s then me?
By switching off the "Als Symbol anzeigen" item in the context menu of the terminals. There also is an item in the LabVIEW options to switch off this setting globally - I guess almost every experienced LabVIEW developer will do this…
@Gotti wrote:
So communication Protocoll looks like(numbers for bytes):
19\n\r
25\n\r
14\n\r
15\n\r
12\n\r
12\n\r
17\n\r
13\n\r
26\n\r
44\n\r
33\n\r
12\n\r\n\r
and repeat .
Your Atmega probably does NOT send the chars "\", "n", "\", and "r", but will send the bytes 0x0A and 0x0D (LF and CR chars). That's why I already told you to enable the "display mode" ("Anzeigemodus") indicator for string constants (as shown in my snippet)!
There's a huge difference of "\n" between "default" and "\-code" display mode!!!
You should define CR (aka 0x0D aka 0d13 aka carridge return) at the SerialPortInit when you want to use a TermChar as is recommended in the linked video in the previous message!
09-01-2021 12:51 PM
So i watched the video and need to ask some questions.
I already receive Data, so i think my Problem is more that it cut it into pieces, cause the termchar is enabled by default. As i run the Programm it shows me 1 part of the stream, cause its terminated by \n\r and the repeated part is terminated by \n\r\n\r, but i cant define it as termchar. So is there a way to get one Block of the stream.
Already tried to improve the parallel loop and at the little hacks gerd shows me , but not sure if its like Gerd explained, i will try it tommorow.
Is it possible to Write the stream into a file?
09-01-2021 01:20 PM - edited 09-01-2021 01:27 PM
Hi Gotti,
@Gotti wrote:
I already receive Data, so i think my Problem is more that it cut it into pieces, cause the termchar is enabled by default. As i run the Programm it shows me 1 part of the stream, cause its terminated by \n\r and the repeated part is terminated by \n\r\n\r, but i cant define it as termchar. So is there a way to get one Block of the stream.
Yes, the problem really is the way you parse those messages!
Please reread my messages #2 / #8 (the sentences about setting the display mode of string constants, as shown in the snippet! The same applies to numeric constants, as can be seen in the snippet below.) and #8 (the sentences about defining the TermChar). You really need to take care of those little things!
You also forgot to enable the subdiagram labels…
Try this:

Until now you used LF (aka 0x0A akd 0d10) as TermChar: you still got each message, but with a leading CR char (aka 0x0D aka 0d13). That leading CR char might disturb your string parsing routines afterwards…
@Gotti wrote:
Is it possible to Write the stream into a file?
Yes. Just do so and write all received data to a (text) file!