serial port: Input/output signal errantly combined

[CodeMunkee]

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

[RavensFan]

Is it possible the instrument has a setting that causes it to echo back any commands sent to it?

For comments of the architecture of your program, you'll need to attach the VI's.  Also the name of the instrument and a link to its manual might help also.

[CodeMunkee]

No, the instrument does not have an echo setting.  I think it is obvious something is being bounced off the instrument and back into the input channel.  It would be helpful if someone could indicate why this might be happening.  Perhaps my vi is poorly devised.  The vi is attached, please indicate if it needs to be reloaded.

[RavensFan]

I don't see too many major problems with your VI.  So I'll comment on the few things I see.

1.  That lime green background is horrible.  Please change it back to grey.

2.  You are setting the VISA buffer sizes on every iteration of the loop.  This should be outside of the loop.  I don't think you really need this function at all, but if you do, move it prior to the loop.  I think if anything, this could possibly cause your problem as changing the buffers while data is going in and out could very well be something that scrambles the data in the serial buffers.

3.  Your LED toggle is set to switch action rather than latch.  So if you click that switch, it will continue to send the "t" until you unclick the switch.  I think a button that has latch action would be more logical, but that is up to you as to which action makes more sense.

[CodeMunkee]

1.  The lime green stays.  You know you like it.

2.  Unfortunately, the buffer is necessary.  Putting it outside the loop is equivalent to removing it, which results in the data flashing to the screen too fast to see with the naked eye.  I will keep your suggestion in mind, I think I may have seen prior evidence that this could be a factor; after I stop the vi, sometimes an LED will turn on - perhaps the command was stuck in the buffer.  Is there an alternative to the buffer command that will keep a display on the screen?

3.  When the LED toggle is switched to "latch", the data seems to stop echoing off the instrument.  The issue now is that I cannot keep the switch "off".  When I run the program, it automatically switches it on, and if turned off, it turns itself back on.  Am I misunderstanding something very basic here?

Thanks for the help.

[RavensFan]

---

CodeMunkee wrote:

1.  The lime green stays.  You know you like it.

Only when I'm wearing sunglasses.

2.  Unfortunately, the buffer is necessary.  Putting it outside the loop is equivalent to removing it, which results in the data flashing to the screen too fast to see with the naked eye.  I will keep your suggestion in mind, I think I may have seen prior evidence that this could be a factor; after I stop the vi, sometimes an LED will turn on - perhaps the command was stuck in the buffer.  Is there an alternative to the buffer command that will keep a display on the screen?

The buffer VI is a configuration setting intended to set the size of the buffer from whatever the default is.  Putting it outside is like running it once, it is not the same as removing it.  Putting it inside the loop is the same as reconfiguring the size of the buffer in the port over and over again to the same settings.  There is usually no need to even run it once unless the default buffer size (probably either 1024 bytes or 4096 bytes) is not large enough.  Since it looks like you are receiving and working on about 20-30 bytes per loop iteration, I'm sure the default is large enough.  The default setting that NI sets it to with that VI is 4096 bytes..

I'm not sure why you say the data flashes on the screen too fast for the naked eye.  You have a 1 second wait statement in there.  That should be slow enough to allow you to see something.  How fast is the data being sent to the serial port from the instrument?  Does it have any termination characters sent with it such as a carriage return or line feed?  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.  I think you might have a mismatch in your timing of when the instrument sends the data and when you read it.  Using the flush buffer command is probably a way that looks like it works for you because it takes a bit of time to reconfigure the buffers on each iteration, and it is effectively slowing down your loop, but at the big risk of scrambling the data. 

3.  When the LED toggle is switched to "latch", the data seems to stop echoing off the instrument.  The issue now is that I cannot keep the switch "off".  When I run the program, it automatically switches it on, and if turned off, it turns itself back on.  Am I misunderstanding something very basic here?

Your default value set for the switch is On.  With latch action, the control is set for the default value as soon as the terminal is read in the diagram.  So if you switch it to Off, it gets read, that case structure doesn't execute, and it returns to the default state of True.  What you want to do is while the VI is not running, set the switch to Off.  Right click on it and select Data Options, Make current value default.  Now the switch will default to Off.  You click it, it will be true for one iteration executing the case structure of sending the write command, and will immediately return to its default state of off.  This would be the logical behavior for a button where you click it so it only does an action one time per click.  Rather than using toggle switch like shown which graphically implies a maintained On or maintained Off state, a push button would graphically imply a momentary type of switch. 

Thanks for the help.

---

Message Edited by Ravens Fan on 01-12-2009 08:22 PM

[RavensFan]

One more thing.  On your file dialog VI's, right click on them and set the selection mode properties so that you can open existing or new filenames.  Right now, if the file name you select doesn't exist, you get an error.  That isn't good for creating new files in a write to file situation.

[CodeMunkee]

1.  If you keep giving me good advice like this, I'll be tempted to change the background to Baltimore prison purple.

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...

How fast is the data being sent to the serial port from the instrument? 

25 bytes a second

Does is have any termination characters sent with is such as a carriage return or line feed? 

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?

I think you might have a mismatch in your timing of when the instrument sends the data and when you read it.  Using the flush buffer command is probably a way that looks like it works for you because it takes a bit of time to reconfigure the buffers on each iteration, and it is effectively slowing down your loop, but at the big risk of scrambling the data.

What would be more effective than the flush buffer command?

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.

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?

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?

[RavensFan]

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

[CodeMunkee]

2.  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.

Without the delay, yes, that's what happens.  It fills up my text file with many zeros.

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.

I would like to eliminate the bytes read and the wait, however, I am unable to get the termination character read.  I am using a U8 (value of 4) as the termination character.  This isn't working and is probably wrong.  And tips?  I changed the timeout to 1 sec without success.  I assume this means the instrument sends the data much faster than 1 sec although not any more frequently than 1 sec.  Bottom line, I am not successful controlling the loop without the time delay.

 3.  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.

The commands are correct.  I have the old interface here and they work properly thru that. They are activated by the keystroke alone.  I will investigate NI Spy, it is possible that the instrument is mishandling - it's very fickle.  But....

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.

...strangely enough, when I run the vi, and complete the loop by pressing the 'Finish' button, even if I have not pressed the 'p' command (to turn the mag light on), the mag light turns on as the vi stops.  This behavior does not happen when I stop the vi by pressing the stop sign button in the task bar (next to the run command).  How is LabView sending a message without me instructing it to?  Additionally, I turn the mag light off by running the vi and then cancelling out of the 'File to save' menus.  So each time the program runs it sends a 'p'?  Twice?  Does this have to do with the way I configured the latch button as always off?  A 'p' turns the lamp on AND off, so perhaps this is the case?

4.  works great, thanks.