I am new to the world of ESC/POS. I have an Epson TM-T20II printer USB connected to a Windows 7 desktop. The code below is a sample application obtained from Epson at this link: https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=269
For my test, I have pasted the code in Notepad and print its content to the Epson printer. The printer prints the code below "as is". What do I need to do in order to get the printer to interpret the ESC/POS commands?
ESC "#"
ESC "3" 18
ESC "a" 1
GS "!" 0x11
0xC9 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xBB LF
0xBA 0x20 0x20 0x20 0x45 0x50 0x53 0x4F 0x4E 0x20 0x20 0x20 0xBA LF
0xBA 0x20 0x20 0x20
GS "!" 0x00
"Thank you "
GS "!" 0x11
0x20 0x20 0x20 0xBA LF
0xC8 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xCD 0xBC LF
ESC "2"
GS "!" 0x00
ESC "J" 4
"NOVEMBER 1, 2012 10:30"
ESC "d" 3
ESC "a" 0
"TM-Uxxx 6.75" LF
"TM-Hxxx 6.00" LF
"PS-xxx 1.70" LF LF
GS "!" 0x01
"TOTAL 14.45" LF
GS "!" 0x00
"---------------------------------------" LF
"PAID 50.00" LF
"CHANGE 35.55" LF
ESC "p" 0 2 20
GS "V" 66 0
First of all make sure that you are sending the escape character, not the letters ESC. The escape character looks like this ← (type alt+27).
Second (on PC) you need to send the file directly to the printer. One way to accomplish this is to use this tool called RawPrint. Good Luck!
It seems that you just send the text with a printer driver to your printer. That is because your printer driver does not interpret the text that you enter but renders it for printing. You would instead have to send the raw byte sequences directly to your printer.
I don't know if there is a way to achieve this using only the Windows printer interface. Maybe there is something like a "raw"-driver. You could however use an ESC/POS-library. For php there is escpos-php and for Python there is python-escpos. There exist probably also libraries for other languages.
They supply you for example with abstraction of the ESC/POS command-set.
This is an example for usage of python-escpos:
from escpos.printer import Usb
# the parameters of the next call depend on the
# Vendor ID and Product ID of your USB-printer
p = Usb(0x04b8,0x0202,0)
p.text("Hello World\n")
p.image("logo.gif")
p.barcode('1324354657687','EAN13',64,2,'','')
p.cut()
It connects to the printer, prints the text "Hello World" with a newline at the end. It then proceeds with printing an image (which has to be available of course) and a barcode and finally cuts the paper.
Moreover you could use p.raw(b'\x1b'+'#') to send the ESC/POS sequence "ESC #" to the printer. With this you could directly send your example to your printer.
Related
#!/usr/bin/expect -f
set prompt "#"
set address 34:85:18:6a:52:52
spawn bluetoothctl
expect -re $prompt
send "connect $address\r"
expect "Connection successful"
sleep 2
send "list-attributes\r"
sleep 2
send "menu gatt\r"
sleep 2
send "select-attribute
/org/bluez/hci0/dev_34_85_18_6A_52_52/service002e/char002f\r"
sleep 2
send "list-attributes\r"
sleep 2
send "write 0xa5 0x00 0x00 0x08 0x00 0x53 0x6f 0x0e 0x00 0x03 0x10 0x01 0x02 0x12 0x01 0x0a 0xff 0x01 0x20 0x9a\r"
send "quit\r"
expect eof
i need to be able to have " " quotations around th value being sent or else bluetoothctl write will not accept the value
it works in terminal as
write "0xa5 0x00 0x00 0x08 0x00 0x53 0x6f 0x0e 0x00 0x03 0x10 0x01 0x02 0x12 0x01 0x0a 0xff 0x01 0x20 0x9a"
but script will not allow me to input quotations around value without throwing an error...
ive tred breaking write and value apart and using a \ between them, i really dont have a good grasp of scripting to know how to make it work.
maybe a variable with intended code inside but again i dont have the knowledge to get this completed solo
The first line #!/usr/bin/expect -f shows that this is an Expect script, not a shell script. Expect is based on Tcl, so the Tcl rules for quoting apply. These can be found at http://www.tcl-lang.org/man/tcl8.6/TclCmd/Tcl.htm .
The first part of #akathimi's answer is still applicable - backslashes can be used to insert double-quotes in a double-quoted string. However the second part does not apply - single-quotes have no significance in Tcl syntax. However the same effect can be achieved by enclosing the whole string in braces {} like this, e.g. puts {test test is "test"} but note that this will also disable the substitution of a carriage-return character for the sequence \r.
in bash in general, use \" to echo the ".
e.g.:
$echo "test test is test"
test test is test
$echo "test test is \"test\""
test test is "test"
You can also use single quotes ', e.g.:
echo 'test test is "test"'
test test is "test"
I would like to disassamble / debug an elf file. Is it somehow possible to track the function where a specific string in the elf file is called?
So I mean, I have a string where I know it is used to search for that string in a file. Is it somehow possible with e.g. gdb to debug exactly that position in the executable?
Or is the position of the string in the elf file, somehow visible in the objdump -d output?
In order to do that you need a disassembler - objdump just dumps the info - it might not give you enough information as some analysis is needed before you can tell where it is being used. What you need is to get the XREFs for the string you have in mind.
If you open your binary in the disassembler it will probably have the ability to show you strings that are present in the binary with the ability to jump to the place where the string is being used (it might be multiple places).
I'll showcase this using radare2.
Open the binary (I'll use ls here)
r2 -A /bin/ls
and then
iz
to display all the strings. There's a lot of them so here's an extract
000 0x00004af1 0x100004af1 7 8 (4.__TEXT.__cstring) ascii COLUMNS
001 0x00004af9 0x100004af9 39 40 (4.__TEXT.__cstring) ascii 1#ABCFGHLOPRSTUWabcdefghiklmnopqrstuvwx
002 0x00004b21 0x100004b21 6 7 (4.__TEXT.__cstring) ascii bin/ls
003 0x00004b28 0x100004b28 8 9 (4.__TEXT.__cstring) ascii Unix2003
004 0x00004b31 0x100004b31 8 9 (4.__TEXT.__cstring) ascii CLICOLOR
005 0x00004b3a 0x100004b3a 14 15 (4.__TEXT.__cstring) ascii CLICOLOR_FORCE
006 0x00004b49 0x100004b49 4 5 (4.__TEXT.__cstring) ascii TERM
007 0x00004b60 0x100004b60 8 9 (4.__TEXT.__cstring) ascii LSCOLORS
008 0x00004b69 0x100004b69 8 9 (4.__TEXT.__cstring) ascii fts_open
009 0x00004b72 0x100004b72 28 29 (4.__TEXT.__cstring) ascii %s: directory causes a cycle
let's see where this last one is being used. If we move to the location where it's defined 0x100004b72. We can see this:
;-- str.s:_directory_causes_a_cycle:
; DATA XREF from 0x100001cbe (sub.fts_open_INODE64_b44 + 378)
And here we see where it's being referenced -> DATA XREF. We can move there (s 0x100001cbe) and there we see how it's being used.
⁝ 0x100001cbe 488d3dad2e00. lea rdi, str.s:_directory_causes_a_cycle ; 0x100004b72 ; "%s: directory causes a cycle"
⁝ 0x100001cc5 4c89ee mov rsi, r13
⁝ 0x100001cc8 e817290000 call sym.imp.warnx ;[1]
Having the location you can put a breakpoint there (r2 is also a debugger) or use it in gdb.
I have two boards with a STM32F437 (IGH6 7BA4S VQ PHL 7B 542) processor. We program these with openocd and a jtag, however lately one card stopped working. It is no longer possible to program the card and one of the differences we have found is that the user option bytes differ between the cards.
0x0EC On the working card
0xCFC On the broken
What I tried to do is using the options_write command. Note that the STM32F4 apparently goes under the "stm32f2x" command.
openocd -f openocd.cfg -c "reset halt; stm32f2x unlock 0; reset halt; stm32f2x options_write 0 0x0EC"
This resulted in the error message: "Error: stm32x device protected"
In the STM32F437 Reference manual RM0090 under "3.7.2 Programming user option bytes" it says:
To run any operation on this sector, the option lock bit (OPTLOCK) in the Flash option
control register (FLASH_OPTCR) must be cleared. To be allowed to clear this bit, you have
to perform the following sequence: \n
Write OPTKEY1 = 0x0819 2A3B in the Flash option key register (FLASH_OPTKEYR)
Write OPTKEY2 = 0x4C5D 6E7F in the Flash option key register (FLASH_OPTKEYR)
The user option bytes can be protected against unwanted erase/program operations by
setting the OPTLOCK bit by software.
To do that I tried the following in a telnet session:
mww 0x08 0x08192A3B
mww 0x08 0x04C5D6E7F
mdw 0x0C
mww 0x18 0x0EC
mww 0x14 0x0EC
The 0x08 on line 1 is FLASH_OPTKEYR, 0x0C on line 3 is FLASH_SR to check if BSY bit is not set, 0x14 on line 4 is FLASH_OPTCR1, and 0x14 on line 5 is FLASH_OPTCR.
Then a reboot and trying to program the application
openocd -f openocd.cfg -c "program HCF-220_07_010_PA2.hex reset exit"
This results in the error:
Error: stm32x device protected.
I also tried to do the following command to unlock before programming:
openocd -f openocd.cfg -c "openocd -f openocd.cfg -c "reset halt; stm32f2x unlock 0; program HCF-220_07_010_PA2.hex reset exit"
Same result:
Error: stm32x device protected.
Update
I tried the following in telnet without luck, the user option is still 0xCFC:
mww 0x40023C08 0x08192A3B
mww 0x40023C08 0x04C5D6E7F
mdw 0x40023c0c
mww 0x40023C18 0x0EC
mww 0x40023C14 0x0EC
mww 0x40023C08 0x02
Power Cycle
In RM0090 chapter 3.7.2 it also says: 4. Set the option start bit (OPTSTRT) in the FLASH_OPTCR register
Hence the nr 6. above.
The working solution for me was as follows:
stm32f2x lock 0 Yes lock not unlock.
Do a power cycle
reset init
mww 0x40023C08 0x08192A3B
mww 0x40023C08 0x04C5D6E7F
mdw 0x40023c0c Wait for flash write to finish, make sure we receive 00000000
mww 0x40023C18 0x0FFF0000
mww 0x40023C14 0x0FFFAAEC Write user_options to same as a working
mww 0x40023C14 0x0FFFAAEE Set option start bit, step "4." in rm0090.
mdw 0x40023c0c Wait for flash erase to finish, make sure we receive 00000. This takes about 10 seconds.
Do a power cycle
The reason why it did not work with OpenOCD command "options_write", can be found in the manual for OpenOCD. The "user_options" argument takes the bits 31-28 and 7-0 from FLASH_OPTCR.
Flash register base address is 0x40023C00 (as per RM0090). 0x08 is offset from base, so you should write to 0x40023C08
Sure, to send EOF from command prompt, Enter followed by Ctrl-Z does the trick.
C:\> type con > file.txt
line1
line2
^Z
This works, and file.txt contains line1\r\nline2\r\n. But how can you do the same without the last newline, so that file.txt contains line1\r\nline2?
In Linux, the solution is to hit Ctrl-D twice1. But what is the equivalent on Windows? Command prompt will happily print ^Zs at the end of a line without doing sending EOF. (And if you press Enter, then any ^Zs you typed get written to the file as literal escape characters!)
If there is no way to do this on Windows, then why?
1 https://askubuntu.com/questions/118548/how-do-i-end-standard-input-without-a-newline-character
The command type con > file.txt doesn't have any special handling for ^Z in the cmd shell, since the target file isn't con and the type command wasn't run in Unicode (UTF-16LE) output mode. In this case, the only ^Z handling is in the ReadFile call itself, which for a console input buffer has an undocumented behavior to return 0 bytes read if a line starts with ^Z.
Let's examine this with a debugger attached, noting that the number of bytes read (lpNumberOfBytesRead) is the 4th argument (register r9 in x64), which is returned by reference as an output parameter.
C:\Temp>type con > file.txt
Breakpoint 1 hit
KERNELBASE!ReadFile:
00007ffc`fb573cc0 48895c2410 mov qword ptr [rsp+10h],rbx
ss:00000068`c5d1dfa8=000001e3000001e7
0:000> r r9
r9=00000068c5d1dfd0
0:000> pt
line1
KERNELBASE!ReadFile+0xa9:
00007ffc`fb573d69 c3 ret
0:000> dd 68c5d1dfd0 l1
00000068`c5d1dfd0 00000007
As you see above, reading "line1\r\n" is 7 characters, as expected. Next let's enter "\x1aline2\r\n" and see how many bytes ReadFile reportedly reads:
0:000> g
Breakpoint 1 hit
KERNELBASE!ReadFile:
00007ffc`fb573cc0 48895c2410 mov qword ptr [rsp+10h],rbx
ss:00000068`c5d1dfa8=0000000000000000
0:000> r r9
r9=00000068c5d1dfd0
0:000> pt
^Zline2
KERNELBASE!ReadFile+0xa9:
00007ffc`fb573d69 c3 ret
0:000> dd 68c5d1dfd0 l1
00000068`c5d1dfd0 00000000
As you see above, this time it reads 0 bytes, i.e. EOF. Everything typed after ^Z was simply ignored.
However, what you want instead is to get this behavior in general, wherever ^Z appears in the input buffer. type will do this for you, but only if it's executed in Unicode mode, i.e. cmd /u /c type con > file.txt. In this case cmd does have special handling to scan the input for ^Z. But I bet you don't want a UTF-16LE file, especially since cmd doesn't write a BOM to allow editors to detect the UTF encoding.
You're in luck, because it happens that copy con file.txt does exactly what you want. Internally it calls cmd!ZScanA to scan each line for a ^Z character. We can see this in action back in the debugger, but this time we're in completely undocumented territory. On inspection, it appears that this function's 3rd parameter (register r8 in x64) is the number of bytes read as an in-out argument.
Let's begin again by entering the 7 character string "line1\r\n":
C:\Temp>copy con file.txt
line1
Breakpoint 0 hit
cmd!ZScanA:
00007ff7`cf4c26d0 48895c2408 mov qword ptr [rsp+8],rbx
ss:00000068`c5d1e9d0=0000000000000000
0:000> r r8; dd #r8 l1
r8=00000068c5d1ea64
00000068`c5d1ea64 00000007
On output, the scanned length remains 7 characters:
0:000> pt
cmd!ZScanA+0x4f:
00007ff7`cf4c271f c3 ret
0:000> dd 68c5d1ea64 l1
00000068`c5d1ea64 00000007
0:000> g
Next enter the 23 (0x17) character string "line2\x1a Ignore this...\r\n":
line2^Z Ignore this...
Breakpoint 0 hit
cmd!ZScanA:
00007ff7`cf4c26d0 48895c2408 mov qword ptr [rsp+8],rbx
ss:00000068`c5d1e9d0=0000000000000000
0:000> r r8; dd #r8 l1
r8=00000068c5d1ea64
00000068`c5d1ea64 00000017
This time the scanned length is only the 5 characters that precede the ^Z:
0:000> pt
cmd!ZScanA+0x4f:
00007ff7`cf4c271f c3 ret
0:000> dd 68c5d1ea64 l1
00000068`c5d1ea64 00000005
We expect file.txt to be 12 bytes, which it is:
C:\Temp>for %a in (file.txt) do #echo %~za
12
More generally, if a Windows console program wants to implement Ctrl+D handling that approximates the behavior of a Unix terminal, it can use the wide-character console function ReadConsoleW, passing a CONSOLE_READCONSOLE_CONTROL struct by reference as pInputControl. This struct's dwCtrlWakeupMask field is a bit mask that sets which control characters will immediately terminate the read. For example, bit 4 enables Ctrl+D. I wrote a simple test program that demonstrates this case:
C:\Temp>.\test
Enter some text: line1
You entered: line1\x04
You can't see this in the above example, but this read was immediately terminated by pressing Ctrl+D, without even pressing enter. The ^D control character (i.e. '\x04') remains in the input buffer, which is useful in case you want different behavior for multiple control characters.
Note that, while there is a lot on this issue already, it invariably covers either using this from powershell (where braces and dashes can be an issue) or a typo in the docs where ipport is followed by a colon.
I am in cmd
C:> netsh http add sslcert ipport=0.0.0.0:8180 appid={12345678-db90-4b66-8b01-88f7af2e36bf} certhash=1234567890
The parameter is incorrect.
In actual usagge I'm using the correct certhash I got from my certificate store - not the obviously fake one above
So what is going on? Is there a way to get more info?
Explained in my comment:
I'm using the correct certhash… Supposedly "The SHA hash of the certificate. This hash is 20 bytes long and specified as a hex
string" instead of fake 1234567890?
However, there is a harmful format symbol Left-To-Right Mark (Unicode
U+200E) after Equals Sign in your certhash=1234567890
Screenshot taken from Unicode Analyzer:
Another way to detect invisible characters using my Alt KeyCode Finder script:
==> mycharmap h=1
Ch Unicode Alt? CP IME Alt Alt0 IME 0405/cs-CZ; CP852; ANSI 1250
h U+0068 104 …104… 104 0104 Latin Small Letter H
= U+003D 61 …61… 61 061 Equals Sign
U+200E 8206 …14… Left-To-Right Mark
CP862 he-IL 0253 (ANSI 1255) Hebrew
CP720 ar-EG 0253 (ANSI 1256) Arabic
1 U+0031 49 …49… 49 049 Digit One
h=1
==> chcp
Active code page: 852