VISA Write sends continuously

[gatekeeper]

Greetings

I'm writing a simple VI to read data from a FID via RS232.  It is a simple system; upon receiving the command Ctrl+Q (sent as ^Q) the device begins trasmitting its data every second.  On reaching the VISA Write command in my VI, the program hangs until it reaches the timeout.  I've set up a virtual serial port on my computer for testing purposes, using Hyperterminal to monitor the command and send simulated data, and it appears that the Write command is transmitting the ^Q message repeatedly until the program crashes.  It is outside of the main While loop and I cannot figure out why it is behaving this way.  I've double- and triple-checked the serial port configuration settings.  Any suggestions are greatly appreciated.

The program appears as follows:

[MoReese]

What does your VI do when it's executing?  Does it get to the while loop?  How are you controlling the timing of your Visa read?  Your while loop might execute and end before any data is received.

Edit: OK, nevermind, I see your 1S wait.  It's still not the best method for time because it's async.  What does your VI do in highlight execution mode?

[rayclout]

Hello gatekeeper

Does the command require a carriage return following it?

Ray

[MoReese]

---

@rayclout wrote:

Hello gatekeeper

Does the command require a carriage return following it?

Ray

---

Probably not since his termination char is disabled on config Visa.

[RavensFan]

A ctrl-Q is often symbolized as a "^Q" in text, but the ctrl-Q character is decimal 17 hex 11 in ASCII and might represent control code DC1.  It would never show up as a "^Q" in a LabVIEW string.  If your string constant is set for normal display, then you are sending two bytes, the ^ character and the Q character.

Try setting your string constant to hex code display and enter 11.  Or in \code display and enter \11

[MoReese]

Nice catch Raven.  I missed that.

[SteveChandler]

Is this the full extent of your program? I ask because I am curious about the purpose of the while loop. It will iterate one time and stop yet it does not have any shift registers. Are you running this VI directly or is it being called as a subVI?

And forgive the following stupid question. You are not pressing run continuous are you?

[MoReese]

---

Steve Chandler wrote:

And forgive the following stupid question. You are not pressing run continuous are you?

---

That's so stupid I did even think to ask it.

[MoReese]

Also, your wait may not provide you proper timing.  Your Visa read could execute first, which I assume is not what you want.  You should gain more control over you serial by monitoring your bytes coming in.  You can use this as the trigger and is synchronous as opposed to the way your trying to do it.  As Steve has said, your While loop will only execute once so there is really no need to even use it.  Now if you want it to continue to cycle until data is received (which may be what you have been trying to accomplish), your boolean should be a false.  But I advise against that method.  Bytes at Port will tell you when data has been received.

Let's us know what results you find from the other suggestions that have been posted.

[RavensFan]

---

@MoReese wrote:

Also, your wait may not provide you proper timing.  Your Visa read could execute first, which I assume is not what you want.

---

That is probably not a problem the way the VI is written.  It won't matter if the VISA read begins executing right away.  The VISA read will finish when one of 3 things happen:

1.  The termination character is received (though in this situation, that is not going to occur since the serial config was set to disable the termination character.)

2.  The number of bytes requested is received.  So here once 64 bytes come in.

3.  The timeout occurs.  Here it is set for 10 seconds.

So whether the wait occurs before the 64 bytes are in, during, or after, it doesn't matter, as the VISA read will wait until event #2 or #3 occurs.

Now if you do a bytes at port type of read, which I don't find necessary to do very often, then when you wait does matter.  You want to wait before you try to figure out how many bytes are at the port.  If the reading of the bytes at port occurrs right away, you may not have given yourself enough time for any bytes to have arrived.