How to check if data is ready on visa/serial

[rolfk]

I only have one engineering degree, so you win!

Have it your way if you like, I'm done with this!

[billko]

---

@rolfk wrote:

I only have one engineering degree, so you win!

Have it your way if you like, I'm done with this!

---

I agree.  This personality type will argue with you like Daffy Duck argues with Bugs Bunny about duck season vs rabbit season.

[Mark_Yedinak]

---

@billko wrote:

---

@rolfk wrote:

I only have one engineering degree, so you win!

Have it your way if you like, I'm done with this!

---

I agree.  This personality type will argue with you like Daffy Duck argues with Bugs Bunny about duck season vs rabbit season.

---

It's rabbit season.

[rolfk]

One extra information:

---

@Dobrinov wrote:

---

---

Let me get this straight, you are telling me that an explicitly blocking LabVIEW function, while waiting for a timeout, is not going to block the rest of my LabVIEW code? Like, seriously?

---

---

Yes seriously. Just execute a VISA Close on that session from anywhere in your program and your VISA Read will immediately return with an error code. 

[Dobrinov]

---

@rolfk wrote:

One extra information:

---

@Dobrinov wrote:

---

---

Let me get this straight, you are telling me that an explicitly blocking LabVIEW function, while waiting for a timeout, is not going to block the rest of my LabVIEW code? Like, seriously?

---

---

Yes seriously. Just execute a VISA Close on that session from anywhere in your program and your VISA Read will immediately return with an error code. 

---

I thought you were pretty much done here. After all I still have two degrees. 🙂 Doesn't change the fact that it is a blocking function, while waiting for its timeout, but genuinely good to know that if I execute a VISA Close, in parallel, I can interrupt it.

Also, I did some additional research, since you are hardly the only one that cannot seemingly comprehend the difference. Turns out that what you, collectively, regard as a race condition here actually bears a different name - Data Race, where data race is defined, in this particular example, as:

" a memory operation in one thread accessing (reading) a memory location at the same time that a memory operation in another thread is writing to that memory location, in a context where this is dangerous"

According to our friends at Wikipedia, some people do not regard data races to be a subset of race conditions (I sure as hell know on which side of that fence I am standing), but either way it is entirely possible to have race conditions without data races and data races without race conditions (or obviously, both at the same time). Google is your friend, go learn something new.

[Vasilich2004]

1. there is another way to know that there is new data. look VISA Advanced -> Event handling subpanel. It should be the most sufficient. I asked help few years ago here, on the forum. it is possible to find that topic.

2. race condition is absent

- in reading if there is one reader

- in writing if there is one writer

VISA has VIs which help with race condition (VISA Advanced -> Unlock, etc.). I also asked help here. I, personally, don't like its visibility and use Semaphore

3. how to parsing in Reading depends of device protocol

- it is great with device use CR, LN and another end answer symbol

- very seldom device uses exact amount of bytes, for example, Zaber binary protocol

- no well defined parsing standard, for example MetOne device which manual is awful also

- *** additional problem when device sends answers without command, for example, stage sends position once per second 

Good luck!

[crossrulz]

---

@rolfk wrote:

I only have one engineering degree, so you win!

Have it your way if you like, I'm done with this!

---

Hey, I have 2 Engineering degrees too (one is a Masters in Engineering)!  And I can tell you from experience, that means NOTHING.  I have seen high school dropouts code circles around good programmers and I've seen lots of PhDs who couldn't engineer their way out of a wet paper bag.

Anyways, I know from experience that you want to avoid reading everything in the buffer if you can avoid it.  String concatenation, searching, and stripping can get VERY slow (again, I know from experience).  If there is a set protocol, use it.  I have personally found it a lot easier to read the terminal data line by line (using the End of Line character for whatever the instrument is) and sending it to wherever for parsing from there.  The consumer can merge the lines together, parse each line individually, or whatever.  My serial loop does not care.  The serial loop also logs everything that comes across the port for debug purposes, each line time stamped.  I can't tell you how valuable that information was in my last major project.

[crossrulz]

---

@Mark_Yedinak wrote:

---

@billko wrote:

---

@rolfk wrote:

I only have one engineering degree, so you win!

Have it your way if you like, I'm done with this!

---

I agree.  This personality type will argue with you like Daffy Duck argues with Bugs Bunny about duck season vs rabbit season.

---

It's rabbit season.

---

No.  It's Elmer Fudd season.

[Vasilich2004]

=========================

Hey, I have 2 Engineering degrees too (one is a Masters in Engineering)!  And I can tell you from experience, that means NOTHING.  I have seen high school dropouts code circles around good programmers and I've seen lots of PhDs who couldn't engineer their way out of a wet paper bag.

========================

I think PhD should higher probability than MD to solve problem, MS than BS, BS than school student ... 

Of course, all should get education in the same area.

[mcduff]

---

@rolfk wrote:

One extra information:

---

@Dobrinov wrote:

---

---

Let me get this straight, you are telling me that an explicitly blocking LabVIEW function, while waiting for a timeout, is not going to block the rest of my LabVIEW code? Like, seriously?

---

---

Yes seriously. Just execute a VISA Close on that session from anywhere in your program and your VISA Read will immediately return with an error code. 

---

I don't want to get into a Bytes at Port discussion, but the statement above should have a caveat.

The VISA READ will immediately return with an error if VISA Close is executed. However, the VISA CLOSE will not return anything (like an error wire) until the end of the timeout. So now the VISA Close blocks execution of subsequent code.

See the crappy example below.