Jak zrealizować wskaźnik zajętości linii RS-485 na kablu UTP?

witam.

Temat poruszany wielokrotnie, ale odpowiedzi na moj pomysl nie znalazlem.
A mianowicie, planuje wykorzystac RS-485, ktory jak wiadomo nie ma sprawdzania stanu
magistrali itp.Ja chcialbym na RS485 zrobic komunikacje Multi Master, czyli
w razie potrzeby kazde urzadzenie rozmawia z kazdym.

I teraz fizycznie magistrala bedzie na kablu UTP, czyli mamy 4 pary.

I 1 para to RS 485
2 para to zasilanie do urzadzen.

No i mam 4 przewody "wolne".

I wlasnie wymyslilem zeby jeden lub dwa przewody wykorzystac jako wskaznik zajetosci linii.
de fact zalozmy ze stan logiczny 0 - linia wolna, 1 - linia zajeta.

Co Wy sadzicie o takim pomysle ?

Myslalem jeszcze nad CAN-em, ale w sumie po co miec dodatkowy kontroler ,
w takiej konfiguracji RS 485 powinien sie sprawdzic.

Pozdr
AK

p.s. przekopiowalem post z forum DSP i transmisja, bo wydaje mi sie
ze tutaj szybciej cos ustalimy

Myślę, że powinieneś zgłębić temat arbitrażu na I2C i na tej podstawie napisać oprogramowanie na uP, bo problemem jest glównie rozpoczęcie nadawania przez dwóch master-ów dokładnie w tym samym momencie i arbitraż między nimi...

Nie napisałeś o ilu masterach myślisz? To jest ważne czy będą 2 czy będzie 20.

Myślę, że możesz rozważyć technikę przekazywania tokena ( token = zezwolenie na nadawanie). Poszukaj na forum.

dzieki.

poszukam o tokenie, wlasnie u mnie cos takiego to bylaby ta wolna linia,
jesli 0 mozesz nadawac, jesli 1 to czekaj.

A ogolnie zalozenie jest takie, ze masterem moze byc kazdy.

Pozdrawiam
AK

problemem może być to, że jeśli dwa układy naraz wysterują "linię zajętości" na zajętą, to oba się o tym nie dowiedzą i nastąpi kolizja przy transmisji. Czasem samo pojęcie mastera można lekko nagiąć - np wpiąć dodatkowy układ bus-master, który to by kontrolował przydział magistrali - "master" chce nadać komunikat, więc wysyła zapowiedź [np ze swoim adresem] na szynę - jeśli busmaster odbierze poprawnie cały pakiet, to przydziela slot masterowi, jeśli nieodbierze (kolizja), to nie przydziela nikomu łącza. Kolejny pomysł to już wspomniane przekazywanie tokena, trzeba wtedy jednak zaimplementować trochę funkcji jak odzyskiwanie tokenu etc.. Inny pomysł, to zrealizować coś na zasanie bramki and-na-linii(na czas arbitrażu) - spolaryzować szynę za pomocą 2 oporników tak, żeby po wyłączeniu wszystkich nadajników utrzymywał się np stan wysoki(na wyjściach odbiorników), początek transmisji ramki polegał by na wysłaniu swojego adresu (0->wymuszenie stanu niskiego; 1->zwolnienie linii) - jeśli nie było by żadnych przekłamań przy transmisji (kontrola stanu linii - adres się zgadza - przy nadawaniu 1 jeśli na linii pojawił by się stan zero, to układ przerywa transmisję), to układ traktuje to jako przyzwolenie na nadawanie. Trzeba by to rozpatrzeć pod kątem możliwych dróg kolizji, ale raczej jedyną będzie czas propagacji sygnału - przy wysyłaniu adresu jeden bit powinien trwać tyle, żeby dotarł do każdego zakamarka sieci zanim zostanie wysłany kolejny. Dodatkowo do tego mechanizmu, jeśli układ odpadł, to obiera sobie np jeden z 32 slotów czasowych, i w nim ponawia transmisję (jeden slot trwał by więcej, niż potrzeba na nadanie całej ramki)

Dzieki za odpowiedz.

Ja myslalem nad takim schematem dzialania, ze kazdy uC przed proba nadawania sprawdza
stan linii, i jesli jest 0 to ustawia 1 i nadaje, konczy nadawanie ustawia 0.

Nie wiem , moze cos pominalem, jakis przypadek ale to calkowicie wyklucza kolizje.
Ew gdyby byly jakies przeklamania na linii albo cos...

Ale mozna zrobic ze sprawdza 2 razy w odstepie czasu np 0.1s I jak 2 razy byla wolna to wtedy
dopiero nadaje.

Wykorzystujac dodatkowa zyle ktora mam i tak w skretce, uproscilbym sobie i arbitraz i
nie musial przenosic sprzetowych rozwiazan na strone programowa.

Pozdr
AK

Ja zawsze myśle modelem najgorszym w najgorszych warunkach - przypuśćmy, że oba układy sprawdzają linię dokładnie równocześnie - oba widzą stan zero, więc oba wystawiają jedynkę - jeśli czas propagacji jest duży, to nie musi to być aż tak do końca równocześnie - ale podczas gdy jeden układ wymusi jedynkę, to drugi ma na wejściu jeszcze zero, albo już sprawdził stan linii (==0) i wykonuje kilka instrukcji żeby dojść do wystawienia jedynki, albo w tym samym momencie też zaczyna wymuszać jedynkę - tak czy inaczej metoda nie jest w 100% pewna, a biorąc pod uwagę niezerowy czas propagacji przez szynę, to prawdopodobieństwo rośnie... może łatwiej było by zrobić najzwyczajniej transmisję w ciemno po szynie rs485 (nawet z kolizjami) i wpakować w to mechanizm retransmisji z potwierdzeniami - pakiet nie doszedł - retransmisja - pakiet doszedł, odrazu za nim wcisnąć potwierdzenie.

hmm,
to fakt ze moze sie zdazyc raz na milion ze tak bedzie.

Wiec zaproponuje cos takiego.

Sprawdzenie linii dwukrotne,
pierwszy raz i drugi raz za 100ms +- losowo od 0 do 30ms.

Dodatkowo kumunikat postaci:
(S - bit/bajt startu stopu)

S:ID:NAD:ODB:DANE:S

po odebraniu komunikatu wysylamy potwierdzenie.

S:ID:NAD:ODB:OK:S.

Brak potwierdzenia, retransmisja za 0.5 lub 1s.

Chyba teraz byloby w miare prosto sprzetowo i niezbyt duzo programowo.

Pozdrawiam
AK

kwiatek6324 napisał:

Sprawdzenie linii dwukrotne,
pierwszy raz i drugi raz za 100ms +- losowo od 0 do 30ms.

To nic nie zmienia - chodzi głównie o równoczesne ostatnie próbkowanie - w przypadku kolizji sytuacja wyglądała by tak: ostatnie próbkowanie było by równocześnie, ale względem poprzedniego było by oddalone o te 100ms +- losowe 30ms - jak widać, nie tędy droga (wystarczyło by pojedyncze próbkowanie)... te czasy retransmisji wydają mi się lekko za duże - ja bym oscylował przy 5-10ms a nie 0.5-1s.. Ostatecznie godząc się na kolizje (z podanych przez ciebie czasów wynika, że nie jest to system krytyczny czasowo) można zrezygnować z dodatkowej linii. Transmisja wyglądała by tak: sprawdzaj przez 2ms czy nie są przesyłane żadne dane. Jeśli nie są - zacznij nadawanie, jeśli są - obierz jeden z iluś tam slotów czasowych w którym ponów sprawdzanie linii. Taka metoda transmisji zmniejszała by prawdopodobieństwo kolizji w warunkach rzeczywistych, ale nie eliminowała by kolizji - w ostateczności biorąc pod uwagę możliwe błędy transmisji i tak powinien być mechanizm retransmisji, więc to chyba była by najlepsze i najprostrze rozwiązanie - transmisja po 2ms ciszy na szynie, jeśli brak ciszy to obieranie kolejnego slotu do ponownienia funkcji nadawania + mechanizm retransmisji.

Fakt,

o tym nie pomyslalem.

A mam jeszcze jedno pytanko bo jesli nic nie pomylilem
to gdzies wyczytalem, ze przy probie nadawania wiecej niz jednego
urzadzenia odbiorniki linii moga sie przepalac ze wzgledu na
za duze roznice potencjalow ??

Bajka to ? czy moze tak byc ?

W sumie mozna zrobic tak, ze pojedyncze sprawdzanie zajetosci linii
na dodatkowym przewodzie (wytnie jakies 95% przypadkow) .
A na te 5% dopisze potwierdzenie odbioru i retransmisje.

Powinno dac rade ??

Pozdrawiam
AK

kwiatek6324 napisał:

(...)ze przy probie nadawania wiecej niz jednego
urzadzenia odbiorniki linii moga sie przepalac ze wzgledu na
za duze roznice potencjalow ??

Można by to uznać za prawdę, ale raczej chodzi o zabezpieczanie na wyrost.. W praktyce specyfikacja rs-485 wymusza, aby nadajnik (transceiver) był zabezpieczony przed kolizją - jednoczesne nadawanie przez więcej niż jeden nadajnik nie może uszkodzić nadajnika bez względu na stan jego wyjścia. Ostatecznie zawsze można wpiąć pomiędzy transceiver a szynę oporniki ograniczające prąd (np 15Ohm).

kwiatek6324 napisał:

W sumie mozna zrobic tak, ze pojedyncze sprawdzanie zajetosci linii
na dodatkowym przewodzie (wytnie jakies 95% przypadkow) .
A na te 5% dopisze potwierdzenie odbioru i retransmisje.

Rozwiązanie "może być".. aczkolwiek ta linia do wskazywania zajętości może być kłopotliwa: asymetryczna może siać zakłuceniami i być niebezpieczna dla mikrokontrolerów, symetryczna będzie wymagać dodatkowych transceiverów.. dlatego polecał bym rozwiązanie z pojedynczą szyną - sprawdzanie, czy przez np 2ms jest cisza na łączu można rozwiązać w bajeczny sposób sprzętowo wykorzystując mechanizm z przerwań, a jeśli sam format wymienianych danych będzie zgodny z tym w rs232, to stosując uart + jedno przerwanie wyzwalane zboczem (bez wywoływania f.przerwania) można warstwę fizyczną rozwiązać w dużej mierze sprzętowo.

Taka metoda była by tańsza (po jednym transceiverze), prostrza(jedna para przewodów danych), bezpieczniejsza(kontroler za transceiverem), i zabezpieczała by przed kolizjami przynajmniej tak samo, jak z dodatkową linią..

wlasciwie to zaklocen sie boje najbardziej.
Zastanawiam sie jak rozwaizac zasilanie,
bo myslalem puscic obok magistralii.

Ale jesli te zaklocenia mialyby byc az takie duze
to moze puscic kolejna pare luzem ?

Chcociaz raczej na zasilanie nie powinny miec wplywu,


Pozdr
AK

Zasilanie może najlepiej stosować tak jak w Power-on-Ethernet - jedna para jako minus, druga jako plus - napięcie może nie w takich samych zakresach (40V czy ile to tam jest), ale może coś koło 9V - na wejściu układu kondy filtrujące + stabilizator. Potencjał pomiędzy masami układów nie był by co prawda równy zero (przy obciążeniu lub zakłóceniach), ale specyfikacja rs485 narzuca też, aby transceivery pracowały z napięciem wspólnym na wejściu od -7V do 12V, więc pomimo różnicy potencjałów mas transmisja powinna zachodzić bez problemów (różnice potencjałów mas były by niebezpieczne przy asymetrycznej linii "zajęcia")

Zawsze możesz zastosować mechanizm jak w CAN.
Nadajesz ramkę, ale jednocześnie ją odbierasz (w transceiverze RS-485 włączasz jednocześnie nadajnik i odbiornik). Jeżeli odebrałeś to samo co nadałeś, to OK, jeżeli nie to kolizja i po losowo wybranym czasie retransmitujesz...
To będzie grało gdy transmisji nie będzie zbyt wiele. Przy dużym obciążeniu linii transmisyjnej, będą niemal same kolizje.

Witaj,
Jest to wyjscie, aczkolwiek...

Coz, w ukladzie raczej komunikacji bedzie nie za duzo,
uklad proponowany to automatyka w domu,
ale moze sie zdarzyc ze bedzie w danej chwili sporo
komunikatow i kolizji najlepiej jakby bylo jak najmniej.

Zasilanie jak w POE to jest niezly pomysl i pewnie go zastosuje.

Poniewaz niektore komunikaty beda wazne.
To moze zrobic tak protokol wygladalby tak

1. sprawdzam czy przez 2ms jest wolne, jesli tak to dalej
2. wysylam dane, na koncu ich suma kontrolna
3. odbiorca weryfikuje jesli jest ok, to odsyla potwierdzenie tez z suma kontrolna.
4. nadawca odbiera potwierdzenie i usuwa komunikat z kolejki.

Zakladajac ze dzialaloby to na 19200, komunikat mialby 12 bajtow + bity Start/Stopu tj
120 bitow.
Wyslanie takiego komunikatu zajeloby ok 6ms ze zwrotnym lacznie ok 12ms.

Doliczajac narzuty itp niech komunikat zajmuje z potwierdzeniem 16ms, na sekunde
moge przeslac 62 komunikaty.

Wyglada ze wydajnosc jest calkiem spora,

przy 57600 tych komunikatow moze byc ok 250.

Wiec jest chyba ok..

Pozdr
AK