Maker Pro
Maker Pro

Monitor RS232 Line Communication - PC hookup

  • Thread starter Klaus Vestergaard Kragelund
  • Start date
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
Hi

I'm communicating to a HP33120a function generator. PC and instrument are
both DTE devices and I use a null-modem cable as described by HP.

When I run the software I have written in LabWindows I sometimes get errors
from the instrument. Header errors and "Input Buffer Overflow" errors

Also for purposes of setting up a larger test system which includes scopes
and multimeters too I have purchased some USB-Serial Adaptor devices. But
when I use those with the same serial flow as with the null-modem cable I
get more errors.

So I need to do some debugging, but it seems too difficult with the scope. I
have an old portable PC, can I somehow hook that up as a second idle PC to
the same serial line with some sort of port state logging software to get an
idea of where my problems comes from?

Thanks

Klaus
 
Hi

I'm communicating to a HP33120a function generator. PC and instrument are
both DTE devices and I use a null-modem cable as described by HP.

When I run the software I have written in LabWindows I sometimes get errors
from the instrument. Header errors and "Input Buffer Overflow" errors

"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??
Also for purposes of setting up a larger test system which includes scopes
and multimeters too I have purchased some USB-Serial Adaptor devices. But
when I use those with the same serial flow as with the null-modem cable I
get more errors.

So I need to do some debugging, but it seems too difficult with the scope. I
have an old portable PC, can I somehow hook that up as a second idle PC to
the same serial line with some sort of port state logging software to get an
idea of where my problems comes from?

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: [email protected]
Klos Technologies, Inc. Web: http://www.klos.com/
==================== What goes around, comes around... =====================
 
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
"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??

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)
Are you using any flow control??

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
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?

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
 
M

moocowmoo

Jan 1, 1970
0
Klaus Vestergaard Kragelund said:
"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??

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)
Are you using any flow control??

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
[snip]


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

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.

http://www.airborn.com.au/rs232.html

Peter
 
M

Mark A. Odell

Jan 1, 1970
0
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
[snip]


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
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.

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.
 
M

Marco

Jan 1, 1970
0
moocowmoo said:
Hi

I'm communicating to a HP33120a function generator. PC and instrument
are
both DTE devices and I use a null-modem cable as described by HP.

When I run the software I have written in LabWindows I sometimes get
errors

from the instrument. Header errors and "Input Buffer Overflow" errors

"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??

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)

Are you using any flow control??

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

[snip]


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


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.

http://www.airborn.com.au/rs232.html

Peter
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.
 
R

Reed Blake

Jan 1, 1970
0
Klaus Vestergaard Kragelund wrote in message
Hi

I'm communicating to a HP33120a function generator. PC and instrument are
both DTE devices and I use a null-modem cable as described by HP.

When I run the software I have written in LabWindows I sometimes get errors
from the instrument. Header errors and "Input Buffer Overflow" errors

Also for purposes of setting up a larger test system which includes scopes
and multimeters too I have purchased some USB-Serial Adaptor devices. But
when I use those with the same serial flow as with the null-modem cable I
get more errors.

So I need to do some debugging, but it seems too difficult with the scope. I
have an old portable PC, can I somehow hook that up as a second idle PC to
the same serial line with some sort of port state logging software to get an
idea of where my problems comes from?

Thanks

Klaus

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.

2. 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.
 
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
Mark A. Odell said:
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
[snip]


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
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.

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.

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
 
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
Klaus Vestergaard Kragelund said:
Mark A. Odell said:
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

[snip]


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

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.

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.

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

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
 
A

Alex Pavloff

Jan 1, 1970
0
So I need to do some debugging, but it seems too difficult with the scope. I
have an old portable PC, can I somehow hook that up as a second idle PC to
the same serial line with some sort of port state logging software to get an
idea of where my problems comes from?

http://www.advfirmware.com/

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.
 
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
Reed Blake said:
Klaus Vestergaard Kragelund wrote in message
scope.

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.

2. 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.

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
 
R

Robert Wessel

Jan 1, 1970
0
Klaus Vestergaard Kragelund said:
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...


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.
 
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
Robert Wessel said:
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.

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:
www.microdesign.dk/2303.pdf. It speaks of DDK and WDM which is completely
new for me)

Cheers

Klaus
 
R

Robert Wessel

Jan 1, 1970
0
Klaus Vestergaard Kragelund said:
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:
www.microdesign.dk/2303.pdf. It speaks of DDK and WDM which is completely
new for me)


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.
 
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
Robert Wessel said:
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.

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

Cheers

Klaus
 
K

Klaus Vestergaard Kragelund

Jan 1, 1970
0
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
 
Top