Serial port: Input/output signal errantly combined

Question

I am currently in the process of using LabView to replace another user interface for a scientific instrument.
LabView is connected to this instrument through a serial port.  The instrument streams 25 bytes of binary data every second to the computer.  I can read the binary string (VISA Read) and save contiuously to disk using a while loop.  In addition, there are a few instructions I can send to the instrument that will do various functions (start logging, turn LEDs on/off, etc).  I can successfully send these instructions to the instrument using the previous interface, and in a stand-alone vi using VISA Write, but when I place the VISA Write function into the larger interface vi, signals go haywire.  Specifically, there are two separate LEDs that I can toggle with two different commands, but when in the larger interface vi, both commands toggle the same LED.  Also, it appears that the singal I send to the instrument (a single ASCII character) immediately bounces back to the computer into the 25 bytes of streaming binary data.  In other words, after I press the LED "on" key, one column of my streaming data changes when it is not supposed to (ex: after Binary to ASCII conversion, it changes from a single digit to a twenty digit value).
Initially, I thought the problem was the sequence of VISA Read/Write.  In the current configuration, I read all data, then allow for Write commands.  Both the VISA functions are within the same While loop to continuously monitor the data.  Is it possible the Write signal output is not leaving the while loop and being read as input?  What would make the instrument read two different commands as the same one?  My goal is to run an interface that displays the streaming data as ASCII, and allows for a few different toggle options while the interface is running - is there are more efficient/elegant way than a while loop?
~Going Bananas
Solved!
Go to Solution.

Answer 1

New replies now in gray.
CodeMunkee wrote:
1.  If you keep giving me good advice like this, I'll be tempted to change the background to Baltimore prison purple.
I'll ignore this statement.
2.  The buffer now lives outside the loop.  I understand clearly.  Part of the problem might be my instrument - when I cycle power the 19 digit number that was 'echoed' disappears.  Forget about that display stuff, it works properly - I accidentally removed the time delay when editing the vi.   But you do bring up an interesting point...
Without the delay, the loop ran much faster.  If the bytes weren't at the port, the read statement would have returned nothing when it read zero bytes, thus blanking out the indicator rather quickly.
Yes, Hexadecimal display shows 04 to indicate the end of the 25-byte data sample.
Doing a bytes at port read is not always a good idea.  If not all the bytes had arrived yet when you ask for the read, you won't get all the data.  The remaining data being sent in that stream from the instrument will show up at the front of the buffer on the next read command. 
While this isn't a common occurence, it does happen.  How can I prevent this from ever happening?
Since you know each commands ends with a hex 04 (ASCII character for EOT), you could enable the termination character when you configure the serial port.  Set the termination character to be 4.  Then when you execute the VISA read, read a large number of bytes such as 25 or more.  The read will terminate at either the timeout, the requested number of bytes, or when the termination character is read.  With this setup, you could eliminate the wait statement and also not request the number of bytes as the port.  The VISA read will control the pacing of the loop.  Any extra bytes after the termination character are part of the next frame of data and will wait around until the next time you read the VISA port.
  3.  Implementing your ideas for the latch button works better.  I am still encountering issues with these commands however.  Attached is the new vi.  There are two commands I want to send, 't' turns on the LED light (they blink for 30 sec then time out), and the latch works perfectly for that, 'p' turns on the magnetometer light (an additional 'p' is required to turn it off), but I cannot get the command sent to the mag while the loop is running.  It turns on either at the beginning of the vi, or at the end of the vi (after Finish button is pressed).  This leads me to think the command 'p' is stuck inside the loop.  I tried adding another film strip (see attached vi) for the toggles to force the issue, but it didn't work. Additionally, the 'p' command effectively works as a 't' command, and the LED lights begin to blink when I press the 'p' button.  This isn't supposed to happen, and leads me to believe the 'p' command does in fact exit the loop but in the wrong manner.
The "film strip" is another frame of a flat sequence structure.  It enforces the order of execution.  The next frame can't execute until everything in the prior frame has completed.  It isn't necessary in your case because the Error and VISA wires determine the order of execution with respect to the other VISA statements.  But it shouldn't hurt.
There is no reason the "p" case structure should behave any differently than the "t" case structure.  Although you should wire the error wire through in the False case of the "p" structure like you did for the "t" structure.  There is no "exiting of the loop" in either case.  The loop runs until the stop button is pressed.  I would check the manual to see that t and p commands do what you think they should do.  Do they need a termination character of their own when they are sent?  Should they be upper case letters rather than lower case?  You can run NI Spy on your serial port and see the operations occurring with it and see the data coming in and what data is going out.  I would be suspicious that the device is not handling the command properly.
Any ideas?  I think I've tried to put the toggle buttons outside the loop before, but then could only toggle once before the loop took over.  Ideally, these toggles would be available at any time while the data is streaming, so therefore inside the loop?
The toggle buttons need to be within the loop so that they can be read on every iteration of the loop.  Outside the loop, as you discovered, they are only read once at the very beginning before the loop is started.
4.  Thank you for the suggestion about the Selection Mode for the Open/Create File option.  It is annoying to create a file first.  I made the change, but I still get error messages when I use a file that does not yet exist.  LabView takes me to the first Open/Create/Replace vi when the error occurs.  Is there something else I must do?
On the open file VI, there is an input that is Open as default when unwired.  Create a constant there and change to Replace or Create.
Remember, if you have any questions about the way LabVIEW is handling something with serial ports, close the port within LabVIEW.  Open Hyperterminal and try the commands from there.
Message Edited by Ravens Fan on 01-13-2009 03:55 PM