CODEWITHSUNDEEP
javapythonprintingpython-3.6escpos
Hmerman6006
Hmerman6006

Reputation: 1913

ESC/POS Printer status only returning unexpected two unsigned integers

I have a kivy App that prints barcodes using ESC/POS command language. The thing that I noticed is that if I don't get the printer status the App will send commands blindly without caring if the printer's out of paper or battery is flat ect. So I use the GS 0x99 command as prescribed by the manufacturer to read the printer status, but I am not sure if I understand the result correctly. According to the manual it should return 1 D 99 XX FF of which the first five digits represent
Bit 0 with value 0 or 1 for paper status;
Bit 1 with value 0 or 1 for cover closed or not;
Bit 2 with value 0 or 1 for printer temprature;
Bit 3 with value 0 or 1 for battery status; and
Bit 4 with value 0 or 1 for print status.
I read the the InputStream into a python Array with Unsigned Integer typecode that always return two decimals [153, 255].

If I use python's hex method the values would hexadecimally be [0x99, 0xff], but how do I interpret each bit or digit as a 0 or 1 value from the hexadecimal value?
If I turn the returned integers into binary I get f'{255:b}' returns '11111111' and f'{153:b}' returns '10011001' which does not say much as I opened the lid and sent the printer status command which gave me exactly the same result.

Edit:
So I had thought that maybe I was using the wrong java method to read the InputStream, as I am using InputStreamReader with BufferedReader which maybe will return the wrong result. I tried using only getInputStream and got exactly the same result as above

Edit 2:
I changed the encoding from latin-1 to utf-8 and received a completely different result, which is the integer 65533; hex(65533) is 0xfffd

Printer details:
Manufacturer: Urovo
Model: K319
PN: 48389221
Link to command

Can someone please point me in the right direction to interpret the results of the read? Should I use bitwise operators to assess each bit?

Upvotes: 0

Views: 1766

Answers (1)

kunif
kunif

Reputation: 4350

For example, there are the following possibilities.

  • It is not a mode setting for notification by hardware.
  • Since InputStream is used, the actual notification data is buried.

The notified data is binary data in bytes.
You need to treat it as a sequence of byte data.
If encoding is set assuming some characters, unintended conversion and error notification may occur.

According to the document, the status notification is the following 4 bytes of data, and the third byte is valid data. 

0x1D, 0x99, 0xXX, 0xFF

For example, if [0x99, 0xff] you thought you received first, the first 0x1D and the byte information in the status data are lost.

And if 0xfffd obtained in the second is the last 2 bytes, the status seems to be 0xfd, and it is as follows when judged in bit units, and it is difficult to think of it as an actual status value.

1 : Out of paper
0 : Cover (closed)
1 : Printer core overheating
1 : battery is low
1 : Print status (Probably during printing)
111 : =7  '/'  (Probably undefined or unsupported paper bin number)

Therefore, it seems that the data was changed by converting from latin-1 to utf-8.
There is such an article.
Unicode Character 'REPLACEMENT CHARACTER' (U+FFFD)

Input data is handled as binary data in bytes, not characters.
The status data will need to be processed bit by bit, as in your last sentence.

Upvotes: 1

Related Questions