I'm trying to build a microprinter using an Arduino and an Epson TM-T88II receipt/POS printer. The printer uses the Epson Esc/POS system, but I can't get it to do anything at all from the Arduino. I'm doing things like:
#include <SoftwareSerial.h>
#define out_pin 3
#define in_pin 2
SoftwareSerial printer = SoftwareSerial(in_pin, out_pin);
void setup()
{
pinMode(in_pin, INPUT);
pinMode(out_pin, OUTPUT);
printer.begin(9600);
delay(1000);
printer.print(0x1B, BYTE);
printer.print('#'); // ESC(HEX 1B) # is supposed to initialize the printer
printer.print("hello world");
printer.print(0xA, BYTE); // print buffer and line feed
}
I just can't get the printer to respond at all. The printer powers up and prints its self test just fine. It's a serial (RS-232) printer, and I'm connecting it to the Arduino through a MAX233 chip. I've checked and rechecked my connections through the chip, which I think are right based on a friend who has a similar setup working. I read somewhere that the TM-T88 printers need null-modem serial cables, so I bought an adapter, and that didn't seem to make any difference.
I'm new to electronics, so I'm completely stumped. I just want to get it to print something, so I can get to the fun part - the programming :). Any thoughts on things to test/try? I can give more detail on wiring or anything else, just didn't want this to get TOO long.
Are you using an RS-232 transceiver? The Arduino outputs 0 and 5 V for serial, while the printer uses -12 and 12 V for serial. You should use a MAX232 or similar device to get the correct physical interface. (You might be able to cheat if you invert the serial port on the Arduino, but that might not work, and it's more trouble when just getting started.)
Once that's taken care of, the RTS and DTR may be your problem. You should be able to change the DIP-switch settings on the printer and turn off flow control altogether, or switch it to software flow control.
Also, you may need to send both line feed and carriage return.
However, once all that's done it should print just fine, even without any reset commands. Send a bunch of ASCII characters and line feed/carriage returns, and it'll spit it all out.
You can ignore the RX line (on the Arduino side, TX on the printer side) for now - just send it data until you figure out the wiring, level conversion, flow control, etc.
You could check whether you can communicate with a PC, both from the Arduino and to the printer.
I would use an oscilloscope to see if the serial signals come out of the Arduino and the MAX as they should, but then you probably don't have one.
Are you sure the communication settings are correct? You set the baud rate to 9600, but what about data bits, parity, stop bits? What about the control lines?
I'd hook another PC instead of the printer to the other end of the serial cable and run telnet or PuTTY on that system to make sure you are communicating out and actually talking through the serial port. If so, you could use the same solution to send data to the printer to confirm all settings such as number of data bits, parity, etc.
I've done a similar project and had the same issue. You need a null modem / crossover cable to go from max232 to the printer as both devices are in slave configuration
Related
I am making an internet cafe software that is coin-operated. I want my program to detect 5 volt signal coming from a coin detector in every insertion of coin. However, I've been searching in google trying to find sample codes to do this but to no avail. Pinchange event doesn't do the trick since the wire that carries the signal is always connected to a serial port pin and pinchange event is always happening even without inserting a coin in the coin slot. I want to detect only the 5 volt signal that the coin detector sends to serial port in every insertion of coin. Please help me on this.
Thank you and best regards.
I have several projects with similarities to this one. I would recommend using the .NET libraries for reading serial ports. In VB.NET it is something like:
Dim com1 As IO.Ports.SerialPort = Nothing
com1 = My.Computer.Ports.OpenSerialPort("COM1")
Dim serialInput As String = com1.ReadLine()
The problem is the 5v signal. This is super easy to read with an Arduino or Raspberry Pi (the Raspberry Pi might be a better solution for you...RPi Foundation just came out with a new quad-core version...and it only runs like $40 and would have no problem surfing the web) to do the signal sensing.
You can get Arduino compatibles for less than $10 like this one http://www.adafruit.com/product/2000 and then program them to send whatever string you want to the serial port.
Good luck with your project.
I'm using PIC18F87J11 as the master and LiPower Shield as the slave, and all I want to do is to be able to read the battery voltage value from the LiPower Shield. I'm using MPLAB C18 libraries for the I2C communication. I'm not able to get correct readings as I think the communication between the two devices is not setup correctly.
I'm looking for interpretations of the waveform signals in order to detect the issue. Also I would like to know if I'm missing something in the code. Any recommendations to improve the code would be helpful.
The LiPower Shield came with a sample code for Arduino but I'm using PIC18 chip from Microchip. The sample code is found here.
Here is the signals I'm getting while trying to read the battery voltage.
Code:
SSP2ADD = 19;
OpenI2C2(MASTER,SLEW_OFF);
StartI2C2();
IdleI2C2();
WriteI2C2(0x36);
IdleI2C2();
data = ReadI2C2(); // Read byte of data
printf ("\r\nAddress 32");
printf (" Byte:");
PrintChar(data);
IdleI2C2();
AckI2C2();
IdleI2C2();
WriteI2C2(0x02);
IdleI2C2();
data = ReadI2C2(); // Read byte of data
printf ("\r\nAddress 02");
printf (" Byte:");
PrintChar(data);
IdleI2C2();
AckI2C2();
StopI2C2(); // Stop condition I2C on bus
Output: Which I think is wrong.
Address 32 Byte:FF
Address 02 Byte:FF
I'm not really sure if I'm writing/reading from the correct address, but that's the address they used in the their sample code. I hope I can get some interpretations on the signals and feedback on the code if possible.
I'm not familiar with the PIC but your code looks nowhere near right. Per the MAX17043DS datasheet, page 12, a memory read must consist of the following:
I2C start condition
Write device I2C write address (0x6C)
Check for ACK from slave
Write 8-bit memory address
Check for ACK from slave
I2C repeated start condition
Write device I2C read address (0x6D)
Read first byte of data
Send ACK
Read second byte of data
Send NACK
I2C Stop condition
What I see in your code is an I2C Start condition followed by a write 0f 0x36. Since this is not the device address the slave recognizes, it sends a NACK (as seen on your logic analyzer traces) and ignores everything else.
This question and answer has a lot of information on I2C on a PIC18. You also should probably find a read a basic I2C tutorial.
I'm running some code on Arduino, I have website with a slider which uses a cgi script to pass values to Python. Then the python script uses pySerial to send the values to Arduino which controls a motor.
The plan was to be able to control the motor speed using the slider on the website.
However I seem to be coming up against a problem of the Arduino resetting whenever I change a value on the website, causing the motor to stop. Is there any way around this? My python code is below.
#!/usr/bin/env python
import cgi
form=cgi.FieldStorage()
import json
ser = serial.Serial('dev/ttyACM0', 9600)
#I think there should be a sleep here for 1.5 seconds
ser.write("%s\n" % (form["value"]))
ser.close()
print "Content-type: application/json"
print
print(json.JSONEncoder().encode({"status":"ok"}))
So, say I have the motor running at 50% speed, then change a value on the website, it runs this script which executes the serial.Serial('dev/ttyACM0', 9600) command. That opens the port which resets the arduino, stopping the motor before passing the new command.
Is there any way to pass ser.write("%s\n" % (form["value"])) to the arduino without freshly opening the port? Such as leaving the port open between python sessions?
If not, is there any other way around this problem?
I believe the reset is due to a hardware design of the specific Arduino device you are using. I suggest using an Arduino Micro or Leonardo board instead. They use a virtual serial port and should not restart your sketch each time a serial port is opened. This is from the Arduino site:
No reset when you open the serial port.
Unlike the Arduino Uno, the Leonardo and Micro won't restart your
sketch when you open a serial port on the computer. That means you
won't see serial data that's already been sent to the computer by the
board, including, for example, most data sent in the setup() function.
Serial re-enumeration on reset.
Since the boards do not have a dedicated chip to handle serial
communication, it means that the serial port is virtual -- it's a
software routine, both on your operating system, and on the board
itself. Just as your computer creates an instance of the serial port
driver when you plug in any Arduino, the Leonardo/Micro creates a
serial instance whenever it runs its bootloader. The board is an
instance of USB's Connected Device Class (CDC) driver. This means that
every time you reset the board, the USB serial connection will be
broken and re-established. The board will disappear from the list of
serial ports, and the list will re-enumerate. Any program that has an
open serial connection to the Leonardo will lose its connection. This
is in contrast to the Arduino Uno, with which you can reset the main
processor (the ATmega328P) without closing the USB connection (which
is maintained by the secondary ATmega8U2 or ATmega16U2 processor).
This difference has implications for driver installation, uploading,
and communication...
I you might be able to use the setDTR(False), but I have tested this yet. A while back they fixed the bug that were initially associated with setDTR. What operating system are you use this on?
ser = serial.Serial('dev/ttyACM0', 9600)
ser.timeout = 1
ser.setDTR(False)
Let us know if this does not work.
I have to interface the thermal Printer with my AM1808 based on the Embedded linux.
I have interfaced a printer having only unidirectional communication, means i need to send only data and no need to receive anything from the printer for verification.
I have my own printer that need the bidirectional communication in which i have to send the data and same way i need to receive something from the printer to verify wether it has successfully printed the data or not.
Yes my printer gets hung when it has printed around 4000 bytes so i have to reinitialize it to empty its inbuild buffer.
Now my question is Once i have configured a UART port. do i have to enable or disable transmission or reception ? means it can work with both the transmission and reception enabled ? How can i do this please help me.
Wether I have to put printer on interrupt. ????
Thank you.
All UART's I've ever worked with have independent tx and rx hardware. Assuming no hardware flow-control enabled, then if you can tx OK, your should be able to rx.
Wether I have to put printer on interrupt? - Well, on a preemptive multitasker, it's usual to use an interrupt driver, (or some variant, eg. DMA with interrupt on completion), yes.
I have interfaced a printer having only unidirectional communication, means i need to send only data and no need to receive anything from the printer for verification.
"... no need to receive anything ..." is probably a faulty assumption.
Your printer should have somekind of flow control to prevent data overrun. Character displays & line printers often can receive the data faster than they can display or print it. These devices use a simple comm protocol that does not have any facility for retransmission of lost data. So there's flow control to notify the host to (temporarily) stop sending data when the device's receive buffer is full.
A EIA/RS-232 serial interface can use either hardware (typically using the CTS control line) or software (embedded data, typically using the XON and XOF characters) for single-ended flow control. Linux serial port drivers and line discipline make flow control invisible to the application program once the serial port is configured.
Yes my printer gets hung when it has printed around 4000 bytes so i have to reinitialize it to empty its inbuild buffer.
This appears to be evidence that you are ignoring whatever flow control the printer is providing, and causing data overrun.
Now my question is Once i have configured a UART port. do i have to enable or disable transmission or reception ?
That's not the salient question. You need to determine what kind of flow control the printer needs, and then implement (i.e. configure) that.
So, to open up a serial port and successfully transmit data from the balance through the serial port, i need to make sure that the settings on the serialPort object match the actual settings of the balance.
Now, the question is how do i detect that the connection hasn't been established due to the settings being different? No exception is thrown by serialPort.Open to indicate that the connection has been established. Yes, the settings are valid, but if they don't match the device (balance) settings; I am in the dark as to why the weight off the balance is not being captured.
Any input here?
Without knowing any more information on the format of the data you expect from your balance, only general serial port settings mismatch detection techniques are applicable.
If the UART settings are significantly incorrect, you'll likely see a lot of framing errors: when the UART is expecting a 1 stop bit, it will in fact see a 0. You can detect this with the ErrorReceived event on the port.
private void OnErrorReceived(object sender, SerialErrorReceivedEventArgs e)
{
if ((e.EventType & SerialError.Frame) == SerialError.Frame)
{
// your settings don't match, try something else
}
}
If things are close, but still incorrect, the .NET serial port object may not even give you an error (that is, until something catastrophic occurs).
My most common serial port communication failure occurs due to mismatched baud rates. If you have a message that you know you can get an 'echo' for, try that as part of a handshaking effort. Perhaps the device you're connecting to has a 'status' message. No harm will come from requesting it, and you will find out if communication is flowing correctly.
For software handshaking (xon xoff) There's very little you can do to detect whether or not it's configured right. The serial port object can do anything from ignore it completely to have thread exception errors, depending on the underlying serial port driver implementation. I've had serial port drivers that completely ignore xon/xoff, and pass the characters straight into the program - yikes!
For hardware handshaking, the basic echo strategy for baud rate may work, depending on how your device works. If you know that it will do hardware handshaking, you may be able to detect it and turn it on. If the device requires hardware handshaking and it's not on, you may get nothing, and vice versa.
Another setting that's more rarely used is the DTR pin - data terminal ready. Some serial devices require that this be asserted (ie, set to true) to indicate that it's time to start sending data. It's set to false by default; give toggling it a whirl.
Note that the serial port object is ... finicky. While not necessarily required, I would consider closing the port before you make any changes.
Edit:
Thanks to your comments, it looks like this is your device. It says the default settings should be:
1200 baud
Odd parity
1 stop bit
Hardware handshaking
It doesn't specify how many data bits, but the device says it supports 7 and 8. I'd try both of those. It also says it supports 600, 1200, 2400, 4800, 9600, and 19200 baud.
If you've turned on hardware handshaking, enabled DTR (different things) and cycled through all the different baud rates, there's a good chance that it's not your settings. It could be that the serial cable that's being used may be wired incorrectly for your device. Some serial cables are 'passthrough' cables, where the 1-9 pins on one side match exactly with the 1-9 pins on the other. Then, you have 'crossover' cables, where the "TX" and "RX" cables are switched (so that when one side transmits, the other side receives, a very handy cable.)
Consider looking at the command table in the back of the manual there; there's a "print software version" command you could issue to get some type of echo back.
Serial ports use a very, very old communications technology that use a very, very old protocol called RS-232. This is pretty much as simple as it gets... the two end points have synchronized clocks and they test the line voltage every clock cycle to see if it is high or low (with high meaning 0 and low meaing 1, which is the opposite of most conventions... again an artifact of the protocol's age). The clock synchronization is accomplished through the use of stop bits, which are really just rest time in between bytes. There are also a few other things thrown into the more advanced uses of the protocol such as parity bits, XON/XOFF, etc, but those all ride on top of this very basic communication layer. Detecting a mismatch of the clocks on each end of the serial line is going to be nearly impossible -- you'll just get incorrect data on the recieving end. The protocol itself has no way built in to identify this situation. I am unaware of any serial driver that is smart enough to notice the input data being clocked an an inappropriate frequency. If you're using one of the error detection schemes such as parity bits, probabilistically every byte will be declared an error. In short, the best you can do is check the incoming data for errors (parity errors should be detected by your driver/software layer, whereas errors in the data received by your app from that layer will need to be checked by your program -- the latter can be assisted by the use of checksums).