Monitor RS232 Line Communication - PC hookup

I don't know what you mean by "port state logging", but if simple monitoring will do, you can see what we have done many times to look at communications.

Our Resources page:

...lists an RS-232 info page:

(look near the bottom for a cable to use)

...and terminal program with some debugging functions:

--
Gary Peek                mailto:mylastname@mycompanyname.com
Industrologic, Inc.      http://www.industrologic.com
Phone: (636) 723-4000    Fax: (636) 724-2288

"Input Buffer Overflow" almost always means that your PC can't keep up with the amount of data coming into the serial port. I expect you're using a high baud rate (115,200?). Do you still get these errors when you reduce the baud rate to something like 1/2 or 1/3 of the current setting??

Are you using any flow control??

Sure. There are several generic serial logger products available, but unless you already know what's supposed to be on the serial line, you may end up just seeing a bunch of bytes and not know what to do with them. Is the protocol between the HP and the PC documented? Does the protocol include a checksum of sorts? And can you spend any real money on the troubleshooting or do you have to make due with the tools at hand?

========= For LAN/WAN Protocol Analysis, check out PacketView Pro! ========= Patrick Klos Email: snipped-for-privacy@klos.com Klos Technologies, Inc. Web:

==================== What goes around, comes around... =====================

errors

with

I should have specified more explicitly it is the instrument that is reporting the error, sorry for that...

I'm just sending data at 2400baud without any handshaking using SCPI commands to debug the interface before I use any drivers from the instrument manufactors (In fact I have tried theese, but they also produce errors)

No flow control. XON/XOFF is disabled and hardware handshaking is also turned off. So, in essence I'm just running so slow that the device will be able to catch up

scopes

scope. I

to

an

unless

troubleshooting

I know exactly what I am sending due to the software I have written. What I'm after is a device I can hook up on the instrument end to capture what bytes are received and what status/control signals are activated

Cheers

Klaus

are

reduce

instrument

be

[snip]

As the other guys have said, you need to switch on handshaking because you are still sending the data too fast and the function generator isn't catching up. If you really don't want to implement handshaking then as well as using a low baud rate you also need to leave gaps in the transmission and it will be very slow.

One way that we use an old PC for monitoring serial comms is using a special cable and Hyperterminal. All that it consists of is a couple of diodes to OR together the send and receive lines then you can monitor the dialog both as long as the devices don't talk in full duplex.

Here is a link to a similar idea.

Peter

are

scope. I

to

get an

Thanks

It is almost what I'm after, but I need monitoring of the control signals too...

Cheers

Klaus

"moocowmoo" wrote in news:btem78$a4u$1$ snipped-for-privacy@news.demon.co.uk:

Or, don't send commands that exceed the device's buffer limit and then wait for completion of each command before issuing the next one. Application level flow control if you will. You can't go any faster than the device can process commands anyway.

--
- Mark ->
--

Google for an program called ComTap, make a tap cable, use a DOS PC to run ComTap and see exactly what happens on the RS232...

I've used this several times to reverse-engineer binary (non-documented) protocols, it works great.

I

an

As others have commented, you really need to turn on handshaking. I strongly suggest hardware handshaking over Xon/Xoff. Use the LabWindows SetCTSMode() function to enable hardware handshaking.

For your larger system, consider using GPIB instead of serial, especially if you are going to download lots of data from your scopes.

That said, there are a couple of ways to do serial port monitoring.

1. Install a serial port sniffer / protocol analyzer on a second computer. This software uses two com ports and a special cable to monitor and display activity on the serial link. This will work for communications between any two devices, not just PCs. This is an excellent solution, but can be a bit expensive for a one time use. I used to use ViewComm from Greenleaf, but it looks like the program has changed a lot in the last decade, so I really can't comment on it now.

1. Install serial port monitor program on your control (LabWindows) computer. These programs typically replace the serial driver, and let you see the data flow and control signals. This is typically less expensive, and likely won't work with your USB serial adapters. Caveat - I haven't personally used this type of program.

Do a google search for serial monitor to see lots of products in both categories.

If you want to use a scope, turn on RTS/CTS hardware handshaking on the HP, and watch the RD and RTS lines on the HP side of your null modem cable. You will likely see the HP drop RTS while the PC continues to send data.

Feel free to email me if you need more info.

-- Reed Blake Beta Technology Industrial and Scientific Computing

Tried going down to 300baud with the cable, that works fine

Then tried 300baud with the USB to serial adaptor, and plenty of errors (header errors, not buffer overflow). Then tried killing the program when I had run the stream of data for a couple of seconds. When I do this the data seems to keep flowing even when the program is killed. Some buffer must be active. Then went to "Control Panel->System->Device Manager" and set the port (USB psedu-port) to disable 16650 FIFO. This changes nothing

I think maybe the USB device buffer is doing something like getting data too fast or something

Moreover, now I remember why I dropped my efforts the last time. Now my PC boots without warning when I use the USB->Serial adaptor. This happens with both types of adapters I have :-(

I Think Bill Gates is angry with me and won't let me succeed ;-)

Thanks

Klaus

Look into Ebay for Protocol Analyzers. There are many older units that will do exactly what you need for cheap

Klaus Vestergaard Kragelund wrote:

also

isn't

I

data

too

Just tried hooking up a RS232 mini tester (LEDs on all the lines). It does continue to send lots of data after the program is killed. The DSR line is toogling in sync with the errors from the instrument. Will try to block transfers to the instrument when this line is active, perhaps this will help my buffer problem too....

Thanks

Klaus

They sell software for Windows and DOS that lets you monitor serial communication, with a PC+adapter between the 2 devices. I've used the DOS version for years and it works great. Never tried the Windows version. The DOS version needs 2 serial ports -- not sure about the Windows version.

--
Alex Pavloff - remove BLAH to email
Software Engineer, ESA Technology

errors

scopes

scope.

to

strongly

SetCTSMode()

if

display

bit

it

and

HP,

You

Thanks Reed

I should have done this when I first started working on the instrument. Now using the null-modem cable with the DTR line from the instrument hooked up to CTS at the PC I can run at 9600 baud with CTS/CTS/DTR hardware handshaking. No errors :-)

But using the USB to serial converter still runs bad, but at least now I know the connection is correct and can chase the problem of the buffer in the USB adapter...

Cheers

Klaus

Many people have found that the USB serial ports have their share of quirks. Notably, they tend to be quite slow to respond to and make control signal changes, and often have considerable amounts of unexpected buffering built in. Pretty much anyone who's tried to rapidly toggle DTR, for example, or to toggle it with any timing precision, has been pretty quickly burned. As you noticed, most of them can also transmit a fair while after getting a flow control signal to stop.

This is usually because these are pretty dumb devices, and most of the responses to changing conditions (eg. hold transmitting) has to propagate over the USB link to the device driver in the CPU before they're acted on, and buffers going the other way are gone as far as the DD is concerned. In short your application is a *long* way away from the actual serial port.

If you've got a fairly conventional serial device, with lots of input buffer, and no tricky timing requirements on the control signals (IOW a modern modem), you'll be fine.

Also, if your device is powered off the serial port (which has always been iffy, rather more so of late), the USB serial ports tend to be a problem as well.

Some of the USB serial ports appear to be a bit better than others, at least as regards hardware flow control.

Oh yeah, you mentioned buggy drivers for these things? It's a bloody serial port, you'd think it wouldn't be that hard to get right, but noooooo......

Allow me to recommend any of the nice PCI serial port cards. The PCMCIA serial ports seem OK as well.

This thread reminded me that I have a new si_scope not being used and I would like to sell. Aside from e-bay, where are the best places to sell test equipment?

By the way, the si_scope does RS-232 analysis. I used it to get timing information on software I did. More information is available at

Thanks, Dennis

--
If sending a reply you will need to remove "7UP".

Now

up

in

Yep, I just bought a Maxo PCI board with 4 serial ports - at least thats going to work :-) (and included is software to log the transmission on the serial port, which was my initial request)

But on the subject of the USB serial port. I refuse to give up - but the next step seems to write my own driver and access the USB device directly. Thats an entirely other project, but I'll give it a try. The USB adapter I'm using from Prolific has a pdf file describing all the low-level commands.....

(it's called the "PL-2303 USB-Serial Driver Specification" - link:

It speaks of DDK and WDM which is completely new for me)

Cheers

Klaus

I looked because I was curious - that sort of low-level interface data is not generally published, unless the vendor intends to support Linux, or under and NDA. Indeed, it is not published here either (unless you provided a link to the wrong document). All that 2303.pdf describes is how the serial port driver appears to the OS. The I/O Request Packets (IRPs) are what the OS sends to a device driver (IOW, this document define the "API" exported by the driver). All they've done is taken the MS sample serial port driver (which is included with the DDK), and produced a document which describes what functions

*their* device driver implements. In fact they've almost exactly matched the MS Sample, which you'd expect for a serial port (IOW, this document would apply, with only minor changes to any driver, for any hardware, that claimed to be a more-or-less "normal" Windows serial port).

Unfortunately, none of that actually tells you anything about how you talk to the serial port thingy on the other end of the USB cable.

directly.

I'm

completely

Well, that just goes to show the saying RTFM certainly applies to me ;-)

Cheers

Klaus

Finally found a workaround for the USB to Serial adapter problem.

Even though the adapter was set to 9600 baud with the correct handshaking, the software program would stream off the data much faster. Well, I simply inserted a delay of approx 2/baud inbetween all bytes written to the USB adapter and now it functions beautifully. This probably avoids filling up the USB input buffer and also limits the speed of the communication line.

I think however I will use the PCI board with multiple serial outputs if I see any more warmboots due to the adapter. Thanks for all your help :-)

Cheers

Klaus

the

adapter