Serial POS printer problem 2

[MangroBongacello]

Hi all,

I've found a few threads about this but they were not answered, so I hope I will have more luck. When printing longer .txt files (longer means 30 lines of text) to a serial pos printer, only few lines of text are printed correctly then it all gets messed up and not everything is even printed. It works fine with parallel printers. I use code like this to send data to a printer (using a batch program)

copy MyFile.txt com1

Any ideas?
Mangro

 

[TheTuna]

I'm not sure what the cause is, but I can recommend a work around...

Trying breaking up the send. If only the first 3 lines of the text send correctly, try sending it one line at a time.

when you say pos printer do you mean a Point of Sale printer, such as a receipt printer?

Is it possible that the printer doesn't have enough buffer space to receive all the text at once? If so, you'll need to go ahead and break up the text into smaller parts and send it that way.

Let me know what happens.

Tuna - It's fat free until you add the Mayo!

 

[John Lewis]

Serial POS printers are so simple they can be a real pain.

TheTuna has the right idea, you are most certainly overrunning the printer.

Breaking the data into chunks is the right idea, but simply sending a few lines at a time doesn't take care of the whole problem. The other part of the equation is how long to wait between sending chunks. If you don't wait long enough, you will still be missing data. There has to be room in the buffer to hold the chunk that you are sending. Send more too soon, and there won't be room yet. Wait to long, and the printer will run out of stuff to print, and the customer will be staring at the clerk wondering if he is ever going to get a receipt.

I think the real answer here is to look at your serial line flow control. Flow control, oddly enough, allows the printer to control the flow of data to it's buffer.

There are two types of flow control. Hardware flow control (RTS/CTS) is somewhat more reliable, but it requires extra wires in the cable connecting the printer to the computer. If you are using a mass produced cable with a 9 pin connector on both ends, the wires are probably there. POS printers are commonly hooked up with telephone type connections, which sometimes don't have the flow control lines wired.

Software flow control (XON/XOFF) does not require the extra wires, so it is almost always available. Main thing is you will have to use the same thing on both ends (printer and computer). Windows is capable of both, so start with your printer manual. Check the index for handshaking or flow control. If the manual is not available, examine the printer itself. The flow control option is generally set by a set of dip switches or a header. You might get lucky enough to find a label on the printer that explains how to configure it.

Don't be surprised if you find that some kind of flow control is already enabled on the printer side. It is almost always required, so the factory default is usually for one kind or the other to be enabled.

Next problem is making sure that the computer is configured to use the same form of handshaking as the printer. Start in the Windows control panel. Some versions have an icon for 'ports' there, others you will need double click on the 'system' icon, then selecting the 'hardware' tab, then click the device manager button, then click on 'ports', and finally double click on 'communications port (comX)'. Either way, click on the port settings tab and select the proper flow control to match the printer.

If by chance the printer and the computer were both already set to hardware flow control, I would suspect a faulty or miswired serial cable. That actually happens quite often.

Sorry for the lengthy post, and hope I made some sense as it is now 1:49am.

Good luck
John

 

[TheTuna]

Thanks John, thats good info considering I'm about to enter the printer coding phase on a kiosk application. At this point though, I'm still waiting to find out what model of printer my client will be using. It's been so long since I've used a serial printer, and I'm praying that it is NOT a serial printer...

Still, very qualified and well explained for the wee hours of the mornining. I'm giving you a Christmas Star! Tuna - It's fat free until you add the Mayo!

 

[MangroBongacello]

Thanks John, I checked all you suggest and everything seemed to be ok. I'm not too familiar with all this so I experimented with all possible flow controls, parity checks, data bits and all that stuff... I too suspected that the problem was a full receive buffer. In my first post I forgot to mention that I was doing some configuring on a com port before sending the data to the printer, otherwise nothing was printed at all. So my batch program looked like this:

mode com1: 2400,n,8,1
copy MyFile.txt com1

2400 - dip switch setting on a printer

And then, I guess God must be in a good mood (his son's birthday and all), he has shown me the light. On a more or less unrelated web page I saw how to configure com port to keep retrying sending data when the receive buffer of a connected device is full. The magic is

mode com1: 2400,n,8,1,p

Now it works like a charm. Hopefully not only on my test machine...

Thank again for your time, TheTuna and John, and happy holidays.

Mangro