I/O Assistant Test works, fails at runtime

[CyO Mike]

I'm trying to control a Newport motion controller (ESP300, if that matters) and I'd like to ping it occasionally to see if it has completed the assigned motion.

The problem is, when I run my .vi, I get no output from the I/O Assistant block.  The return is ASCII 1 or 0, so I have a string indicator set up to display the output result.  It works once, sometimes (I think the first time I launch Labview after booting the PC), but never again.

The strange thing is that if I open the I/O Assistant to edit the write/read parameters and test it, it works just fine.  If I keep clicking on test, and start the stage moving at the controller, it outputs a 0 everytime if ping it until the motion is done, when it starts outputting a 1.  So, I know that my comms set up is correct.

Is this sort of thing common, where the test mode works but in actual execution the Assistant fails?  If so, how does it resolve?

Thanks!

Mike

[CyO Mike]

Additional fact:  Apparently, when I test the command, the device is returning "31 0D" (ASCII 1 \r).  However, when I execute the .VI, the device is returning "0A 31" (ASCII \n 1).

So, this brings forth the additional question:  during the test under the I/O assistant, is Labview missing the leading 0A, failing to display it, or is it not there?  And what is the difference between the test mode and the execution mode that causes the 0A to appear in one but not the other?

Mike

[Steve.Briggs]

Hey Mike,

I've never used I/O Assistant but rather gone straight to using the Serial VIs in VISA and GPIB.

The first thing that comes to mind in seeing your 1st run work, but none afterward, is a question of closing/resetting the data that is present at the port.

Secondly, in regard to your other comment, the difference in data could have to do with the termination characters; which are different from the test and execution.  You first get a carriage return (\r) and in the execution you receive a line feed (\n).  These are two different termination characters and in order to get good data from an instrument you must find the proper termination character and use it throughout any testing or execution.

Hopefully this information helps you a bit..

[CyO Mike]

Nevermind.  Hopefully someone will get something out of this-

It turns out that the device in question requires a \r at the end of a command string, but terminates its returns with \r\n (why, I suspect only the original engineer that wrote it knows).

So, since this is a serial comms device, Labview is looking for the specified termination character.  I was specifying \r (of course), but the device was returning \31\r\n.  Labview was leaving the \n in the serial buffer.  Thus, the first time, Labview would retrieve \31\r and display in the string indicator "1", as it was set to parse the first character retrieved from the serial port buffer.  Every SUBSEQUENT time, it would retrieve \n\31\r, parse and display \n (which of course is not visible unless the "Display Hex code" option is enabled), and quit running.

Grrrr.

Mike

[Steve.Briggs]

More times than not when dealing with an instrument over serial it is always safe to include the line feed along with the carriage return.  Why?  Well, as you said, only the instrument developing engineers know.

[CyO Mike]

Thanks, Steve.  Your reply came through just as I was typing my last reply to myself, but it sounds like what you're suggesting is what I just found out on my own.

It's very frustrating, but I think I have it settled, now.  I just have to choose the appropriate termination char and then remember to add the termination on my own.

Mike