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

"Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message
news:3ffef1ea$0$203$edfadb0f@dread14.news.tele.dk...
> "Robert Wessel" <robertwessel2@yahoo.com> wrote in message
> news:bea2590e.0401082327.43740281@posting.google.com...
> > "Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message
> news:<3ffde978$0$9724$edfadb0f@dread14.news.tele.dk>...
> > > 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.
>
> Well, that just goes to show the saying RTFM certainly applies to me ;-)
>
> Cheers
>
> Klaus
>
>

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:bea2590e.0401082327.43740281@posting.google.com...
> "Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message
news:<3ffde978$0$9724$edfadb0f@dread14.news.tele.dk>...
> > 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.

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

Cheers

Klaus

"Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message news:<3ffde978$0$9724$edfadb0f@dread14.news.tele.dk>...
> 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.

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:bea2590e.0401062120.90298d9@posting.google.com...
> "Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message
news:<3ffb2d62$0$9768$edfadb0f@dread14.news.tele.dk>...
> > 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.

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

Blakely LaCroix wrote:
> Look into Ebay for Protocol Analyzers.  There are many older
> units that will do exactly what you need for cheap
> 
> 
> 
> Klaus Vestergaard Kragelund wrote:
> 
> 
>>"Gary Peek" <mylastname@mycompanyname.com> wrote in message
>>news:3FFAD37B.7000801@mycompanyname.com...
>>
>>>Klaus Vestergaard Kragelund wrote:
>>>
>>>>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.
>>>>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?
>>>
>>>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:
>>>http://www.industrologic.com/resource.htm
>>>
>>>...lists an RS-232 info page:
>>>http://www.industrologic.com/rs232.htm
>>>(look near the bottom for a cable to use)
>>>
>>>...and terminal program with some debugging functions:
>>>http://www.industrologic.com/disk/utility/term232.exe
>>>
>>>
>>
>>Thanks
>>
>>It is almost what I'm after, but I need monitoring of the control signals
>>too...
>>
>>Cheers
>>
>>Klaus
> 
> 

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 
http://www.sinnovations.com/htdocs/siscope_rs232_analyzer.htm

Thanks,
Dennis

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

"Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message news:<3ffb2d62$0$9768$edfadb0f@dread14.news.tele.dk>...
> 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.

"Reed Blake" <rblake@attglobal.net> wrote in message
news:TUBKb.237552$8y1.1071801@attbi_s52...
> Klaus Vestergaard Kragelund wrote in message
> <3ffac4e2$0$9831$edfadb0f@dread14.news.tele.dk>...
> >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.
>

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

On Tue, 6 Jan 2004 15:23:52 +0100, "Klaus Vestergaard Kragelund"
<klauskvik@hotmail.com> wrote:

>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.
-- 
Alex Pavloff - remove BLAH to email
Software Engineer, ESA Technology

"Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message
news:3ffaec0a$0$9801$edfadb0f@dread14.news.tele.dk...
> "Mark A. Odell" <nospam@embeddedfw.com> wrote in message
> news:Xns946872B1078C1CopyrightMarkOdell@130.133.1.4...
> > "moocowmoo" <meltyb@hotmail.com> wrote in
> > news:btem78$a4u$1$8300dec7@news.demon.co.uk:
> >
> > >> 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

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



Klaus Vestergaard Kragelund wrote:

> "Gary Peek" <mylastname@mycompanyname.com> wrote in message
> news:3FFAD37B.7000801@mycompanyname.com...
> > Klaus Vestergaard Kragelund wrote:
> > > 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.
> > > 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?
> >
> > 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:
> > http://www.industrologic.com/resource.htm
> >
> > ...lists an RS-232 info page:
> > http://www.industrologic.com/rs232.htm
> > (look near the bottom for a cable to use)
> >
> > ...and terminal program with some debugging functions:
> > http://www.industrologic.com/disk/utility/term232.exe
> >
> >
> Thanks
>
> It is almost what I'm after, but I need monitoring of the control signals
> too...
>
> Cheers
>
> Klaus