VISA Read isn't polling serial port

[Sam_Sharp]

Yeah, some of the Prolific USB to Serial adapters can be pretty problematic - the ones based on FTDI chips tend to be better. I have a Dell laptop as well and I've never had problems with it not picking up the termination character.

Have you tried checking/setting some of the options on this link? (http://www.ni.com/tutorial/4256/en/) - the one I'm looking at is Number 3 - the behaviour your seeing looks like it could be set to None instead of to stop at the term char. The configure serial port VI sets these options for you, though, so I can't see why it wouldn't be what it says it is.

I would see if I could get hold of an FTDI USB to Serial adapter and/or try the code on another laptop. Have you tried updating the (serial...but perhaps also BIOS) drivers for your laptop? Oh...this is also a long shot, but under 'resources' in device manager, does it show any IRQ conflicts?

[Samuel_Schweighart]

I just tried with my FTDI USB to Serial, and same problem.  I checked, and it is setting that option to (Term Char).

Sam

[Sam_Sharp]

If all else fails, you could periodically (e.g. every 10ms) read all bytes (or read one byte at a time)available at the port into your own string buffer, split the string based on the termination character and feed out the commands yourself.

Ok, so I suspect a software problem (thinking NI-VISA) rather than hardware - can you try running the code on another computer?

[Samuel_Schweighart]

That's what I'm doing. It's such a hack though... 

[Sam_Sharp]

It's only a hack because there seems to be a problem with your setup - there are 1000's of pieces of LabVIEW code out in the wild that use the termination character so there definitely seems to be something wrong with your configuration, hence why I suggested trying to run your code on another laptop. It might be worth doing a repair or reinstall of NI-VISA (and LabVIEW?...although I would try to do the read through NI MAX test panels).

Once you've tried that, I'd be talking to NI to see if there is an issue with that version of NI-VISA etc.

[Samuel_Schweighart]

Problem figured out....

(Thanks to everyone who helped, especially Sam)

My problem was 

1) I wasn't showing all the code for simplicity.

2) The device responds to polled events. I send it a command asking for info, it responds.

3) My read loop is running continuously.

4 ) My write loop is periodically sending out requests for data. (10 Hz)

5) Apparently, you cannot write data to the buffer, if the read block is waiting on data....

What happened, was that there was no data, so the read command would hang.  I would try to send out requestes to the device for data using the write block, but since the read command was hanging, no data went to the write buffer, so the device returned no data, so the read command continued to hang.

Once the read command timed out, the write command unloaded and sent out ~200 requests for data.  The read loop would run, and I'd get all that data until there was no more left.  Then the read block would hang again.

I incorrectly assumed that the READ and WRITE commands were independent and could both happen at the same time.  That is apparently wrong.

Once again, THANK YOU, to eveyone who helped.

P.S. I figured this out using the NI IO Trace.  I saw that there were no write commands going out.

[Sam_Sharp]

If you want to show your appreciation, Kudos the posts from those that helped 🙂

Glad you got it figured out!

[RavensFan]

Not showing all the code did make it harder to solve.  Since you only showed a VISA Read, I had assumed your device was sending data continuously.  Anytime I have a situtation where I need to send a command to request data, then go to read the data, I'm sure to put it in the same loop.  It doesn't make sense to lose a level of synchronization between when a command is sent and when a response is read because they are in different parts of the code.

That being said, I am surprised that the waiting for a VISA Read with no data coming in is effectively blocking the VISA write.  I had never seen that happen before, but I had never written code in a way that would have caused that situation to show up.  I would have thought VISA Read vs. Write wouldn have not blocked each other either.

I'm glad you were able to use the NI I/O Trace tools to narrow down what is happening.  Your efforst have allowed me to learn something today.

[billko]

---

@RavensFan wrote:

Not showing all the code did make it harder to solve.  Since you only showed a VISA Read, I had assumed your device was sending data continuously.  Anytime I have a situtation where I need to send a command to request data, then go to read the data, I'm sure to put it in the same loop.  It doesn't make sense to lose a level of synchronization between when a command is sent and when a response is read because they are in different parts of the code.

That being said, I am surprised that the waiting for a VISA Read with no data coming in is effectively blocking the VISA write.  I had never seen that happen before, but I had never written code in a way that would have caused that situation to show up.  I would have thought VISA Read vs. Write wouldn have not blocked each other either.

I'm glad you were able to use the NI I/O Trace tools to narrow down what is happening.  Your efforst have allowed me to learn something today.

---

I wonder it has to do more with the way a serial port works than how VISA works.