kłopot z MODBUSem

Jul 23, 2008 29 Replies

Witam.



W zasadzie muszę trochę ponarzekać...



Mam w ręku dwa urządzenia: ARDETEM PECA15 i LUMEL N12. Obydwa to mierniki mocy (panelowe) z komunikacją. PECA potrafi RS232/485, LUMEL tylko 485.



PECE i jej problemy znam dobrze - używam od jakiś 3 lat. Lumel pojawił się niedawno.



Obydwa pomykają w protokole MODBUS.



Prękości małe - 9600. Odległość między urządzeniem a moim układem komunikacyjnym nie większa niż kilkanaście (!) cm. Na wyjściu mojego układu siedzi sobie 75176. A i B podciągnięte gdzie trzeba. Całością steruje mój dedykowany mikrokontroler. To co z niego wyskakuje jest krystalicznie czyste (nie ma żadnych zakłóceń, inny przetwornik firmowy łyka dane bez pomyłek na wiele tysięcy wysłanych bajtów). Stablizacja kwarcem. Ogólnie komunikacja na RS485 jest wzorowa nawet po oglądnięciu oscyloskopem. Timeouty na transmisję RTU z dokładnością do milisekund, ale ustawione znacznie powyżej tych z dokumentacji.



No ale zawsze jest jakieś ale.



Obydwa urządzenia mają wrodzoną wadę olewania moich zapytań. Konkretnie coś wysyłam a tam cisza. Wysyłam ponownie - cisza. Wysyłam 3 raz - łaskawie odpowiada - ze złym CRC. Wysyłam ponownie - odpowiada z dobrym CRC. Sytuacja obserwowana w przypadku jednego i drugiego urządzenia przy czym lumel ignoruje mnie znacznie częściej. Efekty są całkiem randomiczne i kosmiczne włącznie z oddawaniem mi ramki informującej o N bajtach danych ... bez danych ale z prawidłowym crc. Za chwile to samo zapytanie produkuje poprawną ramkę z danymi.



W zasadzie mógłbym powiedzieć - mam zapewne coś nie tak sprzetowo z 485. Tylko że na RS232 PECA zachowuje się identycznie - ignorująć niektóre zapytania bądź odsyłając głupoty. W akcie desperacji podłaczyłem w prost do komputera i objawy podobne - nie każde zapytanie kończy się odpowiedzią a niektóre kończą się błednym CRC lub całkowitą bzdurą w budowie ramki.



W zasadzie mam podstawowe pytanie:



Czy niektóre urządzenia przemysłowe z magistralą RS485 zachowują się w taki sposób i jest to spotykane zachowanie? Nie chce popadać w paranoje (2 przykłady to za mało aby ocenić statystycznie) ale mam nieodparte wrażenie że komunikacja nie jest testowana i projektowana pod kątem odpowiadania na każde zapytanie (zakładając pomiar raz na godzinę zawsze można ramkę powtórzyć). Ja muszę czytać "co sekundę" i troche mnie boli takie olewanie.



PS. Mam tu trzeci czujnik z MODBUS i 485. Nie znam firmy ani typu (brak oznaczeń). Na szczęscie znam jego adres i parametry. Odpowiada _zawsze_ i _zawsze_ prawidłowo (na tej samej magistrali). Nie wiem czy to świadczy o jego lepszym wykonaniu czy moim pechu...


Użytkownik "Sebastian Bialy" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:g68bo2$a6c$ snipped-for-privacy@nemesis.news.neostrada.pl...

witam. z 75176 to mialem przypadek ze gdy napiecie go zasilajace spadalo troszeczke ponize 5V bzdury mi odbieral, ale to odbieral, a nie nadawal - ogolnie to jest tani - i pewnie stosunek cena/jakosc ma rewelacyjny sama jakosc taka sobie. Generalnie panuje troszke balagan, rozni producenci pisza za maja implementacje modbusa, a w rzeczywistosci jest to cos do modbusa podobnego, (bo na przyklad dane sa inaczej ulozone) albo czegos tam w ramce nie ma - lub jest cos ekstra - albo czekac wlasnei na odpowiedz nalezy nie wiadomo ile Moze tutaj masz cos w nich siadniete , moze zly kontakt , moze driver oberwal... takie sa moje odczucia... Michal m.

Sebastian Bialy pisze:

Miałem do czynienia z licznikiem Lumela - zero problemów. Sprawdż sobie oba urządzenia programem testującym z

formatting link
Podsłuchaj transmisję a potem zrób to samo z twoim kontrolerem. Może za późno przełączasz u siebie z nadawania na odbiór albo są za krótkie przerwy między znakami w transmisji.

A masa podłączona? Nic o niej nie wspominasz, może to oczywiste, ale w fizycznej warstwie

485 jest jeszcze masa. K.

Mam inną zrobioną magistralę moich urządzeń z moim protokołoem na 75176. Działa wyśmienicie i nie ma potrzeby stosowania czegoś lepszego. Prędkości znacznie większe niż 9600 a mimo to znalezienie błędu transmisji jest prawie niemożliwe. Środowisko mocno zakłucone "przemysłowym" otoczeniem. I działa.

Ile - określa dokumentacja. Swoją drogą urwał bym łeb przy samej d... za czas odpowiedzi rzędu 300ms...

Działają w kilkanascie sztuk na magistrali @57600 i nie dyskutują.

Będę szukał, ale błąd montażowy określam jako = 0. Podpięty fabryczny konwerter odcztuje bez błędów.

OK.

Nie ma sensu. Wysyłam prawidłowe ramki - za którymś razem urządzenie ją zauważa.

Czas przełączenia trwa pare cykli zegarowych CPU za ostatnim znakiem. Można powiedzieć, że nie można szybciej....

Przerwy określa producent. Jesli pisze mi 8n1 to oznacza 1 bit stopu i potem moze nastapić nowy znak (i u mnie następuje). Jeśli okazało by się, że to za mała przerwa to chyba trzeba rozstrzelać kogoś od firmware.

Nie jest. Masa jest czasami potrzeba żeby wyrównać potencjał "w niektórych przypadkach". U mnie nie płynie pomiędzy GND urządzeń nawet głupi 1mA.

Użytkownik "Sebastian Bialy" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:g6aa7t$f0a$ snipped-for-privacy@nemesis.news.neostrada.pl...

I może to jest problem ? Po co zwalniać tak szybko magistralę ? Zastanawiałeś się, jaki stan magistrala przyjmuje, gdy ją zwalniasz i co na to odbiorniki ?

e.

Zostawiam ją w stanie "1". Mam rezystory które utrzymują ten stan kiedy "wszyscy są na nasłuchu". Innymi słowy pomiędzy kończącym bitem stopu (1) a ciszą na lini nie ma obserowalnych zjawisk elektrycznych na lini. Odbiornik ma pełen komfort rozpocząć odpowiedź kiedy chce.

Użytkownik "Sebastian Bialy" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:g6ago2$n7d$ snipped-for-privacy@nemesis.news.neostrada.pl...

zakładając, że Twoja transmisja jest tak jak powinna być 11-bitowa (tzn 2 bity stopu lub parzystość), przychodzi mi do głowy tylko jedna rzecz: brak choćby minimalnych odstępów między poszczególnymi wysyłanymi bajtami i ew. równolegle jakiś błąd w procedurach odbiorczych.

e.

Skoro jesteś tego pewny... K.

A do czego miały by te odstępy być ? Przecież od tego jest bit(y) stopu żeby oddzielić bajty ... Jeśli potrzebne są dodatkowe odstępy to wyglądało by to na ewidentny błąd firmware.

Procedury odbiorcze są sprzętowe (UART).

Ja nie. Producent tak.

Użytkownik "Sebastian Bialy" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:g6aivt$i19$ snipped-for-privacy@atlantis.news.neostrada.pl...

na to stawiam właśnie gdzieś już taki błąd spotkałem

nie znaczy, że coś nie jest skopane, choć szansa minimalna. Testowo możesz pogonić ten UART lekko zmienionym zegarem.

e.

Użytkownik "Sebastian Bialy" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:g6aj0j$i19$ snipped-for-privacy@atlantis.news.neostrada.pl...

Sęk w tym, że 75176 dostaje p...ca gdy ma coś nie tak z masą, w ogóle te "dolne" klucze są w nim jakieś problematyczne...

e.

Wygląda to na błąd w firmware. Ze swojej strony polecam rejestratory Twelve Electric z serii AS-3. U mnie działały z maksymalną szybkością na przysłowiowym kablu od żelazka razem z ST485+uC.

Użytkownik "DMA" snipped-for-privacy@uymail.com napisał w wiadomości news:g6akfg$27n$ snipped-for-privacy@achot.icm.edu.pl...

raczej na dwa wzajemnie się znoszące błędy, bo z czymś to działało...

e.

Już ganiałem po 5% w każdą stronę. Działa najlepiej na nominalnej.

Nie miałem z nim negatywnych do tej pory doświadczeń. Natomiast testowo spróbuje ta masę doprowadzić. Jednak dalej otwarty jest temat, że podobne objawy (jeśli nie identyczne) dostaje przy RS232.

Jaki jest czas odpowiedzi? Iteresują mnie dziesiątki ms a nie setki. Potrzebuje U,I,f,cosfi na jednej fazie.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required