Simple Serial inside a while loop

[MogaRaghu]

The VI below is a simple one that works well under ideal conditions. But as mentioned there in real life there are issues to address. OK one method is to have a logic implemented to do this :

1. Sense the error status.

2. On Error, close the Serial session and then restart the session. 

But I just want a basic clarification... I think the Serial Start / Write / Read functions are blocking type ? Meaning till the intended functions completes or Time out happens the loop is frozen .

I would like o know if there any way of making these non-block type. Like I just initiate a Serial Read  and then go do something else . Once the function completes it lets me know and I do something with the data just received. For those from the embedded world this is a normal way with Processor Interrupts but I am not sure about the Windows world !! Any tips on this ?

[Artem.SPb]

Make 2 loops: 1st for VISA, 2nd for data processing.

This is Application Design Patterns: Producer/Consumer

[drjdpowell]

Those VISA functions have timeout inputs, which can be set to a small number of milliseconds, including zero.

[crossrulz]

---

@drjdpowell wrote:

Those VISA functions have timeout inputs, which can be set to a small number of milliseconds, including zero.

---

No they don't.  The timeout is determined from the VISA Configure Serial Port or a property node.

Back to the original questions...

What you really need is a loop that does nothing but read from the serial port.  Once you get a message, send the data to a processing loop via a Queue or User Event.

Furthermore, your serial port loop should be set up like a State Machine with states like Initialize, Close, and Read.  The idea here being an error will cause a transition to the Close and then Initialize states.

[MogaRaghu]

---

@crossrulz wrote:

---

@drjdpowell wrote:

Those VISA functions have timeout inputs, which can be set to a small number of milliseconds, including zero.

---

No they don't.  The timeout is determined from the VISA Configure Serial Port or a property node.

Back to the original questions...

What you really need is a loop that does nothing but read from the serial port.  Once you get a message, send the data to a processing loop via a Queue or User Event.

Furthermore, your serial port loop should be set up like a State Machine with states like Initialize, Close, and Read.  The idea here being an error will cause a transition to the Close and then Initialize states.

---

Good idea ! I guess the Pseudo code for FSM would be something like this ...

Have five states defined in a Enum control ..

Wait / Init / Write / Read / Close

Default being Wait. 

When user wants the Serial active, he signals Wait.

This transits to Init. 

Upon Init success, it transits to Write.

Upon Successful Write , transits to Read.

Upon successful Read, loops to Write

If at any point there is Error, jump to Close and then back to Init ...

Yes this looks good and gives lot of control options for user to intervene. 

[drjdpowell]

---

@crossrulz wrote:

---

@drjdpowell wrote:

Those VISA functions have timeout inputs, which can be set to a small number of milliseconds, including zero.

---

No they don't.  The timeout is determined from the VISA Configure Serial Port or a property node.

---

Oh yeah, I forgot.  With VISA one does non-blocking by using "bytes at port" to only read the number of bytes immediately available.

[MogaRaghu]

---

@drjdpowell wrote:

---

@crossrulz wrote:

---

@drjdpowell wrote:

Those VISA functions have timeout inputs, which can be set to a small number of milliseconds, including zero.

---

No they don't.  The timeout is determined from the VISA Configure Serial Port or a property node.

---

Oh yeah, I forgot.  With VISA one does non-blocking by using "bytes at port" to only read the number of bytes immediately available.

---

Yes I am aware of that … it kind off lets you know when there is something to pick up from the Serial buffer. But here again I have faced truncated data at times... not sure how or why .. maybe the while loop fires in the middle of a read and cuts it off.  But with the way I have shown ( read after the Termination char ) is far more reliable and always get the full data.

Anyway all this read and Write is fine once the Bluetooth serial link is established. The whole set of problems happen when the link is BEING established or dropped unceremoniously.  A smooth re-connect is what I am aiming at.  Maybe coding the whole thing as a FSM like CrossRulz suggested is the easy way out. 

[crossrulz]

---

@drjdpowell wrote:

With VISA one does non-blocking by using "bytes at port" to only read the number of bytes immediately available.

---

Which you should not do in 99% of the situations.  Use the data protocol to your advantage.

[Minions]

Additionally, you may want to by-pass the VISA Read and avoid the timeout if possible.  Most compliant SCPI commands will only present data for read when the command/query is followed by a '?'.