Pewien kłopot z MODBUSem

Thu Jul 24, 2008 8:23 pm   

Użytkownik "DMA" <storm32WYTNIJTO@uymail.com> napisał w wiadomości
news:g6akfg$27n$1@achot.icm.edu.pl...


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

e.

Thu Jul 24, 2008 9:57 pm   

entroper wrote:

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

Thu Jul 24, 2008 9:58 pm   

entroper wrote:

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.

Thu Jul 24, 2008 9:59 pm   

DMA wrote:

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

Thu Jul 24, 2008 11:18 pm   

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.

Fri Jul 25, 2008 7:40 am   

M M wrote:

Jest praktycznie nówka z pudełka, nie pracowal jeszcze pod obciazeniem.
Ponadto PECA zachowuje się podobnie a mialem tych PECA 4 sztuki .

Fri Jul 25, 2008 7:48 am   

John Smith wrote:

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.

Sun Jul 27, 2008 8:09 pm   

Sebastian Bialy wrote:

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?

--
Jerry1111

Fri Aug 01, 2008 11:07 am   

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

Fri Aug 01, 2008 3:18 pm   

Jerry1111 wrote:

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.

Fri Aug 01, 2008 3:22 pm   

Quebec wrote:

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.

Sat Aug 02, 2008 1:34 pm   

Sebastian Bialy wrote:

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 ;-)



--
Jerry1111

Sat Aug 02, 2008 7:16 pm   

Sebastian Bialy pisze:


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: http://www.modbus.pl/

A napisz jeszcze jakiego konwertera RS-232/RS-485 używasz ?
Czy sterujesz przepływem danych, czy konwerter sam to załatwia ?

Pozdrawiam.
Quebec