Instrument VISA Interface Problem

[Adam_Kimberlin]

I am having a problem communicating with a signal conditioner. The conditioner can be remotely controlled using proprietary software supplied by its manufacturer but I need to integrate it into my VI so I only need a few lines of source code which will not be supplied to me. So I have found various applications to monitor the VISA communication between the instrument and the RS232 port. I then take the code resulting from the sniffer program and send the commands back to the instrument via my VI but the instrument doesn't respond. This makes me think that the port is not configured properly. So when I run the sniffer, this is the first thing that appears once the 3rd party software initiates communication with the instrument.

10   11:23:11 AM   IOCTL_SERIAL_SET_LINE_CONTROL   NiUsbSer0   SUCCESS   StopBits: 1 Parity: NONE WordLength: 8   
11   11:23:11 AM   IOCTL_SERIAL_SET_CHAR   NiUsbSer0   SUCCESS   EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13   
12   11:23:11 AM   IOCTL_SERIAL_SET_HANDFLOW   NiUsbSer0   SUCCESS   Shake:1 Replace:40 XonLimit:64 XoffLimit:64   
13   11:23:11 AM   IOCTL_SERIAL_SET_QUEUE_SIZE   NiUsbSer0   SUCCESS   InSize: 640 OutSize: 640   
14   11:23:11 AM   IOCTL_SERIAL_SET_TIMEOUTS   NiUsbSer0   SUCCESS   RI:-1 RM:0 RC:0 WM:0 WC:500   
15   11:23:11 AM   IOCTL_SERIAL_GET_COMMSTATUS   NiUsbSer0   SUCCESS      
16   11:23:11 AM   IOCTL_SERIAL_SET_RTS   NiUsbSer0   SUCCESS      
17   11:23:11 AM   IOCTL_SERIAL_SET_DTR   NiUsbSer0   SUCCESS      
18   11:23:11 AM   IOCTL_SERIAL_GET_BAUD_RATE   NiUsbSer0   SUCCESS      
19   11:23:11 AM   IOCTL_SERIAL_GET_LINE_CONTROL   NiUsbSer0   SUCCESS      
20   11:23:11 AM   IOCTL_SERIAL_GET_CHARS   NiUsbSer0   SUCCESS      
21   11:23:11 AM   IOCTL_SERIAL_GET_HANDFLOW   NiUsbSer0   SUCCESS      
22   11:23:11 AM   IOCTL_SERIAL_SET_BAUD_RATE   NiUsbSer0   SUCCESS   Rate: 9600   
23   11:23:11 AM   IOCTL_SERIAL_SET_RTS   NiUsbSer0   SUCCESS

 When I execute a command, this is what results,

168761   11:23:33 AM   IRP_MJ_WRITE   NiUsbSer0   SUCCESS   Length 13: 35 31 38 20 30 20 32 3B 31 32 33 0A 0A    
168762   11:23:33 AM   IRP_MJ_FLUSH_BUFFERS   NiUsbSer0   SUCCESS      

and

177285   11:23:39 AM   IRP_MJ_WRITE   NiUsbSer0   SUCCESS   Length 50: 35 31 38 20 31 20 30 3B 31 30 30 30 20 31 30 30 39 20 31 30 30    
177286   11:23:39 AM   IRP_MJ_FLUSH_BUFFERS   NiUsbSer0   SUCCESS   

When I decode the hex in lines 168761 and 177285 and send the resulting string back to the instrument in my VI, I get nothing. So I take the settings from lines 10-23 and try to implement them and I still get nothing....

Here is what I use.

Parity: None

Baud Rate: 9600

Data Bits: 8

Stop Bits: 1

Flow Control: XOn / XOff

XOn Char: 11 

XOff Char: 13

To make things a little easier, I also wired a second serial port into my pc to monitor the signal being sent to the instrument. The VI I wrote to monitor the signal produced the following:

8:32:58 AM   6 0 2;1000 1005 1494 1000 1000 0 1000 1000

The red text is the section of the command that I need to modify. Each set of numbers cooresponds to different settings on the charge amplifier. The red is just the gain. There is also a termination character that follows, 0A.

Any thoughts?

Message Edited by Adam Kimberlin on 10-29-2008 04:57 PM

[Adam_Kimberlin]

Side note: Its an Endevco 2775B Signal Conditioner that I am trying to communicate with.

[TV_Enable]

Hi Adam,

The best way to know whether your serial port is configured properly is to try a serial loop-back test.  Refer to this KnowledgeBase article for more information on how to run an RS232 loop-back test.  This test will tell us whether or not your port and cable are working properly.  Also, do you need to use a null modem cable, or a straight through cable?  You will want to consult the manual of your device to know whether it uses DTE or DCE communication, and this will determine which cable you need.  Please let me know if the loopback test works.   Have a great day!

Regards,

Todd V. 

[Adam_Kimberlin]

The loopback test works.

As far as determining whether or not the device is DTE or DCE, its hard to tell because the interface between the computer and the instrument is converted from RS-232 to an RJ-22. I think it is DTE. The communication works fine when I run their software, so I can only assume the wiring is correct. I use the same port without changing any of the wiring, I just change the program I am using to try and run it.

Message Edited by Adam Kimberlin on 10-31-2008 09:28 AM

[TV_Enable]

Hi Adam,

I'm glad the serial loopback test went well.  Your serial port is working well.  We now need to verify what termination characters will need to be sent to your instrument, if any.  Termination characters tell your instrument when your command is over.  This information should be available in your manual.  If the manual is not readily available, you will need to contact the manufacturer and ask them for this information.  

In regards to what you are seeing in your sniffer program, we will need to see the actual hexidecimal or binary characters to help you out further.  The lines of code communication you provided is top-level and has decoded the source data.  This means that we cannot tell what the instrument is acutally looking for.  If we can see that, it could hopefully tell us what the serial port is looking for.

Another avenue that we could take is trying to access this software from within LabVIEW.  There are two options that we have to do this.  For one, if the manufacturer of the software can provide a DLL, this can be called using the Call Library Function node in LabVIEW.  Secondly, if the manufacturer created this software to be ActiveX compliant, we can use the ActiveX function in LabVIEW to make calls to the software.  Check with the manufacturer to see if this is possible.

Have a great day, Adam!

Regards,

Todd V. 

[Adam_Kimberlin]

They don't provide a manual but I have determined that the termination character is a 0A or 1010.

I checked the directory where the software was installed and there aren't any .dll's so I will try to find any that might be called by the exe.

I will try the activex approach as well and keep you posted.

Thanks,