Serial port issue - Not identifying.

[MogaRaghu]

Got a small application to send a char string from LV to  a Arduino Nano via Serial Port. 

LV sends a pre -formatted String.

The Arduino Nano receives it and sends a OK acknowledgment back to LV. The code for that is attached.  All was working fine till suddenly i lost connection and when i refresh the Serial Port i get an image as below :

Does the above mean that the specified Serial ports are not available ? I know for sure that my Nano is connected to Port 12 but when i try to connect i get an error 

SO what is happening ??

[aputman]

I'm not sure what that symbol means.  Maybe the port is still in use.  If so, you may need to restart your computer to release the resource. 

Don't use the Bytes at Port node.  You already specified that the device's response should have a TermChar (LF).  Set the number of bytes to read to a value larger than what you would ever expect to receive, and you will receive everything up to the first LF.  Use the Trim Whitespace VI to remove any white space characters from the end of the response and then compare to the OK message.  Much cleaner than building a string with CRLF appended and comparing to that. 

[crossrulz]

---

@aputman wrote:

I'm not sure what that symbol means.  Maybe the port is still in use.  If so, you may need to restart your computer to release the resource.

---

The symbol means that the port is reserved by somebody.  This typically happens when people forget to close the port in their code.  If a VI opened it, then you just need to shut down LabVIEW to release the port.  If another application, then that other app just needs to be closed.

[MogaRaghu]

Been doing some trials and accidentally noticed this : If I start the VI with the "Highlight Execution" on, the whole process of course slows down and I can see that the responding client settles down well within one or two iterations..and thereafter the link is rock steady even if I switch off "Highlight Execution"

But the very fact its happening like this denotes that the VI needs a initial period to settle down and link up. 

Your point on not to use the "Bytes at port"is a bit of surprise .. is it not supposed to do exactly what you described otherwise ? 

On the symbol - when the two PCs are shown that port does not link. I do not know what it means though. 

thanks for your time. 

[MogaRaghu]

---

@crossrulz wrote:

---

@aputman wrote:

I'm not sure what that symbol means.  Maybe the port is still in use.  If so, you may need to restart your computer to release the resource.

---

The symbol means that the port is reserved by somebody.  This typically happens when people forget to close the port in their code.  If a VI opened it, then you just need to shut down LabVIEW to release the port.  If another application, then that other app just needs to be closed.

---

Agreed. It does denote that two PCs are linked on that port. But the best I can do is re-launch my LV code or even re-launch LV. Beyond that restarting the PC to release the resource looks not practical. 

As to closing the Client App... I am not clear. If I shut down my Arduino App then what is the LV code going to talk with ??

For sure I know you are trying to convey something but I am not getting it....

[Kyle97330]

It's not that using "Bytes at port" is going to cause problems in your specific code right here, but it's a bad habit to get out of in LabVIEW if you don't absolutely need to use it.

The only time you should use it is if you're getting data from a serial port, and:

1. The device is sending a large amount of data and you want to start processing it before all the data arrives, OR

2. The device you're talking to sends data in arbitrary lengths and doesn't have a termination character

Right now that 0.1 second wait time is enough that you're probably going to get what you're looking for, but I've used devices that take 400 ms to respond to a query sometimes and 10ms the next time (waiting for an internal clock tick...) and it's always better to use the method "read until you get all expected data" instead of "wait some amount of time, then read everything without checking to see if it's all there".

[crossrulz]

---

MogaRaghu wrote:

As to closing the Client App... I am not clear. If I shut down my Arduino App then what is the LV code going to talk with ??

---

Your Arduino should not need you to have your Arduino development open in order to run the sketch you loaded to it.

As far as Bytes At Port, I just went through the big explanation with somebody else.  In short, it causes weird race conditions where you will get partial messages.  Since you are using the Arduino, all of your messages to the computer should use the Serial.PrintLn.  That appends a Carriage Return and a Line Feed to the message.  Then in LabVIEW, you just use the default settings for the termination character from the Configure Serial Port and read more bytes than you ever expect in a message.  The VISA Read will read until it reads the number of bytes it was told to or it reads the termination character.  The all but guarantees you got a complete message that you can properly process.

[Minions]

We use the Bytes at Port function more for a built-in communication overhead wait.  We want to know that the instrument has received the command, processed the request, completed the function, built its response, and has begun to respond.  We then perform a VISA Read at that point.  Sometimes it is in a handshaking fashion expecting a particular byte or stream on which the code responds in kind.  I have attached a snippet here.

[MogaRaghu]

Thanks to all who responded. Have modified the VI as below in line with the sample given by Minions. This one works .... the 2 sec delay in beginning is required to allow the Arduino to settle down. The one more thing that still needs to be implemented is the Auto recovery from an interrupted Serial link ...but that is easy by checking the Error out from the Serial Read. Any improvements required on below ?

 

[pincpanter]

The 2 s wait is useless. You already setup a 5 s VISA timeout for this purpose, no need of a fixed time.

Dropping the delay, you get the response as soon as it's available.