W żadnym wypadku nie twierdzę, że brak masy to rozwiązanie Twojego problemu. Na seminarium TI o transmisji danych, prelegent wyrażnie zwracał uwagę iż jest to częsty błąd. Popełniany jest dlatego, że na schematach ideowych zwykle masy się nie rysuje. Do dobrej praktyki inżynierskiej należy wyeliminowanie tzw. "głupich błędów" zwłaszcza, że jest to proste do wykonania.
Ciekaw jestem wyników, co jest przyczyną takiego zachowania mierników. K.
mialem na mysli blad/uszkodzenie w mierniku lumela (nie w twoim hardware) - moze oberwal cos kiedys i jego driver jest "nie do konca sprawny" - sie czasem zdarza - pierwsza lepsza burza wystarczy i juz nie jest tak jak dawniej. Michal m.
Jest praktycznie nówka z pudełka, nie pracowal jeszcze pod obciazeniem. Ponadto PECA zachowuje się podobnie a mialem tych PECA 4 sztuki :).
Nie zgodzę się, GND w RS485 jest zbędne (teoria i prawie praktyka).
Na poparcie mam cytat z dokumentacji LUMELa:
"Linia GND służy do dodatkowego zabezpieczenia lini interfejsu przy długich połączeniach. Należy ją podłączyć do zacisku ochronnego (nie jest to konieczne dla prawidłowej pracy inerfejsu)."
Dodatkowo schemat nie pokazuje GND w ogóle, tylko A i B.
Moje doświadczenia to potwierdzają, tzn zarówna urządzenia własnej produkcji (75176) jak i inne (niemodbusowe z 485) funkcjonuja poprawnie bez GND. Kłopot sprawiają mi tylko te dwa mierniki.
W tym przypadku jest proste bo mam niedaleko. W przypadku przemysłowym puszczanie 3 żyły dla GND może być bardzo kłopotliwe.
Ja też :)
Swoją drogą PECA ma ciekawe objawy - kiedy w okolicy "pstryka" jakieś duże obciążenie indukcyjne to komunikacja na 100% zanika na ok. 2 sek. Zarówno 485 jak i 232. Oprócz tego zanika również "co jakiś czas" spontanicznie.
Tyle ta dokumentacja warta. Na dlugich przewodach bez masy z reguly nie dziala. Nie zapomnij jeszcze ze chcesz mase miec grubszym kablem niz sygnalowe. Nie znam CMRR w 75176, ale MAX485 ma AFAIR tylko 2V. Dostaniesz gdzies jakies szpilki i 'po ptokach' - nie ma bitu.
A ustrojstwa nie resetuja sie? To moze lapie 'lewy' bit startu i potem software durnieje czekajac na reszte ramki? Nie dziala tak samo jak mu
0xff wyslesz?Witam. Sprawdź ustawienia transmisji (8N1, 8N2, 8E1 itp) w analizatorze LUMEL.
Korzystam z takich analizatorów (N12 i P12) i działają wyśmienicie , nawet przy maksymalnych prędkościach (magistrala o długości ponad 400m).
Przy odczytywaniu wszystkich rejestrów obieg ramki nie przekraczał 300 ms.
Pozdrawiam. Quebec
U mnie jest kilkanascie cm o czym już pisałem.
Nie ma szpilek. Przynajmniej na oscy w okolicy 20MHz pasma nie ma nic niepokojącego poza naturalnym falowaniem zboczy.
Trudno zgadywac co się dzieje, dokumentacja średnio precyzyjnie wypowiada się o timeoutach _odbierania_ danych. Ponadto jesli łapie "lewy" bit startu to musi być coś fatalnie spieprzone hardwareowo, bo w akcie desperacji przestałem wyłączać magistralę na odbiór podczas ciszy i dalej to samo :/
W dodatku na RS232 jest podobnie, a tam lini nadającej z kompa nikt przecież nie uwalnia tylko wystawia silną jedynkę w czasie ciszy.
Sprawdzę. Tylko to jest rękodzieło.
Wszystko sprawdzone. Ponieważ do komunikacji korzystam z UARTa z AtMega8 to mam spore możliwości kontroli ramki. Nadaje oczywiście 8N2 i RTU. Swoją drogą 8N1 nie działa, ciekawe czy software nie jest na "styk" pisane że głupi brak dodatkowego bitu na 9600 powoduje że nie zdąży obrobić bajtu. W każdym razie 8N2 jest nieco upierdliwe bo dodatkowo zmniejsza prędkość transmisji.
Nie masz skaszanionych ramek które trzeba ponowić? Zawsze działa? Uzywasz jakiegoś LabView do komunikacji czy samodzielnie?
Owszem, ale w rejestratorach piszą np. o maksymalnym czasie rzędu 300ms więc nie mogę _oficjalnie_ spodziewać się wcześniej.
Moga byc - jak masa nie polaczona to po prostu szpilek nie zobaczysz. No bo jak? Jak podlaczysz sie oscylem do jednego ukladu, to go uzemisz (przez mase oscyla). Wtedy w tym ukladzie beda prawwidlowe sygnaly. To samo z drugim ukladem. Mozesz jeszcze sprawdzic podlaczajac mase oscyla do jednego urzadzenia i mierzyc mase drugiego (powinna byc ladna i stabilna masa - nie powinna reagowac na dotykanie palcem itp).
Plywajaca masa - przy zlej konstrukcji az sie prosi ;-)
Sebastian Bialy pisze:
Soft pisany w .NET C# jak również wcześniejsze wersje w VC++.
Nie ma problemów z powtórzeniami, timeout-ami itp. Jedyny problem, który zauważyłem (ale było to kilka lat temu, może teraz już LUMEL to poprawił) to analizator błędnie wyliczał energię czynną.
Możesz też sprawdzić komunikację z analizatorem przy pomocy programu umieszczonego na stronie:
Pozdrawiam. Quebec
Have something to add? Share your thoughts — no account required.
Ask the community — no account required