setting up communication through rs232 to a test instrument (SCPI)

[mr_monster]

Hello all, 1st post!

I have an LCR meter by a Chinese manufacturer called Applent. It's a good quality meter that covers the AF range. Like many other firms in China, the support they offer is non existing. The instrument supports SCPI commands and has an RS232 port on the back. I tried hooking up using a serial to USB device and work through HyperTerminal but I can't seem to get anything across or get any data back.

I tried switching between normal extension and null cables, changes the flow control although the spec. states it clearly (no control). I can see that the serial communication does have some effect since the instruments keys will get locked about 20 seconds after I'll start sending some commands but otherwise no indication.

I tried sending:
fetch?
*idn?
*tst?

In the past I used a C library from Agilent to communicate to a power meter, from what I've seen there is no reason this should not work through a terminal program as well. Any help on this will be greatly appreciated!

[ftransform]

lmfao applent corporation.

Are you sure its even plugged into anything useful? Maybe they just added a dummy serial port to trick you... I have seen it with USB ports.

[Psi]

Are you sure you have TX-RX and not TX-TX ?

[mr_monster]

ftransform - I know the name sounds like a joke and the logo is a rip off of the Agilent logo, however I was able to verify this instrument against an HP LCR and they are almost the same. Does not seem like a clone and the quality is actually really good and the guys who engineer these things know what they are doing.

I checked if the RS232 is hooked up on the PCB and it is. I can also see the keys locks when I start transmitting. What do you mean TX-TX?

[McMonster]

I checked if the RS232 is hooked up on the PCB and it is. I can also see the keys locks when I start transmitting. What do you mean TX-TX?

Check if you have you PC's TX pin connected to the device's RX and vice versa. Connecting TX to TX and RX to RX is a common mistake.

[mr_monster]

I checked if the RS232 is hooked up on the PCB and it is. I can also see the keys locks when I start transmitting. What do you mean TX-TX?

Check if you have you PC's TX pin connected to the device's RX and vice versa. Connecting TX to TX and RX to RX is a common mistake.

According to the manual the only connections used in the DB9 are RX, TX & GND. Between PIN2 & 5 (RX & GND) I measure -5V. I tried using a 'normal' extension cable + a null (crossing) cable just to make sure but communication did not work with both of them.

[Bored@Work]

To get that working, you need to know (and get it right) multiple things on multiple levels:

(a) As already discussed, the hardware pinout, etc. (voltage level -5V looks ok)

(b) The serial communication parameters as used by the instrument (or as configured on the instrument). That is Baud rate, number of bits, number of stop bits, parity (if any). Handshaking. In your case this means if there is any software handshaking (XON/XOFF) or not. From (a) you already know it doesn't do hardware handshake, so that needs to be turned off (no RTS/CTS handshaking, no DTR/DSR handshaking, and certainly no exotic functions like RI, CD).

(c) The instrument's protocol. You mention SCPI. Unfortunately, SCPI is one of those standards which huge holes in it, and where you are lucky if a vendor has at least implemented the basics, i.e. a response to "*IDN?". Sometimes "*IDN?" is all you get as fare as SCPI compatibility is claimed. What you really need is a list (programming manual) from the vendor describing the implemented commands.

(c.1) When sending SCPI commands, you need to know the line termination the instrument supports (CR, LF, CRLF). You further need to know things like command queuing behavior. The SCPI standard specifies that, but vendors do their own thing.

To successfully communicate with the instrument you need to get all of the above right, in the above listed order. There is no point guessing communication parameters as long as you didn't get the wiring right.

[mr_monster]

To get that working, you need to know (and get it right) multiple things on multiple levels:

(a) As already discussed, the hardware pinout, etc. (voltage level -5V looks ok)

(b) The serial communication parameters as used by the instrument (or as configured on the instrument). That is Baud rate, number of bits, number of stop bits, parity (if any). Handshaking. In your case this means if there is any software handshaking (XON/XOFF) or not. From (a) you already know it doesn't do hardware handshake, so that needs to be turned off (no RTS/CTS handshaking, no DTR/DSR handshaking, and certainly no exotic functions like RI, CD).

(c) The instrument's protocol. You mention SCPI. Unfortunately, SCPI is one of those standards which huge holes in it, and where you are lucky if a vendor has at least implemented the basics, i.e. a response to "*IDN?". Sometimes "*IDN?" is all you get as fare as SCPI compatibility is claimed. What you really need is a list (programming manual) from the vendor describing the implemented commands.

(c.1) When sending SCPI commands, you need to know the line termination the instrument supports (CR, LF, CRLF). You further need to know things like command queuing behavior. The SCPI standard specifies that, but vendors do their own thing.

To successfully communicate with the instrument you need to get all of the above right, in the above listed order. There is no point guessing communication parameters as long as you didn't get the wiring right.

I have the instrument's manual and I took all the info from there -

RS-232 DB9 connector: 2 is RXD, 3 is TXD, 5 is GND. All the other pins are not connected. It is clearly stated there is no usage of the hardware handshaking lines CTS & RTS. Also stated to use an extension cable and not a null modem cable.
Data frame is 8N1. Baud rate is set to 9600 using the instrument's menu system.

I also have a list of commands, *IDN? is listed there. The terminator is new line or /n
There are also some other commands there that I have tried. I am using a software called RS232Analyzer for port monitoring but I can not see anything coming in.

[jucole]

A while ago I wrote some rs232 basic tx and rx stuff for a pic uC then wrote some c# to connect to it from my PC.  The send code from uC to PC was pretty solid, but during the writing the uC rx code I realized that without handshaking  ie. only using the rx and tx lines it could quite easily get screwed up.   When I came to write the c# on my laptop; yup, sure enough it screwed up!,  So I had to insert a small delay because the PC was sending each byte too fast for my poor uC code to parse them.

So what you could try is to find terminal app that allows you send each byte with a small delay between.

[mr_monster]

I have finally heard something back from the company. Turns out they want to sell me software for $200. The reason it was not bought in the 1st place is due to the fact it was described as an acquisition app and I rather write up some code in C, well turns out the software is just some driver that enables communication and nothing else. What I find strange is that it seems like the program is somehow an FTDI driver with some console app. This seems a bit strange for me because I measured a negative voltage on PIN2 on the DB9 so it does not seem like USB through the DB9 cable... any ideas?