Zerkę, być może to lepsza droga, choć w moim przypadku ramki komunikacyjne powinny być znacznie powyżej 256 bajtów ... ale pomyśle o pakietowaniu w mniejszych ilościach.
Zerkę, być może to lepsza droga, choć w moim przypadku ramki komunikacyjne powinny być znacznie powyżej 256 bajtów ... ale pomyśle o pakietowaniu w mniejszych ilościach.
Jeszcze raz powtorze-czysty RS485 tego nie przewiduje. Mozesz jednak nietypowo polaczyc typowe drivery do 485, by iloczyn na drucie uzyskac. Robi sie tak dla CAN-a.
peters
P.S. zakłÓcać :) bardzo prosze !
Z tym akurat nie ma problemu. Ja przesylam po CAN-ie takze pliki. CAN zalatwia Ci jedna bardzo wazna sprawe -nie obciazasz tak bardzo procesorow.
A tak w ogole, to chyba nie napisales jakie predkosci transmisji Cie interesuja. Ile tych danych w ogole bedzie do przeslania. peters
Mam jeden pomysl, wydaje mi sie ze dosc prosty w realizacji. Budujesz sobie siec w ktorej do Mastera podlaczasz Slave-y. Slave moze byc urzadzeniem koncowym, lub koncentratorem. Koncentrator musi miec dwa RS485. Jeden do lacznosci z masterem, drugi do komunikacji z grupa urzadzen, dla ktorych sam jest masterem. Czyli powstaje rodzaj drzewa.
W ten sposob mozesz podlaczyc nawet ogromna ilosc urzadzen. W latwy sposob wykrywane sa nawe urzadzenia. Awaria w pojedynczej podsieci nie psuje calosci.
peters
Tu jest mały problem. Otórz nie wiem, jakie będą mikrokontrolery i jakimi zegarami taktowane, wpięte w tą magistralę. Co prawda można założyć jakieś parametry, które można łatwo spełnić, ale nie wiem czy choćby budowa sprzętowa uC nie spowoduje problemów typu opóźnienia paru taktów. To jescze do przemyslenia.
Raczej nie chciałbym iloczynu na drucie - zazwyczaj wtedy do plusa podciąga rezystor - na długich kablach musi przeładować takie pojemności, że dużych szybkości nie dam rady uzyskać.
A z jaką predkością ? 9600 to _minimum_. Aż się prosi o 2x-4x więcej ...
Od lat stosuje CAN po RS485 (iloczyn na druce). Szybkosci 125kbps do kilkuset metrow, 25kbps nawet do kilku kilometrow.
peters
Powiedzmy 20-30 urządzeń. Każde po ramce w granicach 50 bajtów (średnio), sporadycznie znacznie więcej - >300.
Całośc ma działać w taki sposób, aby użytkownik wciskając przycisk odczuwał "natychmiastową" reakcję czujnika/serwo itd. Innymi słowy max
50ms na reakcje slave, znacznie lepiej, jeśli da się szybko.Jest jeszcze głupia sprawa - magistrala przez 99.9% czasu jest cicha. I nagle musze rozesłać do 30 slaveów masę informacji praktycznie "natychmiastowo" (w sensie subiektywnego odczucia usera). Tu by się przydało jak najszybciej.
OK :)
Jest jedna sprawa: chciałbym, aby numery były podczas produkcji zaszywane w urządzeniach. A takim przypadku (w jednym segmencie mała pula adresowa) nie mogę ich tam wszyć, bo musiałbym produkować urządzenia w grupach (nie powtarzajace się numerki lub konfigurowalne). Wygląda to tak, jak w protokole IP gdzie nadaje się dodatkowe numerki IP poza MAC żeby grupować stacje.
Oczywiście im mniejszy segment tym większe szanse na znalezienie slave za pomocą protokołu kolizyjnego z sumami kontrolnymi. Ponadto slave może z prawdopodobieństwem 1/32 losować, czy w ogóle się odezwać, zakłądając że zapytania są dość częste czas wykrycia slave będzie sensownie krótki.
Dokładnie tak to sobie wymyśliłem.
PS. Nie napisałem, że nie zalezy mi w ogóle na szybkości znalezienia slave (mogą być sekundy). Istotne jest żeby je znaleźć.
Przepraszam, ze tak na raty odpisuje. Dla CANa nie ma to za bardzo znaczenia. Do CAN-a i tak stosujesz specjalizowane kontrolery (podpiete pod magistrale albo po SPI -chyba takie widzialem) albo uC z CAN. Kontroler zalatwia Ci tyle, ze procesor jest znacznie mniej obciazony niz w przypadku RS485 -moze wiec byc slaby.
peters
robisz tak jak w ethernecie - podsluch na magistrali. Jak inne urzadzenie zaczelo nadawac przed twoim - rezygnujesz, zglosisz sie przy nastepnym odpytaniu.
J.
Cel szczytny, ala po dluzszym zastanowieniu...przeciez urzadzenia musisz jakos identyfikowac, czyli gdzies wprowadzic ich numery. Chyba, ze Ci obojetne czym zasterujesz lub skad pobierzesz pomiary :)
peters
Az sie prosi o zastosowanie CAN-a. Najwazniejszy argument to wlasnie czas przekazywania komunikatow od Slave-a. Jesli masz siec z jednym masterem i stosujesz metode odpytywania
- musisz pytac bardzo czesto. im wiecej urzadzen tym czesciej. I dowiadujesz sie przewaznie, ze nie ma nic do przeslania. CAN te sprawy zalatwia, bo urzadzenie samo zaczyna nadawaie.
Zostaje jeszcze problem z wieksza iloscia urzadzen. Mozesz zaprojektowac proste repeatery, uklady z dwoma CAN-ami. Co zostanie odebrane na jednym CAN-ie za chwile nadawane jest na drugiego.
Numerujac urzadzenia musialbys sie ograniczyc do 29 (lepiej 28) bitow. Ale to i tak ponad 250 milionow urzadzen. Jesli nie musisz rezerwowac puli numerow dla roznych producentow-to spokojnie wystarczy.
peters
Małe ramki w CAN są po to, aby to co ma dojść szybko (alarmy) mogło się wciąć (ma wyższy priorytet) w dowolną inną transmisję danych. P.G.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.