in reply to Serial port losing data
I've done tons of hardware interfacing. While it's a great idea to check your code, you may be trying to feed data to the cash register faster than it's able to consume it. Here are a couple of things you might try:
1) Check the manual for the cash register and make sure that your cable is correct. Many serial devices use hardware handshaking signals to regulate the data flow to a rate they can handle. If it uses hardware handshaking and you're using a serial cable wired to fool itself, you'll get the symptoms you describe.
I've seen this happen in lots of microcontroller-based hardware for example: many don't have a UART in them and they emulate the UART by bit-banging. When the microcontroller is busy doing something else (such as ejecting cash drawer, talking with LCD display, or some such) it can't be monitoring the serial channel. So they may use the CTS or DTR line to put a hold on incoming data.
2) Another thing I've encountered is that some devices don't use hardware handshaking, but they're not quite fast enough to handle a serial port going full-bore. You might try small delays after carriage returns to give the controller a chance to process the line before sending the next line.
One final note: Delays should be your last resort. Too often, people put them in, and it works most of the time. Then you add more delays, and it's a bag of rats. If the device uses hardware handshaking, you'll save yourself some grief by cabling it correctly rather than using arbitrary delays.
...roboticus
|
|---|