Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

usb rs232 problem

Solved!
Go to solution

Hi everyone,

 

I have been fruitlessly searching for some solution to an issue I seem to be having with communication to a serial device using a USB to rs232 converter.

I am using Labview 2013 on a windows 7 computer and using a converter using the FTDI chip.  My computer recognizese the converter, and NI-MAX recognizes it as ASRL7::INSTR which I have named "pc830."  I have attached a screenshot of my VI.

 

I am attempting to write a command to a pc830 (p 169,170 for relevant ASCII write/read commands) requesting position data from a piston. The issue I am encountering is that, while I can send a command, I am not receiving any data back during the read portion of my program and timing out my connection (Error -1073807339 occurred at VISA Read in PC830PosVelExtractor.vi, VISA:  (Hex 0xBFFF0015) Timeout expired before operation completed.).

 

The first and obvious questions are whether the serial port settings I am using are correct.  I am essentially rewriting a previous Labview program that use to control this same piston.  I have taken (and verified) that these are the correct values (baud rate, stop bit, etc).  Additionally, this older program sending the message \02255\sR\s10034:96\r gets back a reply from the serial device with position data (eg \02V26057:148\r).  I have checked that the hex version of the message sent by my new program is the same as the old one.

 

Now, to check that the USB cable is actually working, I performed a loopback test by opening a VISA test window.  In this, by shorting the cable in an rs232 configuration, I was able to successfully send and receive that same \02255\sR\s10034:96\r command.  I had a timeout issue before, however, I enabled the terminal character, and this went away.  The message is sent and received without issue.

 

Going back to my program, I similarly enabled the terminal character (\r) at the serial port hoping to get rid of the issue.  When connected to my serial device, I still get the timeout issue at the reading.  However, if I once again short the cable in an rs232 loopback configuration, I can send and receive my message \02255\sR\s10034:96\r without issue.

 

I actually connected the old and new program together by the cable just to see that I could talk with other devices.  This works fine, and I can both read and write back and forth from each of the programs.

 

My most recent attempt to diagnose/fix the issue was to add a "flush read buffer" just before performing the read/write operation.  This has not changed anything as far as I can tell.

 

I would love to hear back from anyone with suggestions as I'm just about out of ideas at this point.  We don't have space to add a serial port to the computer, and reviews of converters with FTDI chips seem to be good.  How can I get this thing to talk!?

0 Kudos
Message 1 of 16
(6,842 Views)
I've always found that a loopback test is pretty useless as a debug tool. It only verified that the port works. It does nothing to verify the command, port settings, or correct cable.

Your command does not show a termination character. Using the VISA Configure Serial Port only sets a termination character for a read.
0 Kudos
Message 2 of 16
(6,826 Views)
It's also impossible to determine from your image whether you have set the string constant for \ Codes Display.
0 Kudos
Message 3 of 16
(6,823 Views)

So I have attached screenshots from the front diagram of the main program after running it once so you can see the complete string (I should have done that in the first place. Apologies).  I have also included my little program which assembles the command string I wish to send to the serial device.

0 Kudos
Message 4 of 16
(6,794 Views)

The ReadCommandString program concatonates my command along with the <stx> and \r characters.

The displays are in the '\' format in the attached photos.

0 Kudos
Message 5 of 16
(6,793 Views)

Hey there!  I included more pictures of the program so that you can see the entire process.  All front panel diagrams have the completed string command in the " \ " format.

0 Kudos
Message 6 of 16
(6,706 Views)

Hi NIMIke,

 

When you say that your code has worked with older systems, does that mean you used it with an older pc830? If you are able to loopback commands and read those back in successfully, it means something is getting caught up with the actual instrument hardware.

 

If you are worried about program architecture, you can use the Continuous Serial Write and Read.vi example in LabVIEW as a test. You can navigate to this by going to Help»Find Examples..»Hardware Input and Output»Serial»Continuous Serial Write and Read.vi. This VI is pre-built and all you will need to do is verify the baud rate and command string.

 

Paul C

Paul C
0 Kudos
Message 7 of 16
(6,667 Views)

@Cooking_Up_Code wrote:

Hi NIMIke,

 

When you say that your code has worked with older systems, does that mean you used it with an older pc830? If you are able to loopback commands and read those back in successfully, it means something is getting caught up with the actual instrument hardware.

 

If you are worried about program architecture, you can use the Continuous Serial Write and Read.vi example in LabVIEW as a test. You can navigate to this by going to Help»Find Examples..»Hardware Input and Output»Serial»Continuous Serial Write and Read.vi. This VI is pre-built and all you will need to do is verify the baud rate and command string.

 

Paul C


 

Hi Paul.  Thank you for your response.  The serial device I am interfacing with has not changed.  I am simply rewriting the program from an old computer with Labview 6 to a new computer with labview 2013.  As the command strings I am sending appear to be the same as the old computer, I am scratching my head as to why the same device would seem to have issues with the communication.  I imagine it must be with the usb-rs232 converter, or some newer labview function adding characters, or some communication protocol of which I'm unaware.  I will check out the example and post back asap.

0 Kudos
Message 8 of 16
(6,657 Views)

 So trying the example vi, I run into the same issue as before.  I am timing out my connection when trying to read back a response from the hardware.

 

To give a little more background on my project, I am including a few photos of the old program, along with its serial settings and command string sturcture.

 

As the program I am rewriting is rather extensive, I am including the relevant pieces.  First, I have the serial settings for communicating with the device.

These serial settings are connected to a Position/Velocity read/write sub-vi which communicates with the serial device.

 

Within the sub-vi which communicates with the device, a command string is written to the serial device, and the returned string is read back.  Two things to note:

1) the second frame of the stacked sequence has a 50ms wait

2) the "true" setting on the second T/F case structure simply indicates an error has occured.

 

 

0 Kudos
Message 9 of 16
(6,646 Views)

The sub-vi that assembles the command strings is included here.

Download All
0 Kudos
Message 10 of 16
(6,631 Views)