PLC Programında En Pahalı 5 Hata: Devre Almada Öğrendim, Siz Masada Öğrenin
Sahada, devreye almada, serviste defalarca karşılaştığım 5 programlama hatası. Her birini kendi yaşadığım vaka üzerinden anlatıyorum: nasıl tespit edildi, kaç saat gitti, ve masada 5 dakikada nasıl yakalanırdı.

Bu yazı, “PLC yazarken bunlara dikkat edin” listesinin kurumsal hali değil. Bunlar, geçen senelerde sahada, devreye almada, serviste, saatlerce — bazen günlerce — “bu hata yüzünden ne yaptık” dediğim beş hata. Ortak yönleri var hepsinin: masada, simülatörde, beş dakikada yakalanabilecek hatalar. Ben onları sahada saatlerle; siz masada dakikalarla öğrenin.
1. I/O Atamasını “Aklıma Geldiği Gibi” Yazmak
Bir projede tablo güzeldi: Motor1_Start, Vana2_Aciq, temiz, okunaklı. Ama I/O tablosuna baktığınızda %I0.0 = “acaba buydu ya?”, %I0.1 = “şu olacaktı galiba”…
Bu hatanın masadaki maliyeti on dakika. Sahadaki maliyeti üç saat. Çünkü devreye almada “ben programda Motor1_Start yazdım, ama panodaki %I0.0 aslında Motor2’nin startı” anı, “program mı yanlış, kablo mı?” tartışmasına döner. Ve sahada en pahalı tartışma budur: iki uzman, “bana göre program doğru” ile “bana göre kablo doğru” diye üç saat boyunca birbirine hak verir.
Ben artık I/O tablosunu “tek doğruluk” değil, “üç kenarlı kontrol” olarak yazıyorum. Her satır; (1) panodaki terminal etiketi, (2) kablonun karşı ucu, (3) programdaki tag. Üçü aynıysa geçer. Biri bile farklıysa, tartışma başlamış demektir.
2. “Simülatörde Çalıştırdım” Sendromu
Simülatörde makine saatlerce sorunsuz döner. Ama simülatör mekanik toleransı göstermez. Sıcak bir yazın öğleninde motorun üstüne binen yükü göstermez. Operatörün beşinci saniyede üçüncü butona basma ihtimalini göstermez.
Bir keresinde tam da bu oldu. Simülatörde sekiz saat döndürdük, “güzel” dedik. Sahanın ilk günü, öğleden sonra üç, makine bir “tık-tık” sesi çıkarıp durdu. Programda timing hatası vardı: iki adım hızlı üst üste gelince, aralarına giren bir sensör signal’ı kayboluyordu. Simülatörde o iki adım asla hızlı gelmediği için hiçbir şey göstermemişti.
Kuralımız artık: devreye almadan önce simülatörü “en az üç gün, durmaksızın, gerçek tempoda” çevirmek — “tamam bir tur attı” diye değil. O “tık-tık”ın sahada değil, simülatörde çıkması için.
3. Alarmları “Sonra Yazarım” Demek
Devreye alma günü hat çalışıyordur, ama “hangi alarm, ne zaman, hangi öncelikte, hangi ekranı açar” sorusu “sonra”ya kalmıştır. O “sonra” asla gelmez. Çünkü bitişte “hat çalışıyor” denir, “kapıyoruz” denir. Ve kapanışın ortasında bir alarm “beni unutmayın” der. Ama o alarmı “sonra” yazdığınız için, operatör “abi bu kırmızı ışık yanıyor, ne yapayım?” der. Siz de “bir bakayım” dersiniz. O “bir bakayım”, iki saattir.
Benim kuralım: devreye almadan önce “en kritik beş alarm” mutlaka programda. Tanımı net: “bu alarm olursa makine durur ya da hasar alır” olanlar. Bu beşin dışındakiler “sonra”ya kalabilir. Ama o beş, asla.
4. Komünikasyon Düşünce Sessizce Yutmak
PLC ile HMI ya da başka bir PLC arasında bir “bağlantı” vardır. Bir gün o bağlantı kesilir: kablo, reboot, ya da IP filtresi. En pahalı versiyonu şudur: program, “bağlantı düştü” olayını sessizce yutar. HMI “PLC’ye ulaşamıyorum” demez, sadece “son bilinen durumu” göstermeye devam eder.
Bir kere başıma geldi. HMI’da “makine çalışıyor” gözüküyordu, çünkü son bilinen durum oydu. Ama aslında bağlantı yirmi dakika önce kopmuş, makine de STOP’a geçmişti. Operatör “abi makine neden çalışmıyor?” dedi. Cevap: com kopmuş, kimse haberdar değildi. Ben de dahil. O “habersizim”, programın kusuru olmaktan çıkıp benim kusurum oluyordu.
Çözüm basit: her bağlantı için bir “yaşıyor muyum” sayacı. Mesela “bağlantı üç saniye kesilirse, ekrana net net ‘PLC’ye ulaşamıyorum’ yaz”. O üç saniye, sizin güvenli sürenizdir. Bu, aslında ağ tarafında IP filtresiyle aynı aileden bir dert; geçen yazımda detaylamıştım: PLC’yi ağa bağlarken “abi laptop neden NC göremiyor”.
5. “Bu Kodu Ben Yazdım” ve İki Yıl Sonra “Bu Ne?”
En insani, en pahalı hata bu. Bir projeyi üç yıl önce siz yazdınız. Ama “bu sayı neden 47?” sorusunun yanıtı yok, çünkü not yok. İki yıl sonra siz o kodu açtığınızda, “bu kimin, ben mi koymuştum?” diye bakıyorsunuz kendi yazdığınıza. Cevap, “47’deyken çalışıyordu”dan başka bir şey değil.
Bu artık kod değil, arkeolojidir. Ve arkeolojinin sahada “bu makine neden bu tempoda?” sorusuna “bilmiyorum, ama 47’deyken çalışıyordu” diye cevap vermesi, makineyi değil, sizi düşürür müşteri gözünde.
Benim kuralım: her “tuhaf görünen” sayının yanına, “neden bu sayı” satırı. O satır, iki yıl sonraki sizinle bugünkü sizin konuşur. Ve o konuşma, en pahalı hatanın en ucuz önlemidir.
Masada Beş Dakika, Sahada Beş Saat
Beş hatanın ortak noktası: hepsi masada beş dakikada yakalanır. Sahada ise beş saat — bazen beş gün — “neden?” sorusuyla uğraşılır. O sorunun asıl cevabı: “neden masada o beş dakikayı harcamadık.”
- hata — “bağlantı sessizce yutma” — bir de haberleşme tarafında karşımıza çıktı: kablo sağlam, güç sağlam, ama 11. slave sessiz. Orada da masadaki beş dakikanın sahada on beş dakikasından pahalı olduğuna inandım. Modbus RTU ile 15 Dakikalık Sessizlik o 15 dakikanın kısa notu.
Bu beş hatanın en iyi yanı: hepsi masanın en ucuz hatası. I/O ataması, simülatör sendromu, alarm “sonra”, com sessizce yutma, kod arkeolojisi — simülatörde bir kere yaşarsanız, sahada beş saati daha beş dakikaya çeker. Masada ödeyince, sahada ödetmez. Masanın tek avantajı budur: hata yaptığı gün, saha’daki o beş saati beş dakikaya çevirir.