want to use visa read only when bits are at the port

[mcduff]

See if this works.

Cheers,

mcduff

[Wolleee]

This is exactly what ill be doing actually.  I also have a termination character though so hopefullyno information will be lost.

Thanks for the help,

Matt

[mcduff]

Typically, with those vis I do not use a termination character. When I use them, it is because I am trying to get binary data from the port or because some instruments do not respect the termination character. (I have had some instruments give a multiline response when the termination character is a newline!)

When the number of bytes at the port does not change, or your timeout value is met, the while loop will exit either to read the data or continue in the VIs I posted.

Good luck.

Cheers,

mcduff

[Wolleee]

Thanks for the help and my termchar is a CR so i should be ok. Havent seen any problems yet and it seems that using the bytes at port with a read in a case structure works well.  I was originally using the visa read and allowing the timeout to control the loop, but i dont really like that method because you have to clear the error every loop iteration if nothing is read.

Thanks everyone for the input,

Matt

[billko]

I'm curious as to why this particular method of reading the serial port?  I consider myself a fairly seasoned LabVIEW developer, but I know there is still a lot for me learn.  Why would a standard producer/consumer design pattern not work better here?

Thanks for all who indulge in answering my query.  🙂

[Wolleee]

Bilko,

You bring up a good point and I've actually used one for this purpose before. But a producer consumer still wouldn't negate the need for polling the serial port. That's really what I was interested in doing. Im not sure if polling the port is typically a common way for effecient communication?

Matt

[billko]

---

@matt198717 wrote:
Bilko,

You bring up a good point and I've actually used one for this purpose before. But a producer consumer still wouldn't negate the need for polling the serial port. That's really what I was interested in doing. Im not sure if polling the port is typically a common way for effecient communication?

Matt

---

Typically it is more efficient to use the VISA write without the bytes at port if you have a termination character you can rely on.  Then VISA Read just waits around until it sees the termination character (or a timeout, of course).  It's also more reliable because it knows when to stop reading (the term char).  But I know there are cases when you want to poll.  I wasn't really trying to make you defend your choice; I was trying to understand it in case I come up against the same thing one day.  🙂

[Wolleee]

Oh it's ok. In this case I will write to the device and the read but sometimes in order to get the character I'm looking for it takes interface from user or automation to the device, who knows how long it could actually take. So I have to poll while I'm waiting because the response times vary. Just kind of annoying. But it's what I got.

[mcduff]

I'll try to answer the questions for my use cases, your mileage may vary:

Why would a standard producer/consumer design pattern not work better here?

Not sure by what you mean here. Is the producer the VISA write and the consumer VISA read? As far as I know, Serial communication cannot be duplexed, ie, you cannot send and receive messages at the same time. The two loops would need synchronization, and have to handle the case for no response from the command.

Then VISA Read just waits around until it sees the termination character (or a timeout, of course).  It's also more reliable because it knows when to stop reading (the term char).  But I know there are cases when you want to poll. 

This is true for most cases. However, consider the case of binary data coming over the serial port, eg, data from an oscilloscope. In this case the binary data may have a termination character in part of its stream. So you may truncate the data unexpectedly. Also, I have had many cases where the instrument response is a multiline string where the termination character is a newline or carriage return, in these cases the data is truncated incorrectly. Admittedly, these are edge cases and not typical cases. So you are correct in your assumptions.

For my use, I like to use the GeneralSerialIO vi I attached earlier. I use it for the following reasons: I do not need to worry about edge cases, it has a read built in, so if there is a message I can retrieve it, but I can use the same vi to set some configuration that does not generate a response. Lastly, I like to use it as a "Stand-alone" vi to test commands that I send to the serial port.

Cheers,

mcduff

[crossrulz]

---

mcduff wrote:

Then VISA Read just waits around until it sees the termination character (or a timeout, of course).  It's also more reliable because it knows when to stop reading (the term char).  But I know there are cases when you want to poll. 

This is true for most cases. However, consider the case of binary data coming over the serial port, eg, data from an oscilloscope. In this case the binary data may have a termination character in part of its stream. So you may truncate the data unexpectedly. Also, I have had many cases where the instrument response is a multiline string where the termination character is a newline or carriage return, in these cases the data is truncated incorrectly. Admittedly, these are edge cases and not typical cases. So you are correct in your assumptions.

---

Here is a situation I have found myself in lately.  I am getting data from an instrument only when something changes.  So say I start the VISA Read with a timeout of 1 second and the data starts coming in after 999ms.  Not all of my data will come in in the 1ms.  So my message will get cut off and I lose data.  Yes, the message is in ASCII and has a termination character.

So I have done what the OP was showing earlier in this thread.  I check the Bytes At Port and use the Greater Than 0.  So if there is ANY data in the buffer, I use the VISA Read as normal and then I will get my full message.  If no data (bytes = 0), then move on and check on the next iteration.  This is a valid way to use the Bytes At Port since I am not using the Bytes At Port to say how many bytes I should read (which is the trap most fall into when using it).

So, Matt, you are on the right track with your post back in message 3.