Picproje Elektronik Sitesi

Merhaba
Bir cihaz geliştirdiğimizi düşünelim. Bu cihaz Canopen hattınca slave olarak çalışacak ve komutlarını canopen hattı üzerinden alacak hem pdo hem sdo servislerini kullanacak. Kendi obje listesine sahip olacak.

Böyle bir sistemi gömülü sistem olarak veya PLC lerin canopen terminallerini kullanarak geliştirdiğimizi düşünelim.

Bu canopen slave cihazının kendi obje listesini oluşturabilior olmamız gerekir değilmi. Örnek olarak h6000 adresine ben cihazın çektiği akımı. h6001 objesine cihazın sıcaklığnı tanımlayabiliyor olmam gerekir. Ve ben bu objelere ister sdo ile ister pdo servisleri ile erişebiliyor olmam gerekir.

Sorum şu aslında böyle bir canopen slave cihazı geliştirmeye kalktığımızda kullandığımız geliştirme araçları plc veya gömülü sistem bize bu şekilde kendi obje listemizi oluşturma imkanını veriyor mu?

Bu tarz bir projede çalışmış veya fikri olan arkadaşlardan cevap bekliyorum. Teşekkürler.
İnşAllah sormak istediğimi anlatabilmişimdir.

Tam da şu sıralar CANopen destekli bir cihaz geliştirmeye çalışıyorum ve öğrenme safhasındayım. İlk denemeleri STM32F103'te yapmayı planlıyorum.

Aslında ortalıkta adı geçen iki kütüphane var: CANopenNode ve CanFestival. Ancak ikisi için de yeterli dokümantasyon bulamadım ve öğrenmeye nereden başlayacağımı çözemedim. Bana fazla karmaşık geldiler. Ben de sıfırdan kod yazmaya karar verdim.

Sıfırdan kod yazmak zor bir iş olacak, ama en azından ne olup bittiğini tam olarak anlayabileceğim. SDO sunucusunu büyük oranda yazdım ama daha testlere başlayamadım. Aynı zamanda Object Dictionary'yi (OD) yönetecek kodu da büyük oranda tamamladım.

Bilgisayar tarafındaki CANopen yazılımları, cihazlarla iletişim kurabilmek için EDS dosyasına ihtiyaç duyuyorlar. Bu dosyayı elle yazmak pratikte pek mümkün değil. Bunu oluşturabilecek ücretsiz yazılım bulmak da zor ama ben bir tane bulabildim epey bir araştırdıktan sonra: Vector CANeds.

Ancak işlemci tarafındaki gömülü yazılım için kod üretecek bir yazılım bulmak neredeyse imkansız gibi. Hem zaten bu yazılımın, kullanılan gömülü yazılıma uyması gerek. Kendim kod yazıyor olduğum için bu konuda hiç şansım yok, tüm OD'yi kendi koduma göre elle yazacağım STM32 kodunun içine. Ya da oturup EDS'den bana uygun STM32 kodu üreten bir program yazacağım, ki böyle bir zahmete girmeye şimdilik niyetim yok.

OD'nin gömülü sistemde C kodu olarak ifade edilmesi pek kolay değil. Benim epey kafa patlatmam gerekti. Bir sonuca vardım ve epey kod da yazdım ama verimli olup olmadığını bilemeyeceğim.

Birisi libedssharp diye bir proje yapmış. Bir başla EDS editör programı ama sanırım CANopenNode için kod üretme özelliği de var. Programı bir denedim ama sevmedim. Sanki henüz bitmemiş gibi, bir dolu garip hatası var.

Senin sorunu doğru anladım mı emin değilim ama özetle, bilgisayarda OD'yi düzenleyip bundan EDS oluşturan programlar var. Çoğu ücretli de olsa 1-2 tane ücretsiz veya demo yazılım bulunabiliyor. Ancak EDS dosyası gömülü sistemi kodlarken işine yaramayacak, tabi eğer EDS'yi işleyip kendine uygun bir kod üretici program yazmazsan.

Ekleme: CanFestival'de de kod üretme özelliği varmış.

Projemiz canopen slave çalışacak bir sistem. Canopen tarafını proje süresi kısa olduğu için hazır terminallerle yapalım diye kararlaştırdık. Gömülü yazılım için işin uzayacağını ve zor olacağını tahmin etmiştik.
Bir markanın embedded PC ve canopen slave terminalini aldık. Bu terminalde özellikle sordum kendi obje listemizi oluşturup bu objelere SDO ve PDO ile erişebiliyormuyuz diye. Ama ürünü alıp geliştirme aşamasını gelince ürünün sadece pdo atabildiği ortada bir obje listesinin olmadığı yazılım içerisindeki değişkenlerin pdo dan gönderdiğini gördük. Bu değişkenlere sdo üzerinden erişemiyorduk. Yani bu modül bir nevi kısıtı bir canopen kullanan bir yapıya sahip.
Bu durumda bende kendimle çeliştim. Muhtemelen hazır alınabilecek çoğu sistemde bu şekilde. Kendi firmware larina belli bir OD yüklenmiş ve bu OD değiştirilemiyor. Sadece bu OD lere yazılımdan bir değer verilebiliyor.
Dediğim gibi kendi OD mizi oluşturup bu objelere hem sdo hem pdo ile erişebileceğimiz bir cihaz varmıdır bilmiyorum.

@Tagli Siz Nesneleri ROM,RAM,Eeprom gibi bir hafızayamı kaydediyorsunuz. Protokol nesnelere o hafıza adreslerindenmi erişiyor. Canopen yapısınını gömülü yazılım olarak gerçeklenme mantığını anlamaya çalışıyorum.
Sonra bu neslerin yazılım için kullanırken o adreslere sahip pointerlar ilemi erişiyorsuunz.

CANopen tamamen uygulamaya geçirmesi zor bir standart. O yüzden anladığım kadarıyla üreticiler basit ürünler için sadece gerekli olan asgari bölümü destekliyorlar.

Ben SDO server, OD, PDO ayarları (mapping dahil), SYNC consumer, heartbeat producer gibi özellikleri kodlamaya çalışıyorum. OD elemanları, bellekte kaplayacakları normal alan haricinde index, subindex, erişim izinleri halan gibi bilgileri de içermeleri gerekiyor. Bu sebeple her değişken için bellekte bir de ona işaret eden bir struct tutmam gerekti. Şu an için aşağıdaki gibi bir yapı kullanıyorum:

typedef struct DictObject {
	uint16_t index;
	uint8_t subIndex;
	struct {
		uint8_t type : 4; // One of DictObjType
		uint8_t isSub : 1; // 1 if this entry is a sub-entry
		uint8_t isArray : 1; // 1 if this entry is an array
		uint8_t access : 2; // One of DictAccType
	};
	uint16_t length; // String length
	uint8_t nSubs; // Number of sub-indexes this object has (or array elements)
	void *ptr;
} DictObject;

En iyi çözüm bu mu bilmiyorum. Bu yapıları bir dizi olarak saklıyorum ve istediğim index değerine binary search ile erişiyorum. Ancak maalesef bunları ROM'a koyamadım. C dili const bir ifadenin içinde değişken adresi gibi sabitlere izin vermiyor. C'nin bakışına göre sadece literal ifadeler ve enum'lar sabit sayılıyor. Belki bir miktar uğraşsam dolambaçlı da olsa bir yol bulabilirdim. Bu haliyle OD'deki her değişken için (subindex'ler dahil, array'ler hariç) RAM'den 12 byte harcamam gerekiyor.

Bu yapılar gerçek değişkenin adresini ve türünü tutuyorlar. Böylece SDO server bunlara erişebiliyor. PDO kodunu yazmadım henüz ama aynı mantığın çalışacağını sanıyorum.