Software Development
Epson TM-T82: Driver Windows vs ESC/POS Mentah
Agustus 202611 menit baca
Driver merender dokumen Anda menjadi bitmap selebar kertas lalu mengalirkannya sebagai titik, yang berkali-kali lipat lebih besar datanya dan jauh lebih lambat. ESC/POS mentah mengirim byte perintah persis yang dieksekusi printer, biasanya satu sampai tiga kilobyte untuk satu struk penuh, dan hanya jalur inilah yang juga bisa memotong kertas serta memberi pulsa ke laci uang.
Bisa, dan biasanya itu langkah pertama terbaik. Mengirim pekerjaan dengan datatype RAW memberi tahu spooler agar meneruskan byte Anda apa adanya tanpa merender apa pun, sehingga manajemen antrean, sharing, dan izin tetap ada sementara biaya rasterisasi hilang. Di Linux padanannya adalah opsi raw pada lp.
OPOS atau POS for .NET masuk akal di lingkungan khusus Windows yang harus mendukung banyak merek printer di balik satu antarmuka perangkat standar. ePOS SDK dan ePOS-Print masuk akal ketika aplikasi browser atau mobile harus mencetak ke printer TM berjaringan tanpa memasang apa pun secara lokal. Keduanya menukar keleluasaan dengan dependensi yang lebih berat.
Ukur jumlah byte satu pekerjaan cetak. Struk ESC/POS berbasis teks berukuran sekitar satu sampai tiga kilobyte; struk yang sama dalam bentuk bitmap berukuran puluhan hingga ratusan kilobyte. Kalau struk Anda butuh beberapa detik dan menghasilkan pekerjaan berukuran besar, berarti driver sedang menggambarnya sebagai citra.
Hasilkan byte ESC/POS berdampingan dengan jalur driver yang ada, buang keduanya ke berkas, bandingkan hasil cetaknya di atas kertas, lalu pindahkan satu toko pada satu waktu di balik feature flag. Tidak ada yang berubah pada alur transaksi, dan hasil yang buruk bisa dibatalkan untuk toko itu saja tanpa menyentuh toko lain.
Ringkasan Utama
Driver Windows merender struk menjadi bitmap dan menyembunyikan printer di balik spooler; ESC/POS mentah mengirim byte persis yang dieksekusi printer. Driver unggul untuk laporan kantor dan antrean bersama, byte mentah unggul untuk kecepatan kasir, kendali laci uang, dan kegagalan yang bisa diprediksi.
Ada empat cara sah untuk mengeluarkan teks dari Epson TM-T82, dan tim biasanya memilih salah satunya secara kebetulan — mana pun yang muncul lebih dulu di hasil pencarian — lalu menanggung akibatnya bertahun-tahun. Akibatnya nyata: selisih beberapa detik per transaksi, apakah laci uang bisa terbuka sama sekali, dan apakah kegagalan cetak bisa dilihat oleh kode Anda.
Ini perbandingan yang saya harap saya punya sejak awal, disusul kode untuk dua jalur yang paling penting dalam praktik.
Semua opsi di bawah berakhir dengan byte ESC/POS yang sama sampai ke kepala cetak. Yang berbeda adalah siapa yang menghasilkannya, berapa lapisan di antaranya, dan seberapa banyak perilaku printer yang masih bisa Anda jangkau.
| Pendekatan | Cara kerjanya | Paling cocok untuk | Harganya |
|---|---|---|---|
| Driver printer (GDI atau CUPS) | Aplikasi Anda menggambar halaman; driver meraster ke lebar kertas lalu mengalirkan titik | Cetak sesekali, dokumen kantor, dan memberi akses ke pengguna non-teknis | Paling lambat, tanpa kendali laci atau potong dari dokumen, dan ada dialog cetak yang menghalangi |
| OPOS atau POS for .NET | API perangkat terstandardisasi di atas Epson Advanced Printer Driver | Lingkungan khusus Windows yang harus mendukung banyak merek printer di balik satu antarmuka | Instalasi berat, konfigurasi per mesin, dan ketergantungan keras pada Windows |
| ePOS-Print dan ePOS SDK | XML atau panggilan SDK milik Epson yang dikirim lewat HTTP ke printer TM berjaringan | Aplikasi browser dan mobile yang harus mencetak tanpa memasang apa pun di perangkat | Butuh model berjaringan yang didukung dan mengikat Anda ke format permintaan Epson |
| ESC/POS mentah | Anda menyusun array byte dan menuliskannya ke perangkat USB, port serial, atau TCP port 9100 | POS khusus, tiket dapur, apa pun yang diukur dalam struk per menit | Anda sendiri yang mengurus matematika tata letak, code page, dan logika ulang — tidak ada framework yang melakukannya |
Ringkasan jujurnya: driver dioptimalkan untuk keumuman, byte mentah dioptimalkan untuk struk. Sistem point-of-sale bukan masalah pencetakan umum, dan itulah sebabnya hampir semua produk POS berakhir di baris terbawah tabel.
Memahami biayanya menuntut Anda tahu apa yang terjadi antara dokumen dan kertas. Driver kelas GDI memperlakukan struk sebagai citra halaman.
Tak satu pun dari itu cacat. Semuanya justru tepat untuk mencetak faktur di kertas A4. Bentuknya saja yang salah untuk perangkat yang seluruh tugasnya adalah semburan pendek teks monospace ditambah dua atau tiga perintah kendali.
Kalau struk Anda lambat dan Anda tidak bisa memastikan sedang mengirim teks atau bitmap, hampir pasti Anda mengirim bitmap. Ukur jumlah byte satu struk: struk berbasis teks berukuran satu sampai tiga kilobyte, versi rasternya puluhan hingga ratusan kilobyte.
Ada jalan tengah yang sering terlewat: Anda bisa mengirim ESC/POS mentah melalui antrean cetak sistem operasi alih-alih melewatinya. Di Windows namanya datatype RAW, di Linux cukup opsi raw pada lp. Anda tetap mendapat manajemen antrean, sharing, dan izin akses, tetapi spooler meneruskan byte Anda apa adanya tanpa merender apa pun.
# Windows: hand raw bytes to the spooler with the RAW datatype.
# The queue still owns the port, so sharing and permissions keep working.
Add-Type -AssemblyName System.Drawing
$job = [System.IO.File]::ReadAllBytes("C:\pos\receipt.bin")
# RawPrinterHelper.SendBytesToPrinter uses OpenPrinter + StartDocPrinter
# with pDatatype = "RAW", then WritePrinter. Nothing renders the page.
# Linux / CUPS: the same idea, one line.
lp -d TM-T82 -o raw receipt.bin
# No queue at all: talk to the device node.
cat receipt.bin > /dev/usb/lp0Ini biasanya migrasi pertama yang tepat. Ia menghapus biaya rasterisasi dan membuka perintah laci serta potong, tanpa meminta pengaturan IT sebuah toko berubah sedikit pun. Barulah pindah ke koneksi perangkat atau soket langsung ketika Anda mengejar seratus milidetik terakhir atau mencetak dari service tanpa sesi desktop.
Untuk POS yang dibangun khusus, jalur terpendek adalah membuka transport sendiri. Lewat USB atau serial itu berarti sebuah device node; lewat Ethernet itu berarti koneksi TCP ke port cetak mentah printer.
// Node: raw TCP to an Ethernet TM printer. One socket, one receipt, close.
import { Socket } from "node:net";
const PRINTER_PORT = 9100; // the raw print port on TM Ethernet models
const CONNECT_TIMEOUT_MS = 3000;
export function printRaw(host: string, payload: Buffer): Promise<void> {
return new Promise((resolve, reject) => {
const socket = new Socket();
socket.setTimeout(CONNECT_TIMEOUT_MS);
socket.once("timeout", () => socket.destroy(new Error("printer timeout")));
socket.once("error", reject);
socket.connect(PRINTER_PORT, host, () => {
// end() flushes then FINs — the printer treats the close as end of job.
socket.end(payload, () => resolve());
});
});
}Dua detail memisahkan implementasi yang bekerja dari yang rapuh. Buka koneksi per struk lalu tutup — penutupan itulah yang diperlakukan banyak firmware TM sebagai akhir pekerjaan. Dan jangan pernah menahan soket tetap terbuka antar transaksi demi menghemat handshake: koneksi setengah terbuka ke printer yang sempat dimatikan akan menerima tulisan dan tidak mencetak apa pun.
Keputusannya hampir mekanis begitu Anda menjawab ketiga ini.
Dalam pekerjaan POS saya sendiri jawabannya selalu sama: byte mentah, lewat antrean bila toko sudah punya, langsung ke port bila belum.
Simpan kedua jalur di balik satu antarmuka dalam kode Anda — sebuah transport printer dengan satu metode kirim. Berpindah dari toko ber-USB ke toko berjaringan lalu menjadi urusan konfigurasi, bukan penulisan ulang, dan Anda bisa menguji unit penghasil byte tanpa printer terpasang sama sekali.
Kalau Anda mewarisi sistem yang mencetak struk lewat driver, urutan yang berhasil adalah: hasilkan struk yang sama sebagai byte ESC/POS berdampingan dengan jalur lama, buang keduanya ke berkas, bandingkan hasil cetaknya dengan mata di atas kertas, lalu balik feature flag per toko. Tidak ada yang berubah pada alur transaksi, dan Anda bisa membatalkan satu toko tanpa menyentuh yang lain.
Hasil terukurnya biasanya sama: struk turun dari beberapa detik menjadi kurang dari satu detik, laci uang mulai terbuka dari perangkat lunak, dan keluhan soal antrean cetak macet lenyap karena tidak ada lagi antrean yang bisa macet.
Driver Windows bukan salah, ia umum. ESC/POS mentah bukan pintar, ia spesifik. Aplikasi point-of-sale adalah satu dari sedikit tempat di mana kespesifikan jelas menang, dan harga kespesifikan itu hanyalah satu sore untuk mempelajari bahasa perintah kecil yang kemudian Anda pakai bertahun-tahun.