Depoda palet etiketi basılıyor, etiket iade masasından
çıkıyor. Kimsenin kodu değişmedi. Bu arıza rastgele gibi görünür ama değildir
— bir kimlik sorunudur. Neredeyse her baskı yığını yazıcıyı
değişmesine izin verilen bir şeyle tanır: kuyruk adı, IP adresi, Windows
paylaşımı. Kimlik kayınca işler makineyi değil, kimliği takip eder.
Üç klasik şüpheli
1. IP değişti (DHCP)
Yazıcılar da dizüstüler gibi kira alır. 192.168.1.50 adresine kurduğunuz
yazıcı elektrik kesintisinden sonra .73 olarak döner; .50 adresini başka bir
cihaz kapar. .50 adresine gönderilen her iş artık başka bir yerde
basılır — ve 9100 portu bunu sessizce kabul eder, çünkü ham baskıda
"sen benim sandığım yazıcı mısın?" diye soran bir el sıkışma
yoktur.
2. Kuyruk yanlış cihazı gösteriyor
Windows ve CUPS kuyrukları elle bakılan bir ad-port eşlemesidir. Bir iş
istasyonunu klonlayın, bir yedeği geri yükleyin ya da sürücüyü
"iyilik olsun diye" yeniden kurun; PRINTER_A sessizce PRINTER_B'nin
portuna düşer. Uygulama her şeyi doğru yaptı; yalan söyleyen eşlemeydi.
3. Paylaşılan adlar
İki tesis, ikisinde de ZEBRA-DOCK adında bir kuyruk. Dizüstü seyahat eder,
yanlış VPN profiline bağlanır ve beş yüz sevkiyat etiketi yanlış tesiste
basılır. Ada dayalı kimlik hangi ZEBRA-DOCK olduğunu bilmez.
Rivayetsiz teşhis
Her kuyruktan, hedefin kendi kimliğini taşıyan bir test
etiketi bastırın (seri numarası ya da yapılandırma etiketi) ve
kuyruğun gösterdiğini sandığınız cihazla karşılaştırın. Bunu her ağ
değişikliğinden sonra yapın, bir kez değil.
Yazıcının kendi yapılandırma sayfasına bakın: kuyruğun kullandığı IP,
yazıcının bildirdiği IP ile aynı mı?
DHCP ağlarında kira tablosunu listeleyin: yazıcının MAC adresi hâlâ
işlerinizin gittiği adrese bağlı mı?
Bu listede olmayan şeye dikkat edin: yeniden basıp ummak ya da
etiket dosyasını suçlamak. Baytlar neredeyse her zaman doğrudur — ZPL bir
etiketi anlatır, bir hedefi asla — bu yüzden içerik düzeyinde bir kontrol bu
arızayı bulamaz. Dosyayı önce elemek isterseniz
tarayıcıdaki önizleme baytların ne
üreteceğini birebir gösterir; önizleme doğru, kâğıt yanlışsa hata düzende
değil adreslemededir.
Önleme
Üretimdeki her yazıcı için adres ayırın (DHCP rezervasyonu
ya da statik IP). Bu tek başına 1. sebebi ortadan kaldırır.
Kuyrukları konum ve işleve göre adlandırın
("DOCK3-PALET-203DPI") ve bir adı tesisler arasında asla tekrar
kullanmayın.
Her sürücü ya da kuyruk değişikliğinden sonra, üretime dönmeden önce
yazıcının kimliğini taşıyan bir doğrulama baskısı şart koşun.
Yapısal olarak: yazıcıları değişebilen bir adresle değil,
kararlı bir cihaz kimliğiyle adresleyin. İşi yazmadan önce
hangi fiziksel cihazın yanıt verdiğini doğrulayan bir gönderici, 1. ve 3.
sebepleri disiplinle "azaltmak" yerine tasarımla imkânsız kılar.
Neden nadir kalır ve sonra bir vardiyaya mal olur
Yukarıdaki mekanizmaların hepsi sessizce ve aralıklı olarak bozulur: bir
kiranın dolması ve başka bir cihazın o adresi kapması gerekir; bir
imajın klonlanması ve bir adın çakışması gerekir. Tesisler yıllarca
bunu yaşamaz, sonra bir vardiyalık sevkiyat etiketini yanlış masada bulur.
Arızanın yokluğu, güvenli bir tasarımın kanıtı değil, biriken şanstır — çözüm
de tam bu yüzden bir alışkanlıkta değil, adresleme katmanında durmalıdır.
Çünkü yazıcı, değişmesine izin verilen bir şeyle adreslendi: bir DHCP kirası, bir kuyruk-port eşlemesi ya da paylaşılan bir kuyruk adı. Kimlik kayınca iş makineyi değil kimliği takip eder ve 9100 portu, karşısındakinin hangi cihaz olduğunu hiç sormadan kabul eder.
Hangi kuyruğun nereye gittiğini nasıl bulurum?
Her kuyruktan, hedefin kendi kimliğini taşıyan bir test etiketi bastırın (seri numarası ya da yapılandırma etiketi) ve kuyruğun gösterdiğini sandığınız cihazla karşılaştırın. Bunu bir kez değil, her ağ değişikliğinden sonra tekrarlayın.
Bunun sebebi etiket dosyası olabilir mi?
Hayır. ZPL bir etiketi anlatır, hedefi asla: hedef yazıcıyı adlandıran bir alan yoktur. Tarayıcıdaki önizleme doğru etiketi gösteriyor ama kâğıt hâlâ yanlışsa hata düzende değil adresleme katmanındadır.
