HP Serial Plotter, WinXP CPU

[travcoe21]

Greetings --

Can anyone tell me all of the settings one needs to apply to a serial
port from a Command Prompt window (via the MODE command) in order to
talk to an HP7580 plotter?

With my old W98SE box, all I had to do was open an MS-DOS prompt, type

MODE COMn: 1200,n,8,1,p
copy %1 COMn:

.. . . and the plotter would be off and running, with the CPU copying
HPGL plot file %1 to the COMn: port. But with my new XP box I have yet
to successfully do this.

I have tried both a Prolific USB-serial converter and a SIIG PCI
plug-in serial port. With the converter the plotter writes readable
text, but the lines are all garbage. With the plug-in card, I can't
seem to talk to the plotter at all, either from a Command Prompt or
from Windows as an installed printer.

I know that both ports are working, because I have successfully
communicated with another serial device over both. The cable
connecting the CPU to the plotter hasn't changed since the days of the
W98SE box, other than getting rid of a share switch. I do notice, when
I type HELP MODE, that there seem to be many more options for serial
port operation under XP than there are under W98SE, which is what is
prompting my question.

FWIW, I'm using the WinLine HPGL driver to create plot files, both on
the old box and the new. The old box had 2 serial ports on the
motherboard.

TIA for any help anyone can give!

Jeff Travis

 

[Paul]

Greetings --

Can anyone tell me all of the settings one needs to apply to a serial
port from a Command Prompt window (via the MODE command) in order to
talk to an HP7580 plotter?

With my old W98SE box, all I had to do was open an MS-DOS prompt, type

MODE COMn: 1200,n,8,1,p
copy %1 COMn:

. . . and the plotter would be off and running, with the CPU copying
HPGL plot file %1 to the COMn: port. But with my new XP box I have yet
to successfully do this.

I have tried both a Prolific USB-serial converter and a SIIG PCI
plug-in serial port. With the converter the plotter writes readable
text, but the lines are all garbage. With the plug-in card, I can't
seem to talk to the plotter at all, either from a Command Prompt or
from Windows as an installed printer.

I know that both ports are working, because I have successfully
communicated with another serial device over both. The cable
connecting the CPU to the plotter hasn't changed since the days of the
W98SE box, other than getting rid of a share switch. I do notice, when
I type HELP MODE, that there seem to be many more options for serial
port operation under XP than there are under W98SE, which is what is
prompting my question.

FWIW, I'm using the WinLine HPGL driver to create plot files, both on
the old box and the new. The old box had 2 serial ports on the
motherboard.

TIA for any help anyone can give!

Jeff Travis

Possible issues:

1) 8 bit versus 7 bit transparency
2) Flow control method

I think you have (1) covered, by your mode choice of "8".

It is harder to tell about flow control. There are a couple of
methods, like X-ON/X-OFF or hardware flow control (RTS/CTS on the
cable interface.) You would think the hardware flow control would
be enough to allow the printer, to tell the computer to stop for
a moment when necessary.

It could be that the plotter simply cannot be guaranteed to "eat"
data at 1200 baud (i.e. if flow control is not working for some
reason). For example, try the experiment at 300 baud and
see what happens. (Make sure the plotter is set to 300 baud
before you try.)

To debug serial problems, you can plug the output of one serial
port, into another serial port. Use a null modem cable or adapter
plug, which will connect TX-RX and RX-TX on the two serial
interfaces (plus do the right things with the flow control
signals). If you set up a Hyperterm on one COM port, then use
your "copy %1 COMn:", you should see the data show up on the
Hyperterm screen. There is presumably a way to redirect the
output to a file, and then you can compare the source file,
and the file that comes back on the other serial port (I used
to do this years ago, but no longer remember the DOS command.)

http://www.radioshack.com/product/i...kw=null+modem&kw=null+modem&parentPage=search

In this USBM100 manual, there appears to be a menu item for
flow control. See page 7 here. Perhaps selecting hardware
flow control will fix it.

http://www.ibizcorp.com/downloads/USBM100 Install.pdf

Paul

 

[travcoe21]

Hi, Paul --

Thanks for this thoughtful response. There are some interleaved
replies.

Jeff

Possible issues:

1) 8 bit versus 7 bit transparency
2) Flow control method

I think you have (1) covered, by your mode choice of "8".

That's correct. n,8,1 always worked in the past.

It is harder to tell about flow control. There are a couple of
methods, like X-ON/X-OFF or hardware flow control (RTS/CTS on the
cable interface.) You would think the hardware flow control would
be enough to allow the printer, to tell the computer to stop for
a moment when necessary.

Right, everything I've seen says that you need to use hardware
handshaking for the plotter. But as I mentioned, there seem to be more
options for hardware handshaking than previously. To wit:

C:\HELP MODE

returns . . .

Serial port: MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
[to=on|off]
[xon=on|off] [odsr=on|off]
[octs=on|off]
[dtr=on|off|hs]
[rts=on|off|hs|tg]
[idsr=on|off]

It could be that the plotter simply cannot be guaranteed to "eat"
data at 1200 baud (i.e. if flow control is not working for some
reason). For example, try the experiment at 300 baud and
see what happens. (Make sure the plotter is set to 300 baud
before you try.)

It definitely can't eat data at 1200 baud. That's what the ",p" is for
in the MODE command that used to work -- "infinite retry on timeout".
Using 600 baud would typically result in the plotter stopping to wait
for more data, so it seemed like 1200 baud was the way to keep the
pipeline full.

To debug serial problems, you can plug the output of one serial
port, into another serial port. Use a null modem cable or adapter
plug, which will connect TX-RX and RX-TX on the two serial
interfaces (plus do the right things with the flow control
signals). If you set up a Hyperterm on one COM port, then use
your "copy %1 COMn:", you should see the data show up on the
Hyperterm screen. There is presumably a way to redirect the
output to a file, and then you can compare the source file,
and the file that comes back on the other serial port (I used
to do this years ago, but no longer remember the DOS command.)

This is an excellent idea, I will try it. Thanks!

http://www.radioshack.com/product/i...kw=null+modem&kw=null+modem&parentPage=search

In this USBM100 manual, there appears to be a menu item for
flow control. See page 7 here. Perhaps selecting hardware
flow control will fix it.

http://www.ibizcorp.com/downloads/USBM100 Install.pdf

I get the same sort of display in the Command Prompt after issuing a
MODE command, regardless of whether I use the USB adapter or the
plug-in:

Status for device COM2:
-----------------------
Baud: 1200
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: OFF
XON/XOFF: OFF
CTS handshaking: ON
DSR handshaking: ON
DSR sensitivity: OFF
DTR circuit: HANDSHAKE
RTS circuit: HANDSHAKE

This appears to have hardware handshaking enabled, yet I get absolutely
no response from the plotter, and then DOS come back after a bit with a
message about "The handle is invalid."

 

[Paul]

Hi, Paul --

Thanks for this thoughtful response. There are some interleaved
replies.

Jeff

Possible issues:

1) 8 bit versus 7 bit transparency
2) Flow control method

I think you have (1) covered, by your mode choice of "8".

That's correct. n,8,1 always worked in the past.

It is harder to tell about flow control. There are a couple of
methods, like X-ON/X-OFF or hardware flow control (RTS/CTS on the
cable interface.) You would think the hardware flow control would
be enough to allow the printer, to tell the computer to stop for
a moment when necessary.

Right, everything I've seen says that you need to use hardware
handshaking for the plotter. But as I mentioned, there seem to be more
options for hardware handshaking than previously. To wit:

C:\HELP MODE

returns . . .

Serial port: MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
[to=on|off]
[xon=on|off] [odsr=on|off]
[octs=on|off]
[dtr=on|off|hs]
[rts=on|off|hs|tg]
[idsr=on|off]

It could be that the plotter simply cannot be guaranteed to "eat"
data at 1200 baud (i.e. if flow control is not working for some
reason). For example, try the experiment at 300 baud and
see what happens. (Make sure the plotter is set to 300 baud
before you try.)

It definitely can't eat data at 1200 baud. That's what the ",p" is for
in the MODE command that used to work -- "infinite retry on timeout".
Using 600 baud would typically result in the plotter stopping to wait
for more data, so it seemed like 1200 baud was the way to keep the
pipeline full.

To debug serial problems, you can plug the output of one serial
port, into another serial port. Use a null modem cable or adapter
plug, which will connect TX-RX and RX-TX on the two serial
interfaces (plus do the right things with the flow control
signals). If you set up a Hyperterm on one COM port, then use
your "copy %1 COMn:", you should see the data show up on the
Hyperterm screen. There is presumably a way to redirect the
output to a file, and then you can compare the source file,
and the file that comes back on the other serial port (I used
to do this years ago, but no longer remember the DOS command.)

This is an excellent idea, I will try it. Thanks!

http://www.radioshack.com/product/i...kw=null+modem&kw=null+modem&parentPage=search

In this USBM100 manual, there appears to be a menu item for
flow control. See page 7 here. Perhaps selecting hardware
flow control will fix it.

http://www.ibizcorp.com/downloads/USBM100 Install.pdf

I get the same sort of display in the Command Prompt after issuing a
MODE command, regardless of whether I use the USB adapter or the
plug-in:

Status for device COM2:
-----------------------
Baud: 1200
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: OFF
XON/XOFF: OFF
CTS handshaking: ON
DSR handshaking: ON
DSR sensitivity: OFF
DTR circuit: HANDSHAKE
RTS circuit: HANDSHAKE

This appears to have hardware handshaking enabled, yet I get absolutely
no response from the plotter, and then DOS come back after a bit with a
message about "The handle is invalid."

Paul

There is a page here with the options:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/mode.mspx?mfr=true

and this page suggests:

http://cctr.umkc.edu/ftp/anon_ftp/info/KERMIT/KERMIT.BEWARE

"MODE COM1 RTS=HS OCTS=ON (for RTS/CTS hardware flow control)"

I wonder whether DSR handshaking should be on ?

At some point, I'd have to dig out a voltmeter, and measure
the values on the status lines. At one time, you could get
a LED readout which would show the value on the lines. The
value of the lines should also be available in software.

http://www.eas.asu.edu/~cse521/handouts/RS232_and_flow_control.pdf

This web page is the result of one person's attempts to
debug an RS232 problem.

http://home.att.net/~Tom.Horsley/p4c800e.html

Perhaps in all of that, you can discover what is jammed
Debugging problems like this takes me a while, and part of
the problem is I don't do it often enough to learn anything.
I can tell you, I keep a bag of RS232 connectors of all
types, 25 pin, 9 pin, gender changers, null modem adapter,
and the like, so I can handle virtually any reasonable combo
of 9 and 25 pin devices. But I never invested in a LED
status indicator, and end up using a voltmeter for that.
At least the voltmeter can tell me the static state of the
signals, in cases where something is jammed. An analog meter
is sometimes better, as you can even see when a TX line
is transmitting, as the analog meter will "jump" a bit
for the characters.

Paul

 

[travcoe21]

Paul --

Many thanks for this gold mine of information!!

I'm intriigued by the MS description of the "to" option; it sounds like
the sense of it is the opposite of what I guessed. The option defaults
to off, and was off in the status display I posted earlier; but this
means that infinite time-out processing is off, not that the port can't
time out. That sounds very promising. Apparently the ",p" option
doesn't work anymore, but is not explicitly rejected by COMMAND.COM. I
will try this first, and then your null-modem technique.

The RS-232 "Theory of Operation" document also looks very good.
Between these and the plotter documentation (which I found on CD), I'm
hopeful that I can restore communication to the plotter.

Again, many thanks!

Jeff

Hi, Paul --

Thanks for this thoughtful response. There are some interleaved
replies.

Jeff

Greetings --

Can anyone tell me all of the settings one needs to apply to a serial
port from a Command Prompt window (via the MODE command) in order to
talk to an HP7580 plotter?

With my old W98SE box, all I had to do was open an MS-DOS prompt, type

MODE COMn: 1200,n,8,1,p
copy %1 COMn:

. . . and the plotter would be off and running, with the CPU copying
HPGL plot file %1 to the COMn: port. But with my new XP box I have yet
to successfully do this.

I have tried both a Prolific USB-serial converter and a SIIG PCI
plug-in serial port. With the converter the plotter writes readable
text, but the lines are all garbage. With the plug-in card, I can't
seem to talk to the plotter at all, either from a Command Prompt or
from Windows as an installed printer.

I know that both ports are working, because I have successfully
communicated with another serial device over both. The cable
connecting the CPU to the plotter hasn't changed since the days of the
W98SE box, other than getting rid of a share switch. I do notice, when
I type HELP MODE, that there seem to be many more options for serial
port operation under XP than there are under W98SE, which is what is
prompting my question.

FWIW, I'm using the WinLine HPGL driver to create plot files, both on
the old box and the new. The old box had 2 serial ports on the
motherboard.

TIA for any help anyone can give!

Jeff Travis

Possible issues:

1) 8 bit versus 7 bit transparency
2) Flow control method

I think you have (1) covered, by your mode choice of "8".

That's correct. n,8,1 always worked in the past.

It is harder to tell about flow control. There are a couple of
methods, like X-ON/X-OFF or hardware flow control (RTS/CTS on the
cable interface.) You would think the hardware flow control would
be enough to allow the printer, to tell the computer to stop for
a moment when necessary.

Right, everything I've seen says that you need to use hardware
handshaking for the plotter. But as I mentioned, there seem to be more
options for hardware handshaking than previously. To wit:

C:\HELP MODE

returns . . .

Serial port: MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
[to=on|off]
[xon=on|off] [odsr=on|off]
[octs=on|off]
[dtr=on|off|hs]
[rts=on|off|hs|tg]
[idsr=on|off]

It could be that the plotter simply cannot be guaranteed to "eat"
data at 1200 baud (i.e. if flow control is not working for some
reason). For example, try the experiment at 300 baud and
see what happens. (Make sure the plotter is set to 300 baud
before you try.)

It definitely can't eat data at 1200 baud. That's what the ",p" is for
in the MODE command that used to work -- "infinite retry on timeout".
Using 600 baud would typically result in the plotter stopping to wait
for more data, so it seemed like 1200 baud was the way to keep the
pipeline full.

To debug serial problems, you can plug the output of one serial
port, into another serial port. Use a null modem cable or adapter
plug, which will connect TX-RX and RX-TX on the two serial
interfaces (plus do the right things with the flow control
signals). If you set up a Hyperterm on one COM port, then use
your "copy %1 COMn:", you should see the data show up on the
Hyperterm screen. There is presumably a way to redirect the
output to a file, and then you can compare the source file,
and the file that comes back on the other serial port (I used
to do this years ago, but no longer remember the DOS command.)

This is an excellent idea, I will try it. Thanks!

http://www.radioshack.com/product/i...kw=null+modem&kw=null+modem&parentPage=search

In this USBM100 manual, there appears to be a menu item for
flow control. See page 7 here. Perhaps selecting hardware
flow control will fix it.

http://www.ibizcorp.com/downloads/USBM100 Install.pdf

I get the same sort of display in the Command Prompt after issuing a
MODE command, regardless of whether I use the USB adapter or the
plug-in:

Status for device COM2:
-----------------------
Baud: 1200
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: OFF
XON/XOFF: OFF
CTS handshaking: ON
DSR handshaking: ON
DSR sensitivity: OFF
DTR circuit: HANDSHAKE
RTS circuit: HANDSHAKE

This appears to have hardware handshaking enabled, yet I get absolutely
no response from the plotter, and then DOS come back after a bit with a
message about "The handle is invalid."

Paul

There is a page here with the options:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/mode.mspx?mfr=true

and this page suggests:

http://cctr.umkc.edu/ftp/anon_ftp/info/KERMIT/KERMIT.BEWARE

"MODE COM1 RTS=HS OCTS=ON (for RTS/CTS hardware flow control)"

I wonder whether DSR handshaking should be on ?

At some point, I'd have to dig out a voltmeter, and measure
the values on the status lines. At one time, you could get
a LED readout which would show the value on the lines. The
value of the lines should also be available in software.

http://www.eas.asu.edu/~cse521/handouts/RS232_and_flow_control.pdf

This web page is the result of one person's attempts to
debug an RS232 problem.

http://home.att.net/~Tom.Horsley/p4c800e.html

Perhaps in all of that, you can discover what is jammed
Debugging problems like this takes me a while, and part of
the problem is I don't do it often enough to learn anything.
I can tell you, I keep a bag of RS232 connectors of all
types, 25 pin, 9 pin, gender changers, null modem adapter,
and the like, so I can handle virtually any reasonable combo
of 9 and 25 pin devices. But I never invested in a LED
status indicator, and end up using a voltmeter for that.
At least the voltmeter can tell me the static state of the
signals, in cases where something is jammed. An analog meter
is sometimes better, as you can even see when a TX line
is transmitting, as the analog meter will "jump" a bit
for the characters.

Paul

 

[travcoe21]

To debug serial problems, you can plug the output of one serial
port, into another serial port. Use a null modem cable or adapter
plug, which will connect TX-RX and RX-TX on the two serial
interfaces (plus do the right things with the flow control
signals). If you set up a Hyperterm on one COM port, then use
your "copy %1 COMn:", you should see the data show up on the
Hyperterm screen. There is presumably a way to redirect the
output to a file, and then you can compare the source file,
and the file that comes back on the other serial port (I used
to do this years ago, but no longer remember the DOS command.)

I tried this test last night using a DB9 null modem adapter I bought at
Radio Shack. I installed the null modem between the SIIG port on COM2
and the Prolific adapter on COM8. Opened up HyperTerm, and connected
to COM8. Double checked the port settings on both to make sure they
were the same.

I opened a Command Prompt window and typed

HELP MODE > COM2

The HyperTerm window showed absolutely nothing. When I reversed
directions, with HyperTerm connected to COM2 and the help text
redirected to COM8, I got a few garbage characters.

So, more work to do yet . . . I'm going to buy myself an RS-232
breakout box, I think, and see what I can see.

Jeff

 

[Paul]

I tried this test last night using a DB9 null modem adapter I bought at
Radio Shack. I installed the null modem between the SIIG port on COM2
and the Prolific adapter on COM8. Opened up HyperTerm, and connected
to COM8. Double checked the port settings on both to make sure they
were the same.

I opened a Command Prompt window and typed

HELP MODE > COM2

The HyperTerm window showed absolutely nothing. When I reversed
directions, with HyperTerm connected to COM2 and the help text
redirected to COM8, I got a few garbage characters.

So, more work to do yet . . . I'm going to buy myself an RS-232
breakout box, I think, and see what I can see.

Jeff

In the test where you got a few garbage characters, try the
test again at 9600 baud. Say, for example, that the Mode command
is not working for one of the devices. I assume the default for
most hardware would be 9600 baud or so. I'd try baud rates
until I got a proper response. The garbage characters tells me
it is not stuck due to flow control, but there is likely a
baud rate mismatch.

Paul

 

[Noozer]

In the test where you got a few garbage characters, try the
test again at 9600 baud. Say, for example, that the Mode command
is not working for one of the devices. I assume the default for
most hardware would be 9600 baud or so. I'd try baud rates
until I got a proper response. The garbage characters tells me
it is not stuck due to flow control, but there is likely a
baud rate mismatch.

Just saw this thread, so I'm not sure if this will be helpful or not...

HP Plotters don't use hardware handshaking or XON/XOFF software handshaking
to control data flow.

What happens is that the driver asks the plotter how many characters are
free in the buffer. Then it sends up to that many characters. It asks again,
and sends that many, and asks again... etc.

I don't see the model of plotter here, but a Google should show what a
properly wired cable would look like.

 

[travcoe21]

Just saw this thread, so I'm not sure if this will be helpful or not...

HP Plotters don't use hardware handshaking or XON/XOFF software handshaking
to control data flow.

What happens is that the driver asks the plotter how many characters are
free in the buffer. Then it sends up to that many characters. It asks again,
and sends that many, and asks again... etc.

I don't see the model of plotter here, but a Google should show what a
properly wired cable would look like.

It's an HP7580B. I actually found the manuals for sale on CD on Ebay,
so I have those. I don't think the cable is the problem. It's the
same cable I used previously when the plotter was connected to the old
W98SE box.

With the flow control you describe, how would you suggest that all the
parameters of MODE should be set? Ref. Paul's link earlier in the
thread, to the Microsoft page that describes all the parameter of MODE
offered under XP.

Thanks for your contribution!

Jeff

 

[travcoe21]

In the test where you got a few garbage characters, try the
test again at 9600 baud. Say, for example, that the Mode command
is not working for one of the devices. I assume the default for
most hardware would be 9600 baud or so. I'd try baud rates
until I got a proper response. The garbage characters tells me
it is not stuck due to flow control, but there is likely a
baud rate mismatch.

Paul

It's true, I only tried one baud rate, but I'm almost positive that I
verified the settings were the same on both Tx and Rx ports. I'll go
back and try the test again, and double-check the baud rates are the
same on both ports.

I think also that there may be something else weird going on. I can't
recount the sequence of events, but at some point during the loopback
test I noticed the blue LED on my Belkin bluetooth USB dongle was
blinking. It also maps to a COMn: port, I think 4 and/or 6, and
shouldn't have been invoked by the test, which was only supposed to
exercise COM2: (SIIG card) and COM8: (Prolific USB adapter). Then I
discovered that the other serial device I had connected to the second
port on the SIIG card (COM9 wasn't working. It took a reboot to
clear that situation up, and I had to get some real work done, so
abandoned the test. From the symptoms I'm guessing that the OS somehow
got the port assignments mixed up, but can't draw any firm conclusions.

Sheesh, RS-232 is such a PITA!

Jeff

 

[Noozer]

It's an HP7580B. I actually found the manuals for sale on CD on Ebay,
so I have those. I don't think the cable is the problem. It's the
same cable I used previously when the plotter was connected to the old
W98SE box.

With the flow control you describe, how would you suggest that all the
parameters of MODE should be set? Ref. Paul's link earlier in the
thread, to the Microsoft page that describes all the parameter of MODE
offered under XP.

From
http://www.robosys.com/hardware/plotter1.htm#Hewlett Packard HP7580A/HP7580B/HP7585


Hewlett Packard HP7580A/HP7580B/HP7585

Cable : Type B
Data Format : 9600 baud, 8 data bits, 1 stop bit, no parity
Diagram of Rear Panel Switch Settings

INTERFACE MODE x RS-232-C EXPAND x NORMAL
LISTEN ONLY x NORMAL EMULATE x NORMAL
A1 x STAND ALONE x EAVESDROP
A2 x MONITOR MODE x NORMAL
A3 x LOCAL x NORMAL
A4 x
A5 x COMPUTER MODEM
PARITY ON x OFF Plug serial cable into
PARITY EVEN x ODD this socket.
DUPLEX HALF x FULL
HARDWIRE x MODEM
DTR BYPASS x NORMAL







HPGL (Hewlett-Packard Graphics Language) and HPGL/2

The differences between HPGL and HPGL/2 are not significant for our
purposes. However, HPGL/2 has certain problems dealing with varying line
types, so we suggest using HPGL when you have the choice. Set your
printer/plotter to HPGL (or HPGL/2) and use one of the following plotter
drivers:

1. DraftMaster - A through E (A4 - A0) size, the smallest margin (most
coverage) of the HPGL devices.
2. HP7580 - A through D (A4 - A1) size, wider margins (less coverage)
than DraftMaster
3. HP7585 - A through E (A4 - A0) size, wider margins (less coverage)
than DraftMaster
4. HP7475 - A and B (A4 and A3) size, the common default for HPGL file
generation

 

[Paul]

http://www.robosys.com/hardware/plotter1.htm#Hewlett Packard HP7580A/HP7580B/HP7585

Hewlett Packard HP7580A/HP7580B/HP7585

Cable : Type B
Data Format : 9600 baud, 8 data bits, 1 stop bit, no parity
Diagram of Rear Panel Switch Settings

INTERFACE MODE x RS-232-C EXPAND x NORMAL
LISTEN ONLY x NORMAL EMULATE x NORMAL
A1 x STAND ALONE x EAVESDROP
A2 x MONITOR MODE x NORMAL
A3 x LOCAL x NORMAL
A4 x
A5 x COMPUTER MODEM
PARITY ON x OFF Plug serial cable into
PARITY EVEN x ODD this socket.
DUPLEX HALF x FULL
HARDWIRE x MODEM
DTR BYPASS x NORMAL

HPGL (Hewlett-Packard Graphics Language) and HPGL/2

The differences between HPGL and HPGL/2 are not significant for our
purposes. However, HPGL/2 has certain problems dealing with varying line
types, so we suggest using HPGL when you have the choice. Set your
printer/plotter to HPGL (or HPGL/2) and use one of the following plotter
drivers:

1. DraftMaster - A through E (A4 - A0) size, the smallest margin (most
coverage) of the HPGL devices.
2. HP7580 - A through D (A4 - A1) size, wider margins (less coverage)
than DraftMaster
3. HP7585 - A through E (A4 - A0) size, wider margins (less coverage)
than DraftMaster
4. HP7475 - A and B (A4 and A3) size, the common default for HPGL file
generation

This is an archived web page from the HP site. They are showing a serial
port cable wiring that looks like it includes hardware flow control of
some type. It doesn't match the typical wiring diagrams shown in
the flow_control document below.

http://web.archive.org/web/20021225...cposupport/plotters/support_doc/bpp01402.html

This doc describes some of the issues around flow control.

http://www.eas.asu.edu/~cse521/handouts/RS232_and_flow_control.pdf

If the plotter is sending back something, then that is a "protocol".
A driver would be needed, to intercept the information and behave
according to the protocol. XON/XOFF or hardware flow control, are
lower level features available via the OS, and their use means no
further driver would be required.

Paul

 

[travcoe21]

From
http://www.robosys.com/hardware/plotter1.htm#Hewlett Packard HP7580A/HP7580B/HP7585


Hewlett Packard HP7580A/HP7580B/HP7585

Cable : Type B
Data Format : 9600 baud, 8 data bits, 1 stop bit, no parity
Diagram of Rear Panel Switch Settings

INTERFACE MODE x RS-232-C EXPAND x NORMAL
LISTEN ONLY x NORMAL EMULATE x NORMAL
A1 x STAND ALONE x EAVESDROP
A2 x MONITOR MODE x NORMAL
A3 x LOCAL x NORMAL
A4 x
A5 x COMPUTER MODEM
PARITY ON x OFF Plug serial cable into
PARITY EVEN x ODD this socket.
DUPLEX HALF x FULL
HARDWIRE x MODEM
DTR BYPASS x NORMAL







HPGL (Hewlett-Packard Graphics Language) and HPGL/2

The differences between HPGL and HPGL/2 are not significant for our
purposes. However, HPGL/2 has certain problems dealing with varying line
types, so we suggest using HPGL when you have the choice. Set your
printer/plotter to HPGL (or HPGL/2) and use one of the following plotter
drivers:

1. DraftMaster - A through E (A4 - A0) size, the smallest margin (most
coverage) of the HPGL devices.
2. HP7580 - A through D (A4 - A1) size, wider margins (less coverage)
than DraftMaster
3. HP7585 - A through E (A4 - A0) size, wider margins (less coverage)
than DraftMaster
4. HP7475 - A and B (A4 and A3) size, the common default for HPGL file
generation

That's how I have all of the switches set. Haven't changed them from
the days when the plotter worked correctly with W98SE.

Still wondering about all the parameters offered for MODE by SP.

Jeff

 

[travcoe21]

This is an archived web page from the HP site. They are showing a serial
port cable wiring that looks like it includes hardware flow control of
some type. It doesn't match the typical wiring diagrams shown in
the flow_control document below.

http://web.archive.org/web/20021225...cposupport/plotters/support_doc/bpp01402.html

This doc describes some of the issues around flow control.

http://www.eas.asu.edu/~cse521/handouts/RS232_and_flow_control.pdf

If the plotter is sending back something, then that is a "protocol".
A driver would be needed, to intercept the information and behave
according to the protocol. XON/XOFF or hardware flow control, are
lower level features available via the OS, and their use means no
further driver would be required.

Paul

I should take a DMM and verify the pinout of the cable matches the one
shown on the cached HP page. It looks like a null modem cable, with
pins 2 & 3 crossed. If mine isn't like that I guess I can throw the
DB9 null modem adapter in line with the cable. I doubt the cable is the
problem, because the same cable worked with the plotter connected to
the old W98SE box; but will check anyway.

Any ideas re: all of the parameters offered for MODE by XP?

Jeff

 

[Paul]

I should take a DMM and verify the pinout of the cable matches the one
shown on the cached HP page. It looks like a null modem cable, with
pins 2 & 3 crossed. If mine isn't like that I guess I can throw the
DB9 null modem adapter in line with the cable. I doubt the cable is the
problem, because the same cable worked with the plotter connected to
the old W98SE box; but will check anyway.

Any ideas re: all of the parameters offered for MODE by XP?

Jeff

Working out what the cable is wired for, is not a bad idea.

There are some examples of MODE here:
http://support.microsoft.com/kb/94297/en-us

I think first, I would want to debug your RS-232 capability, to the
point of being able to send a reliable stream out of some RS-232
device on your cpmputer. If you are getting garbage characters, then
there isn't much point refining any other details, whether it is
Noozer's description of an actual protocol being used, or some
kind of flow control. You have to get the baud rates in agreement,
and the output capability working, in such a way that you can prove
that part works.

http://www.bogpeople.com/networking/SerialComms/rs232pinouts.shtml

Looking at it again, the 25-25 HP cable wiring suggested, could
just be using DTR to keep the two signals on the other side
"happy", and not actually doing flow control via DTR.

Say Noozer's idea is the correct one - if it is, you cannot simply
spew a file at an ungodly baud rate, right at the plotter. You would
need some kind of application (a "spooler" if you will), which is
looking for whatever the plotter is sending back. If you choose
to ignore the info the plotter is sending back, then choosing a
transmit baud rate of 300 would be the next best thing (slow but
steady wins the race).

One example of software flow control, is XON/XOFF. AFAIK, that is
not eight bit clean, so only seven bit data can go across the link.
I don't think that is the idea in your case - but you can examine
your plot file, to see whether it has 7 bit or 8 bit data in it.

XON/XOFF is intercepted by the serial port driver. That is essentially
a free lunch for you, in terms of flow control. If the plotter is
sending an available buffer size at some interval, across the link,
then something on your computer has to look at that number, and then
send a limited amount of data in response. That would be a
"spooler" of some sort, and the spooler has to follow the
protocol.

I think I could eventually solve the problem, if I was sitting
there in front of the equipment, but I don't know if I can do
much to help you from here

If you could use something like Hyperterminal, or some other
terminal application, and you could look at the character
stream coming back from the plotter, that might tell you
whether a higher level protocol is being used or not.

Paul

 

[travcoe21]

Working out what the cable is wired for, is not a bad idea.

There are some examples of MODE here:
http://support.microsoft.com/kb/94297/en-us

I think first, I would want to debug your RS-232 capability, to the
point of being able to send a reliable stream out of some RS-232
device on your cpmputer. If you are getting garbage characters, then
there isn't much point refining any other details, whether it is
Noozer's description of an actual protocol being used, or some
kind of flow control. You have to get the baud rates in agreement,
and the output capability working, in such a way that you can prove
that part works.

http://www.bogpeople.com/networking/SerialComms/rs232pinouts.shtml

Looking at it again, the 25-25 HP cable wiring suggested, could
just be using DTR to keep the two signals on the other side
"happy", and not actually doing flow control via DTR.

Say Noozer's idea is the correct one - if it is, you cannot simply
spew a file at an ungodly baud rate, right at the plotter. You would
need some kind of application (a "spooler" if you will), which is
looking for whatever the plotter is sending back. If you choose
to ignore the info the plotter is sending back, then choosing a
transmit baud rate of 300 would be the next best thing (slow but
steady wins the race).

One example of software flow control, is XON/XOFF. AFAIK, that is
not eight bit clean, so only seven bit data can go across the link.
I don't think that is the idea in your case - but you can examine
your plot file, to see whether it has 7 bit or 8 bit data in it.

XON/XOFF is intercepted by the serial port driver. That is essentially
a free lunch for you, in terms of flow control. If the plotter is
sending an available buffer size at some interval, across the link,
then something on your computer has to look at that number, and then
send a limited amount of data in response. That would be a
"spooler" of some sort, and the spooler has to follow the
protocol.

I think I could eventually solve the problem, if I was sitting
there in front of the equipment, but I don't know if I can do
much to help you from here

If you could use something like Hyperterminal, or some other
terminal application, and you could look at the character
stream coming back from the plotter, that might tell you
whether a higher level protocol is being used or not.

Paul

Paul --

I greatly appreciate the helpful links and suggestions you've provided.
When I have time and eqpt (DMM/BOB) to diagnose the problem further,
I'll report back to let you know what I figured out. Thanks much!

Jeff