serial communication

[JFMoynihan]

I am trying to communicate with an Agilent 34970A through a serial connection.  Using the LabVIEW example Basic Serial Write and Read.vi, I can type a command into the String to Write control and the command executes without fail.  If I try to build the same string, the command fails on the write.  The command I am trying to write is as follows; MEAS:TEMP? TC,K,(@101,102).  Although any command will act in the same fashion.  Can anyone offer some advice?  Thanks.

[RavensFan]

Can you post the code?

Create indicators out of the "String to Write" control and your build functions.  Look at them in terms of /codes and hex.  Compare them to each other to see if they are the same.  If the code has run once, you can do a right click, create constant on the wire to create a constant of the data.  You can copy them to a blank VI if it helps do the string comparisons.

Are you sure you are ending the string with the came characters?  Perhaps one is carriage return/line feed and the other is not?

[JFMoynihan]

I have tried to make a constant from the control (Normal, "\" or hex), but the only thing that works is typing the command into the control.  I've also tried a variety of terminator configurations.  With the control set to normal display, no terminator characters are neccessary.  With the control in the "\" Code display, the command will run as long as I include the \r\n terminator.  Here are two .jpgs of the code.

[RavensFan]

When the control is in the normal display, the terminator characters of carriage return and line feed are still there.  They just aren't visible because they are non-printing characters.

In your non-working code, you have a string constant "\r\n".  Is that constant in normal display or \ code display?  Everything else looks okay, so I suspect you are getting the codes mixed up.  If that \r\n is in normal display, then you are sending 4 characters, a slash, an r, another slash, an n.  This is NOT the same as \r\n in \code display which is two characters of \r (carriage return) and \n (line feed).  If you look at that constant in hex display, it should show up as 0D 0A.

There is also a special CR/LF primitive on the string pallette that you could drop on the block diagram to wire to the concatenation rather than dealing with \r \n.

[Jaime Rodriguez]

I have two suggestions:

(1) Try writing the string without using the concatenate strings function. If you have all inputs as constants, then why use the function???

(2) Try using the carriage return constant in the strings palette instead of a \r\n string.

I would try the one that you claim works by wiring the constant that you have on the block diagram to the VISA write function instead of the control.. Does it still work??

I hope this sheds some light.

[JFMoynihan]

My example shows that I am reading two channels (@101,102) because I'm trying to iron out the communication.  When incorporated into the application, a user will select which channels to read.  I have to build the command string from the user selections.  The good news is that the CR/LF constant cleared up the problem.  I should have tried that first.  Lesson learned.  Thanks Raven and Jaime for helping me get my head on straight.