absolute servo following error

Katılım
11 Eyl 2009
Mesajlar
453
Puanları
6
Yaş
37
Merhaba, profidrive üzerinden technology object ile motion control yapmaktayız. Fakat yüksek hızlara çıktığımızda servo following error veriyor, ardından durduğu yerin konum bilgisini kaybediyor ve tekrardan home yaptırmak zorunda kalıyoruz. Oysa motor ebsolute ve frenli.

Yüksek hızlara çıkıp following error hatasını aşmanın bir yolu varmıdır acaba ? Biz rampa sürelerini uzatarak çözmeyi denedik ama hareket sahası kısa olduğu için rampanın da çok uzun olmaması gerekiyor.

Edit: servo modeli s110-plc s71200
 
Son düzenleme:
KNX Standardı, küçük bir rezidansın içerisindeki aydınlatma, perde panjur, klima kontrolünden, Dünya’nın en büyük havalimanlarındaki aydınlatma otomasyonu gibi çözümler için tercih edilen bir Dünya standardıdır.
Yazımızda endüstrinin can damarı sayılabilecek PLC’yi inceleyeceğiz.
On santim yolda 500 basacaksın dersen olmaz. Tutamayacağı veya yavaşlayamacağı ivmelere neden çıkıyorsunuz ?

Ayrıca absolute ve frenli, garip bir durum çünkü dur-kalktan bahsedersen fren hızı yetişemez servoya.

Following errorun rampa hızı ve max hızdan dolayı yükseldiğinden eminmisin. Belki sonraki adım değerlerine çıkamadığı için o hatayı veriyor. Atalet aşımı sözkonusu...
 
Hocam bu konuya netlik kazandırmak adına motoru boşta denedik ve sonuç yine aynı, fakat sıkıntının büyüğü following error anında durduğu yerin pozisyonunu kaybetmesi. Oysa alet absolute.

Bu arada fren kontrolünü direk drive yapıyor ve enbled durumuna geçtiği andan itibaren fren zaten sürekli açık kalıyor.

Siemens teknik servis ile görüştüm onlarda lafı çevirip çevirip duruyorlar. S71200 ile profidrive üzerinden technology object kullanımını pek tavsiye etmiyoruz gibisinden şeyler söylüyorlar. real time haberleşme bir tek s71500'de oluyormuş vs.

Fakat ben bu sistemi kurdum ve bir şekilde çözüm bulmam gerekiyor.
 
OOO, hardware reset ! Neden şaşırmadım ?

Sürücünü tanımıyorum ama şayet step adımı tanımlanabiliyorsa tanımla ve digital girişlerden motora birebir aynı hareketi yaptırmayı dene, şayet o ivmelenmeyi başarırsa MCU(sürücü işlemcisi) çöküyor demektir.

Sürücün reset sinyali alıyor, bunun haberleşme ile alakası yok (haberleşme birimi profibus direk MCU'yu etkiliyor(Donanımsal))!

Diğer metodları dene, USS, CAN vs.

Problemin olası çözüm adımları :

  1. Profibus hızını seni kurtaracak minimum seviyeye çek(500kbit yetiyorsa(veya daha düşük) 1m veya 6,8,12mbit kullanmanın anlamı yok , çünkü slave modüllerde clock sinyalini oturtmak masterdan on (10) kat daha zordur).
  2. Profibus haberleşme voltajını osilaskop ile kontrol et(Muhtemelen o sürücüde yada plc de optik izelasyon yok ! Yada her ikisinde).
  3. Sürücünün tüm topraklamalarını kontrol et ve tüm kabloların ekranlı , aynı zamanda ekranlarınında toprağa bağlı olduğundan emin ol.
  4. Sürücüye biryerlerden reverse (dönüş) voltajı geliyor olabilir. DC bara voltajını düşürme yollarını ara.
  5. Sürücünün beslemesine, konumuna uygun EMF filtresi tak. (Monofaze yere trifaze filitre takan dünya devi mal şirketler gördüm)
  6. Virtual ground oluştur( siemensin ürününü açıp kafana göre tekrar düzenle, bence değmez çünkü siemens senden daha çok kazanır (bilgini tenzih ederim))
  7. Master resette tüm veriler silinir, software reset asla kalıcı dataları silmez, ciddi anlamda donanım kontrolü yapmanız gerekiyor. Arızanız büyük ihtimalle sürücüde çünkü sürücüde siemens sıçar. (Aksini iddia eden herhangi biri ile sabahlara kadar tartışabilirim(bilinmeyen arızadan dolayı motoru durdurup sisteme run sinyali verebilecek başka bir lanet sürücü görmedim...))
Aklıma başkada şeyler gelmedi şimdilik, gelince ilave ederim...
 
Hocam değerli önerileriniz için teşekkür ederim, fakat benim fikrim drive tarafında değilde plc tarafında bir sıkıntının olduğu.

Çünkü technology object içerisinde ki motion control bölümüne proidrive özelliği daha yeni eklendi öncesinde hep analog kontrol vardı.

Her zaman ki gibi siemens yarım yamalak komutları gönderdi bize ve bizi madara etti.

Şimdi bu bug nasıl ispat edilir, üstlerimize nasıl hesap veririz al başına belayı.
 
Hocam değerli önerileriniz için teşekkür ederim, fakat benim fikrim drive tarafında değilde plc tarafında bir sıkıntının olduğu.

Çünkü technology object içerisinde ki motion control bölümüne proidrive özelliği daha yeni eklendi öncesinde hep analog kontrol vardı.

Her zaman ki gibi siemens yarım yamalak komutları gönderdi bize ve bizi madara etti.

Şimdi bu bug nasıl ispat edilir, üstlerimize nasıl hesap veririz al başına belayı.

O kolay !

Hilscher (başka bir angut alman firması) Ethernet to Profibus dönüştürücü edin, sürücünü bilgisayardan aynı hareket yaptırarak çalıştır. Şayet çalışırsa o zaman PLC çöküyor demektir. Clock sinyalinin bozulması (master) MR (master reset) tetiklemesi yapması lazım ki tüm aktif süreçler askıya alınsın. Yoksa varolan işleme contune komutu uygulamak her babayiğidin harcı değil.

Bu alman firmalarının "yaptık, oldu !" edaları beni hasta ediyor...

Adamlara "registerlar neden hep unidirection diyorum" adamlar "Program kodlarınızı ve yapılandırma ayarlarınızı gönderin, bakalım". Gelde günahkar olma....

CPU kapasitesini aşan işlem yaptığını düşünüyorum. Elinizdeki CPU ile o işi yapmanız çok zor (ha firmware güncellemesi yaparlarsa o başka, ama bu sefer diğer fonksiyonların "sıçma" ihtimali var)! Bu ürünleri kullanarak ib*nelerin ürünlerini gelişmesine katkıda bulunuyorsunuz. Bu zihniyetteki üretimin tüm devlet ihalelerini aldığını düşünürsen işin nekadar acıklı olduğunu görürsün.

Servoda Panasonic ürünlerini şiddetle tavsiye ederim. Ve elinizden geldiği kadar PLC lerden uzak durun..

PLC leri I/O ünitesi olarak kullandığım için terabaytlarca program sığam, 6 çekirdekli işlemcilerim, Gigabytelarca RAM im var. Tabi hal böyle olunca ister istemez "Acaba paket gönderme süresini 50 mikrosaniyeden nasıl 25 lere düşürürüm" fikirleri uyanıyor.
Mikro denetleyiciler bağımlılıklarıda beraberinde getirir. İşi yapan çevre birimlerine (I/O, DAC,ADC, Drive) paranın alacağı en iyisini alın sonra en kötü bilgisayarla kontrol edin.

Not : Ispat etsen bile yine sen haksız olacaksın. Neden mi ? Adamlar basacak iskontoyu, patronlarının dişleri kırılacak ama sen bok küremeye yaldır yaldır devam edeceksin... Tamam bu not zalimce görünebilir ama dünyanın düzeni böyle...
 
Hocam sistem profibus değil profinet üzerinden kontrol ediliyor. CU305 PN var.

Evet aslında plc üzerinde yüküm var, çünkü plc yanında 8 adet modül, ve ayrıca kontrol ettiği 2. bir makina var.

Ben nasıl olsa tek eksen ve point to point bir uygulama olacak diye üstesinden gelir diye düşünmüştüm. Şimdi 1500'e çevirme şansım da yok bakalım ne olacak.

CPU en güncel firmware sahip, sistemin dinamikliğini düşürdüğümde yani eksen ivmesini düşürdüğümde following error durumuna düşmüyor artık. Ama ne olur ne olmaz following error prosedürü yazdım.

Error anında sistem software olarak home pozisyonu isteyecek ve bu şekilde eksen sonuna çarpma ihtimali kalkacak ortadan. Absolute sistemde böyle bir önlem almak bir teknik adam için çok acı. Çok yaşa siemens...
 
Öncelikle Siemens'in T CPU'ları hariç normal CPU larla Motion control yapmanız çok verimli değildir. Çünkü PLC realtime olmasına rağmen ek istekler örneğin PG ile bağlanmanız dahi Motion Control uygulamanızı etkiliyor. Bunu bizzat yaşamış biri olarak sözüme güvenebilirsiniz.

Şimdi gelelim probleminizin çözümüne:

-Absolute encoder kullanmanız pozisyonun aynı değerde kalmasını garanti etmez. Çünkü Technology object içerisindeki pozisyon görecelidir. Yani absolute encoderdan gelen değeri belli parametrelerle skalalandırır ve ona göre göreceli bir pozisyon çıktısı alınır. Sizin probleminizde yaşanan gecikmeler ve işletim zamanı değişiklikleri bu algoritmanın bozulmasına yol açar.

-Following: Birim zamanda eksenin olması gereken pozisyonla gerçek pozisyonu arasındaki farka denir. Bu da çeşitli nedenlerden ortaya çıkar. Bunlardan biri mekanik zorlanma veya Kp ve Feed forward parametrelerinin uyumsuz olmasından kaynaklanır. Ama feed forward parametresini doğru bir şekilde ayarlasanız bile sistemin işleyişi yanlış olduğundan dolayı yine de verim alamazsınız. Rampadan kaynaklanmaz çünkü controller rampa zamanlarını da yukarıda açıkladığım şekilde zamanlamaya dahil eder.


Sisteminizde S110 kullandığınızı belirtmişsiniz. Neden EPOS kullanmadınız? S110 FB283 ile direkt olarak pozisyon kontrolünü yapabiliyor. Yani pozisyon kontrolünü S110'un kendisine yükleyebilirsiniz. Bu durumda PLC üzerinde yalnızca set pozisyonunu gönderirsiniz aktüeli alırsınız vs..

"Siemens teknik servis ile görüştüm onlarda lafı çevirip çevirip duruyorlar. S71200 ile profidrive üzerinden technology object kullanımını pek tavsiye etmiyoruz gibisinden şeyler söylüyorlar. real time haberleşme bir tek s71500'de oluyormuş vs. "

Normalde sürücü sistemleri Isochronous haberleşme kullanır. Yani normal Profinet deterministik olmadığı için performans problemleri ortaya çıkar. S7 1200'de maalesef Isochronous Profinet desteklemiyor. Siemens'in size bu şekilde dönüş yapması çok normal.


https://en.wikipedia.org/wiki/Isochronous_timing


Sorunuzun ana nedeni: Motion Controller olarak PLC kullanmanız.
Çözümü: S110'un kendi pozisyon kontrolünü kullanmalısınız. (EPOS)
 
Öncelikle Siemens'in T CPU'ları hariç normal CPU larla Motion control yapmanız çok verimli değildir. Çünkü PLC realtime olmasına rağmen ek istekler örneğin PG ile bağlanmanız dahi Motion Control uygulamanızı etkiliyor. Bunu bizzat yaşamış biri olarak sözüme güvenebilirsiniz.

Şimdi gelelim probleminizin çözümüne:

-Absolute encoder kullanmanız pozisyonun aynı değerde kalmasını garanti etmez. Çünkü Technology object içerisindeki pozisyon görecelidir. Yani absolute encoderdan gelen değeri belli parametrelerle skalalandırır ve ona göre göreceli bir pozisyon çıktısı alınır. Sizin probleminizde yaşanan gecikmeler ve işletim zamanı değişiklikleri bu algoritmanın bozulmasına yol açar.

-Following: Birim zamanda eksenin olması gereken pozisyonla gerçek pozisyonu arasındaki farka denir. Bu da çeşitli nedenlerden ortaya çıkar. Bunlardan biri mekanik zorlanma veya Kp ve Feed forward parametrelerinin uyumsuz olmasından kaynaklanır. Ama feed forward parametresini doğru bir şekilde ayarlasanız bile sistemin işleyişi yanlış olduğundan dolayı yine de verim alamazsınız. Rampadan kaynaklanmaz çünkü controller rampa zamanlarını da yukarıda açıkladığım şekilde zamanlamaya dahil eder.


Sisteminizde S110 kullandığınızı belirtmişsiniz. Neden EPOS kullanmadınız? S110 FB283 ile direkt olarak pozisyon kontrolünü yapabiliyor. Yani pozisyon kontrolünü S110'un kendisine yükleyebilirsiniz. Bu durumda PLC üzerinde yalnızca set pozisyonunu gönderirsiniz aktüeli alırsınız vs..

"Siemens teknik servis ile görüştüm onlarda lafı çevirip çevirip duruyorlar. S71200 ile profidrive üzerinden technology object kullanımını pek tavsiye etmiyoruz gibisinden şeyler söylüyorlar. real time haberleşme bir tek s71500'de oluyormuş vs. "

Normalde sürücü sistemleri Isochronous haberleşme kullanır. Yani normal Profinet deterministik olmadığı için performans problemleri ortaya çıkar. S7 1200'de maalesef Isochronous Profinet desteklemiyor. Siemens'in size bu şekilde dönüş yapması çok normal.


https://en.wikipedia.org/wiki/Isochronous_timing


Sorunuzun ana nedeni: Motion Controller olarak PLC kullanmanız.
Çözümü: S110'un kendi pozisyon kontrolünü kullanmalısınız. (EPOS)

İsterdim ki bu yazınızı belli bir markayı "holigan" seviyesinde destekleyenlerde okusa.
Kötü mal yoktur, kötü tercihler vardır...
 
Sisteminizde S110 kullandığınızı belirtmişsiniz. Neden EPOS kullanmadınız? S110 FB283 ile direkt olarak pozisyon kontrolünü yapabiliyor. Yani pozisyon kontrolünü S110'un kendisine yükleyebilirsiniz. Bu durumda PLC üzerinde yalnızca set pozisyonunu gönderirsiniz aktüeli alırsınız vs..

Hocam bu fikir hoşuma gitti fakat bu konuda bana yardımcı olabilirmisiniz ? Bu uygulamayı drive üzerinden nasıl yapabilirim ?
 

Forum istatistikleri

Konular
128,198
Mesajlar
915,767
Kullanıcılar
449,979
Son üye
schule48

Yeni konular

Geri
Üst