Printing stops with USB to Serial adapter

[Tore Bostrup]

I am struggling with printing to a receipt printer (serial port Star
Micronics SP212 with Line mode driver installed) through a USB to Serial
adapter (sorry - don't have the USB/Serial driver name available here).

The output starts normally, but after a number of lines of output, it simply
stops printing. It is possible that this is after the printer's internal
buffer fills up (about 1kb IIRC). At this point, there is no error message,
and no more output.

I have tried a number of different settings, and at this point it is all a
blur. Previously, I have been able to print all, but received an error
message from the print spooler - but if I ignore it, the printing seems to
complete.

I will eventually be printing a sizable strip of paper from (hopefully)
thousands of systems, and need for this to work flawlessly. Does anyone
have any experience with this type of configuration - and what did you have
to do?

TIA,
Tore.

 

[J French]

I am struggling with printing to a receipt printer (serial port Star
Micronics SP212 with Line mode driver installed) through a USB to Serial
adapter (sorry - don't have the USB/Serial driver name available here).

The output starts normally, but after a number of lines of output, it simply
stops printing. It is possible that this is after the printer's internal
buffer fills up (about 1kb IIRC). At this point, there is no error message,
and no more output.

I have tried a number of different settings, and at this point it is all a
blur. Previously, I have been able to print all, but received an error
message from the print spooler - but if I ignore it, the printing seems to
complete.

I will eventually be printing a sizable strip of paper from (hopefully)
thousands of systems, and need for this to work flawlessly. Does anyone
have any experience with this type of configuration - and what did you have
to do?

I'm surprized that you are not controlling the printer directly from
the COM port

 

[Dick Grier]

Hi,

This sounds like either a fault with the printer or the USB/serial driver.
And, yes, it might be connected with a failure of flow control (either
hardware or software). Without lots more information, it would be hard to
speculate more.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.

 

[Tore Bostrup]

I have been unable to set it up correctly without actually installing the
printer driver. The printer will print its settings, except for stop bits
and flow control parameters, and I have tried all combinations thereof
without achieving success (but I have to admit I probably didn't reboot
between each setting change). The printer driver apparently does something
additional, and I haven't been able to determine what. Also, after
installing and using the printer driver, I can output directly to the COM
port. But after reboot, etc., it appears that I have to print to the
printer driver first.

Tore.

 

[Tore Bostrup]

Yes - it does appear that something is not well-behaved. As I wrote in my
response to J French, I have tried all combinations of stop bits and flow
control settings - without being able to output (reliably) to the COM port
directly.

Tore.

 

[PointZero FR]

The USB to Serial converter is branded Manhattan "USB TO SERIAL CONVERTER"
(model number 205146, UPC 766623205146), the driver identifies itself as
"Prolific USB-to-Serial Bridge" version 2.0.0.24, and I'm pretty sure it is
a flow control issue.

With flow control set to Hardware, the spooler ("Printers Folder") gets an
error "There was an error found printing the document ... to COM4:. Do you
want to retry or cancel the print job?". If I ignore this, the entire
output prints, and the message goes away.

With flow control set to Xon/Xoff or None, the output stops fairly
consistently after a byte count (~1300-1400+ characters as counted from my
app). The printer's buffer is supposedly 1kb (or somewhere close).

I have tried to configure the printer to print directly to the printer (i.e.
not spool the output so I can add some waiting), but that does not appear to
work. The output does not start until i end the print job (VB6
Printer.EndDoc). We are using VB6 SP4 on Win2k Pro SP2 (don't ask me why,
but if it makes a difference, I'd be interested...).

Output directly to the COM port tends to show up as a bunch of question
marks and blanks as if the parity or framing was off - but it is configured
according to the printer's status page (except I've tried all combinations
of stop bits and flow control - these are not printed on the printer's
status page). It is also the same settings as used for the printer driver
(when successfully printing using it).


Tore.

 

[J French]

I have been unable to set it up correctly without actually installing the
printer driver. The printer will print its settings, except for stop bits
and flow control parameters, and I have tried all combinations thereof
without achieving success (but I have to admit I probably didn't reboot
between each setting change). The printer driver apparently does something
additional, and I haven't been able to determine what. Also, after
installing and using the printer driver, I can output directly to the COM
port. But after reboot, etc., it appears that I have to print to the
printer driver first.

That is extremely interesting, it suggests that the printer driver is
performing some sort of setup (sending ESC chars to the printer ?)

Do you really need the printer driver ?
It is only really useful if you are doing graphics and fancy fonts

It is possible that the printer needs to be 'woken up' by raising the
DTR

I think you need to go back to the raw documentation for the printer
(not the driver)

Incidentally on a Zebra printer I had terrific problems with buffer
overflow under XP and on fast machines - using USB <-> RS232
The only way I could solve the problem was by physically slowing down
the flow of data.

If I were you I would persevere with the MSCOMM control

I would also try to get it running on a standard COM port before using
the USB one.

 

[Thorsten Albers]

I am struggling with printing to a receipt printer (serial port Star
Micronics SP212 with Line mode driver installed) through a USB to Serial
adapter (sorry - don't have the USB/Serial driver name available here).
The output starts normally, but after a number of lines of output, it simply
stops printing. It is possible that this is after the printer's internal
buffer fills up (about 1kb IIRC). At this point, there is no error message,
and no more output.
I have tried a number of different settings, and at this point it is all a
blur. Previously, I have been able to print all, but received an error
message from the print spooler - but if I ignore it, the printing seems to
complete.
I will eventually be printing a sizable strip of paper from (hopefully)
thousands of systems, and need for this to work flawlessly. Does anyone
have any experience with this type of configuration - and what did you have
to do?

- Are You sure, that the printer driver apropriate for Your OS and printer
modell is installed correctly?
- Are You sure, that the driver for the USB-2-Serial adapter appropriate
for Your OS and adapter modell is installed correctly?
- Are Your sure, that Your are using an appropriate cable? If any, observe
printer peculiarities. E.g. for Star Micronics serial printers there is the
following note: "Star serial receipt printers use a DTE cable between the
computer and printer - this is NOT the same cable used between the computer
and an external modem". Make sure, that, if Your printer needs such a
special cable, the USB-2-Serial adapater is able to work with such a cable
too.
- If possible, try connecting the printer to the serial interface of
another computer and see, if there it works correctly (of course You will
have to install the printer driver there too; "another computer" because
Your using of a USB-2-Serial adapter leads me to the assupmtion that >Your<
computer doesn't have a serial interface). This at least could exclude
problems with the printer itself and would point to problems with the
connection.

With flow control set to Hardware, the spooler ("Printers Folder") gets an
error "There was an error found printing the document ... to COM4:. Do you
want to retry or cancel the print job?". If I ignore this, the entire
output prints, and the message goes away.
With flow control set to Xon/Xoff or None, the output stops fairly
consistently after a byte count (~1300-1400+ characters as counted from my
app). The printer's buffer is supposedly 1kb (or somewhere close).

- Did You try not only to change the flow control but to reduce or enlarge
the interface's (COM4) bit rate, stopp bit, parity settings, and so on? You
will find these settings in interface's property dialog within the device
manager.

And at least: Does the manual of the printer or the manual of the adapter
really state nothing about this?

--

 

[PointZero FR]

Thanks - that is an interesting point about the "special DTE cable" - I'm
not sure what the exact difference is (is that a DTE-DTE cable?), but I can
see how that might make a difference when working with a USB-to-serial
adapter. As mentioned, this is a Star Micronics SP212.

Your assumption about not having a serial port is correct. And we should
probably just bite the bullet and purchase a USB version of the printer -
but this was meant for a quick demo before we actually sell this particular
printing capability. Anyway, I should probably try the printer on a
computer with a serial port - the printer is not new, and although the cable
was with the printer, it may not be the correct one (it hadn't been used in
a while).

As for your other comments, I installed both the printer and USB drivers for
Windows 2000 (on Windows 2000 system) according to the documentation AFAICT.

The bit rate, parity, and data bit length are printed on a hardware status
print (FF during power on), and are reported as 9600BPS, No parity (actually
prints NONE PARITY), and 8BIT. I tried all combinations of stop bit (1,
1.5, 2) and flow control (HW, Xon/Xoff, None) attempting to output directly
to the COM port, but get what appears as either framing errors or parity
errors (a mixture of question marks and blanks). And if by "the manual of
the adapter" are referring to the USB to Serial adapter, that "manual"
consists of five bullet points (at marketing level) in six languages printed
on the back of the packaging (typical cable package, clear plastic front and
sliding cardboard back stapled on). The driver disk is a generic USB driver
disk with drivers for 19 different USB-to-something drivers.

I did not find anything in the Star Micronics documentation (found online)
that indicated stop bits or flow control settings. But then again, I did
not read them from cover to cover (didn't know about the special cable
requirement).

Tore.

 

[Thorsten Albers]

Thanks - that is an interesting point about the "special DTE cable" - I'm
not sure what the exact difference is (is that a DTE-DTE cable?), but I can
see how that might make a difference when working with a USB-to-serial
adapter. As mentioned, this is a Star Micronics SP212.

I am sorry, I cann't tell You either. Maybe You will find some usefull
information here:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_fix/805/805hwin/s
erial.pdf
It seems to be mainly a different pin setting for the pins RxD and TxD of
the interface. This AFAIK could very well lead to problems with the
USB-2-Serial adapter.
Did You check the properties of the adapter driver? Maybe here one can
determine wether the serial cable plugged into the adapter connects to a
DTE (printer etc.) or a DCE (modem etc.).

Googleing with "+dte +cable" shows up, that DTE cables seem to be sold
everywhere in stores which sell printer equipment.

Your assumption about not having a serial port is correct. And we should
probably just bite the bullet and purchase a USB version of the printer -
but this was meant for a quick demo before we actually sell this particular
printing capability.

Instead I would think about an expansion card for Your computer which for
example provides You with two serial ports. They are very cheap, usually
don't need drivers and don't lead to any problems.

Anyway, I should probably try the printer on a
computer with a serial port - the printer is not new, and although the cable
was with the printer, it may not be the correct one (it hadn't been used in
a while).

In this case I would assume that You already have an DTE cable (since it
was shipped with the printer), and that the USB-2-Serial adapter only can
deal with DCE cables (that which are used for modems). Or maybe You
manually have to set the adapter's driver to work with DTE. Have a look
into the properties' dialog of the adapter (if there is one...).

As for your other comments, I installed both the printer and USB drivers for
Windows 2000 (on Windows 2000 system) according to the documentation AFAICT.

The bit rate, parity, and data bit length are printed on a hardware status
print (FF during power on), and are reported as 9600BPS, No parity (actually
prints NONE PARITY), and 8BIT. I tried all combinations of stop bit (1,
1.5, 2) and flow control (HW, Xon/Xoff, None) attempting to output directly
to the COM port, but get what appears as either framing errors or parity
errors (a mixture of question marks and blanks). And if by "the manual of
the adapter" are referring to the USB to Serial adapter, that "manual"
consists of five bullet points (at marketing level) in six languages printed
on the back of the packaging (typical cable package, clear plastic front and
sliding cardboard back stapled on). The driver disk is a generic USB driver
disk with drivers for 19 different USB-to-something drivers.

Did You change the interface speed for the COM4 port to 9600 Bps? With a
modem one usually sets the speed to the double or the quadruple of the
modem speed, but with a serial printer this may be different.
And maybe You should check, how the printer works with either the FIFO
buffer settings modified or the FIFO turned of in general. The FIFO is
known to be a source for problems with older equipment, because it may
deliver the data too fast to the external device so that this does not get
all data. You will find the FIFO settings in the extended properties of the
COM port within the device manager.

--

 

[Thorsten Albers]

Instead I would think about an expansion card for Your computer which for
example provides You with two serial ports. They are very cheap, usually
don't need drivers and don't lead to any problems.

What I have forgotten:
Also modern mainboards usually still have support for at least one serial
port. If so, You will find the pins for this on the mainboard by searching
the mainboard documentation or by searching about 10 or 9 pins, 4/5
parallel to the other 5, marked as "COM". You only need an appropriate
cable for this to make it available. But take care to get a cable that is
compatible to Your mainboard since the pin settings may differ from
manufacturer to manufacturer.

--

 

[Tore Bostrup]

Special molded case - no room for expansion cards - and no room for
additional external connectors either. Think retail system or laptop
without a PCMCIA slot. Even if a serial port could be added, we'll probably
go to a straight USB model printer since they exist and we are already
planning for USB. These will be dedicated systems.

I have learned a few more things:

The parity/framing-like problem only occurs when opening the COM port for
(sequential) output and printing to it

hfCommPort = FreeFile
Open "COM4:" For Output As #hfCommPort
Print #hfCommPort, "Printing Something"

A hex dump of this output showed a mix of 80 and 3D(?) byte values printed
using the above method... I'm pretty sure I did this successfully on an
Ithaca receipt printer in the past...

Printing to the SP212 Line Mode Driver works when using Hardware Flow
Control, but spooler gets an error during printing. Output completes
apparently OK.

I have dumped the initialization string used by the printer driver and
determined that it is not strictly required (unless the printer was left in
a funky state for some unknown reason).

Using the MSComm control seems to work, and I have recorded CTS events (and
I can wait for CTSHolding to revert) which seem to signal readiness of the
printer (as CTS should). However, I had really hoped to avoid using this
approach. There's really no need for my app to have to deal with the
printer status details, and I probably won't even get to test it enough to
make sure I have all the different statuses and status methods covered. In
addition, I'll have to implement what I consider a somewhat clunky
workaround for invoking the printing from multiple forms, a couple of which
are modal - making the whole printing process less than straightforward.
But those are just code mechanics which can be worked out.

I have adjusted the FIFO buffers down to 1 each to avoid any such issues.
No difference detected.

Anyway, at this point I will proceed with the "kludge" using a modal form
with an MSCOMM control that starts the printing from the Form_Activate
event. Next on the agenda will be obtaining a USB model of the printer (or
a comparable model).

Thanks to all for the help.

Tore.

 

[Thorsten Albers]

The parity/framing-like problem only occurs when opening the COM port for
(sequential) output and printing to it
hfCommPort = FreeFile
Open "COM4:" For Output As #hfCommPort
Print #hfCommPort, "Printing Something"

Accessing the printer this way would mean to send raw data to the printer.
There is a better way to do so under Windows:

- OpenPrinter()
Get the printer handle
- StartDocPrinter()
Start print job

- StartPagePrinter()
Initialize new page
- WritePrinter()
Send raw data to the printer
- ...
- EndPagePrinter()
Terminate current page

- StartPagePrinter()
- WritePrinter()
- ...
- EndPagePrinter()

- EndDocPrinter()
Terminate print job
- ClosePrinter()
Close printer

The advantage of this is that, if needed, You still have control over the
printer job and printer status by using API functions like
GetPrinterInfo(), EnumJobs(), SetJob(), etc.
Another advantage is that You are using the printer driver to access the
printer, and that You don't have to bother to which port the printer is
connected. It should work with Your printer connected to the serial port or
the USB-2-Serial adapter as well as with a new printer connected to an USB
port.

There is a MS Knowledge Base article on this:
HOWTO: Send Raw Data to a Printer Using the Win32 API from Visual
Basic Microsoft Knowledge Base Article - 154078
http://support.microsoft.com/?scid=kb;en-us;154078

It is a little bit more complex than using Open "COM4:" ..., but it is less
complex than using the communications control.

If You still want to try to work with Open "COM4:" ..., You may pay
attention to this:
In other BASIC dialects it was possible to specify the COM parameters with
the Open statement. E.g. it was possible to open the COM1 port with a baud
rate of 300, no parity, 8 data bits and 1 stop bit by using the statement
Open "COM1:300,N,8,1" ...
Unfortunately I don't know, if this is still possible with VB.

Another way which You could try:
Install the printer driver "General/Text only" shipped with windows and
connect it (via the printer driver's property dialog) to the COM4 port.
Then You may try to print 'raw data' with the VB printer object.

--

 

[J French]

Accessing the printer this way would mean to send raw data to the printer.
There is a better way to do so under Windows:

- OpenPrinter()
Get the printer handle

There are substantial advantages in /not/ using the Print Spooler in
certain types of applications.

Configuration of the COM port now needs to be done through APIs unless
one uses the COMM control - no support in VB

 

[Guest]

install proper drive and try the below link,
http://www.starmicronics.com/printers/printers_pages/support/programming.html#
open%20a%20cash%20drawer

 

[Guest]

install proper driver & try the below link

http://www.starmicronics.com/printers/printers_pages/support/programming.html#open a cash drawer

 

[Tore Bostrup]

Thanks for responding, but if you check the rest of this thread, you will
realize that there is no help to be found on that page - and that the
problem is (probably) related to the "special" configuration of using a USB
to Serial adapter cable (no serial port on computer).

There may be a better driver for the USB to Serial adapter somewhere, but
due to its generic nature I don't know what would be the best driver to use
for it. If you have detailed knowledge about such drivers, I'd be very
interested. As mentioned in a previous post, the "... USB to Serial
converter is branded Manhattan "USB TO SERIAL CONVERTER" (model number
205146, UPC 766623205146), the driver identifies itself as "Prolific
USB-to-Serial Bridge" version 2.0.0.24, and I'm pretty sure it is a flow
control issue."

Regards,
Tore.

install proper driver & try the below link

http://www.starmicronics.com/printers/printers_pages/support/programming.html#open a cash drawer

 

[Tore Bostrup]

I know - and I have used the printing API's in the past - especially when
the printer/job status was an important aspect. However, as mentioned in a
previous post - the spooler itself was generating an error message - I can
print to the spooler OK.

I did not try the Generic/Text Only printer driver. At the moment, my code
is working with the MSCOMM control and using CTS for flow control. I did
receive a class from another helpful poster that does the same with API's,
but haven't had a chance to look at it yet.

Personally, I like working through the printer driver/spooler - using VB
native or API constructs depending on what level of control and performance
I require. Since the only thing I really needed was to perform a simple
print job, the VB Printer object *should* have been sufficient. As it
stands, my trivial 10-line print routine now stands at one class module with
three properties and 5 methods, a form to accommodate the MSCOMM control,
several supporting functions, and implementing a rather kludgy print job
invocation logic (called from a modal form - among other places, so the form
containing the control must be modal, and printing must therefore start from
the Form_Activate event and output parameters must be passed by setting
public properties on the form). Sure I could leave the form hidden, but I
don't like that in case of unforeseen problems resulting in memory leaks
(i.e. the form remaining in memory after printing terminated).

At this point, we *will* be ordering a "real" USB receipt printer (any
suggestions for an inexpensive one?) - and hopefully all the problems will
go away so I can use those 10 trivial lines again... :->

Regards,
Tore.

 

[Thorsten Albers]

There may be a better driver for the USB to Serial adapter somewhere, but
due to its generic nature I don't know what would be the best driver to use
for it. If you have detailed knowledge about such drivers, I'd be very
interested. As mentioned in a previous post, the "... USB to Serial
converter is branded Manhattan "USB TO SERIAL CONVERTER" (model number
205146, UPC 766623205146), the driver identifies itself as "Prolific
USB-to-Serial Bridge" version 2.0.0.24, and I'm pretty sure it is a flow
control issue."

Although You already have stated that You want to by an USB receipt
printer, here is one more try...

Did You observe what is stated for the driver installation on this page?
http://www.manhattan-support.com/helpdocs/205146_winxp_install-english.shtml


- especially what is said in the last paragraph:
"Once the adapter is installed, it will show up in the device manager under
COM and LPT devices. The >>adapters properties dialog, port settings<< lets
you specify options for the new COM port, i.E. Data Transmission Rate, Data
Bits, Flow Control and so on."

Also:

"USB To RS232 Adapter: How to change the COM port settings?"
http://www.manhattan-support.com/faq/index.php?sid=67321&aktion=artikel&rubr
ik=003004&id=8&lang=en

--

 

[Tore Bostrup]

No - I sure had not found those!

Thanks,
Tore.

Although You already have stated that You want to by an USB receipt
printer, here is one more try...

Did You observe what is stated for the driver installation on this page?
http://www.manhattan-support.com/helpdocs/205146_winxp_install-english.shtml


- especially what is said in the last paragraph:
"Once the adapter is installed, it will show up in the device manager under
COM and LPT devices. The >>adapters properties dialog, port settings<< lets
you specify options for the new COM port, i.E. Data Transmission Rate, Data
Bits, Flow Control and so on."

Also:

"USB To RS232 Adapter: How to change the COM port settings?"
http://www.manhattan-support.com/faq/index.php?sid=67321&aktion=artikel&rubr
ik=003004&id=8&lang=en

--