Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Brak komunikacji miernika tablicowego z RS485 Modbus RTU

mateuko 31 Sie 2009 15:32 3579 14
  • #1 31 Sie 2009 15:32
    mateuko
    Poziom 9  

    Mam konwerter USB-RS422/485. Widziany jest jako wirtualny COM3 w systemie. Gdy program wysyła ramkę zapytania, miga dioda Tx w konwerterze, ale brak jest odpowiedzi - dioda Rx nie reaguje. Po podłączeniu oscyloskopu na zaciski Data+ Data- miernika widać ramkę zapytania i po ułamku sekundy ramkę (chyba) odpowiedzi miernika jednak dioda w konwerterze nie miga a terminal pokazuje "Timeout". Na razie mam wszystko na biurku tzn. Konwerter wpięty do USB - skrętka - miernik. Linie Data- miernika mam podciągniętą rezystorem 3,3k do masy (tzn. zacisku COM ) a Data+ do +5V takim samym rezystorem. Zaciski TxD- oraz Rxd- oraz TxD+ i RxD+ układu 4 przew. z konwertera zwarte ze sobą aby otrzymać układ 2 przewodowy, wg tego co narysowano w specyfikacji. Ale nawet po tych zabiegach, odpowiedź nie dochodzi. Zaciski COM miernika i konwertera są połączone. Czy może być walnięty konwerter? Mogę zworkami wymusić aby dostawać w odpowiedzi to co wysłałem i wtedy działa, ale odpowiedź z miernika nie przechodzi...

    pozdrawiam

    0 14
  • #2 31 Sie 2009 20:39
    jestam
    Specjalista Automatyk

    Konwerter jest czteroprzewodowy a miernik dwuprzewodowy?

    Usuń rezystory.

    Zewrzyj w konwerterze TxD+ z RxD+ a TxD- z RxD-. Sprawdź czy w pętli działa. Jeżeli tak, to konwerter powinien być w porządku. Jeśli masz jakiekolwiek inne urządzenie (nawet drugi konwerter) przetestuj konwerter z nim.

    Sprawdź czy nie zamieniłeś sygnałów data+ z data- w mierniku, najprościej zamień i zobacz czy pomogło.

    Sprawdź czy masz poprawnie ustawioną prędkość transmisji i parametry ramki. Jeżeli miernik ma funkcję resetu do ustawień fabrycznych użyj jej.

    Sprawdź czy adres abonenta jaki ma miernik zgadza się z tym z ramki.

    Sprawdź w dokumentacji miernika jakie rozkazy Modbus obsługuje. Czy wysyłasz ramkę która może być rozumiana przez miernik. Może wysyłasz ramkę Modbus RTU a miernik spodziewa się ASCII lub odwrotnie?

    Brak odpowiedzi zwykle wynika z tego, że urządzenie po drugiej stronie nie rozumie otrzymanego rozkazu. Nie zgadzają się ustawienia portów, suma kontrolna, kable są zamienione itp. Wtedy abonent podrzędny musi zachować ciszę na łączu i stąd brak odpowiedzi.

    0
  • #3 01 Wrz 2009 15:02
    mateuko
    Poziom 9  

    Próbowałem powyższego, ale bezskutecznie
    A czy to różnica, że konwerter jest 4w a miernik 2w jeśli zastosuje się opisany wyżej układ połączeń? A może to wina tego wirtualnego COMa pod którym jest widziany ten mój konwerter USB? Może zadziała jeśli wezmę jakiś konwerter RS232/RS485 2w? Ale najbardziej frapuje mnie, że na oscyloskopie podłączonym na zaciski Data+ i Data- miernika są widoczne dwie paczki impulsów jedna po drugiej przy wysłaniu pojedynczej ramki zapytania. Ramkę biorę z instrukcji miernika więc powinna być rozpoznana. Próbowałem też innych rozkazów, ale też kicha. A gdy zmienię nr urządzenia w terminalu tak, że się różni od tego ustawionego w mierniku to tej drugiej paczki impulsów nie ma. Będę musiał chyba kupić inny konwerter - zwykły RS232/485 2w bo już nie mam innych idei co może być przyczyną braku odp.

    pozdrawiam

    0
  • #4 01 Wrz 2009 18:07
    jestam
    Specjalista Automatyk

    Tzn. przetestowałeś sam konwerter i działa w obie strony (w pętli), widzisz dwie ramki ale odpowiedź nie przychodzi? To jest więcej niż dziwne. Pozostaje użyć innego konwertera.

    0
  • #5 02 Wrz 2009 12:19
    kaltron
    Poziom 17  

    Możesz jeszcze spróbować zaterminować początek i koniec skrętki rezystorami 120-150Ω

    0
  • #6 07 Wrz 2009 10:07
    mateuko
    Poziom 9  

    Mam inną przejściówkę USB/RS485 ale dalej nie działa. Mam też odpowiedź producenta przyrządu:

    W odpowiedzi na Pańskie zapytanie informuję, iż do nawiązania komunikacji w formacie Modbus RTU nie nadaje się program windows'owego terminala. Ze względu na ostre wymagania czasowe w formacie ramki musi być stosowane specjalistyczne oprogramowanie zapewniające ten format transmisji ( Modbus RTU). Windows ze względu na swój charakter wielowątkowości może wprowadzać niepożądane  odstępy czasowe pomiędzy bajtami  w  ramce, wysyłanej za pomocą programu terminal. Uwaga: nie należy mylić Modbus RTU z Modbus DP, w którym to można uzyskać komunikację za pomocą terminala. Do komunikacji proponuję zastosować typowe oprogramowania typu SCADA

    Co wy na to? Mogą mieć rację?

    Docelowo miernik ma chodzić pod systemem VEE firmy Agilent Technologies. Może ktoś ma doświadczenie we współpracy VEE - RS485? Jest w ogóle taka współpraca możliwa?

    0
  • #7 07 Wrz 2009 14:18
    SunnyLion
    Poziom 13  

    Niestety mogą mieć rację, polecam żeby liznąć temat modbusa rtu gdzie masz podstawowe założenia:
    * bajty są wysyłane binarnie jako znaki ośmiobitowe
    * każda ramka jest poprzedzona odstępem (cisza na linii)> 3,5T (gdzie T oznacza czas transmisji jednego znaku)
    * odstępy pomiędzy kolejnymi znakami ramki < 1:5T

    Windows nie jest systemem czasu rzeczywistego i do zastosowań przemysłowych nadaje się w niewielu wypadkach.

    0
  • #8 08 Wrz 2009 12:26
    jestam
    Specjalista Automatyk

    mateuko napisał:

    Co wy na to? Mogą mieć rację?


    Kilka postów wyżej pytałem
    Cytat:

    Może wysyłasz ramkę Modbus RTU a miernik spodziewa się ASCII lub odwrotnie?


    Użyj jakiegoś programu obsługującego protokół Modbus RTU. Np. Modbus Tester z www.modbus.pl.

    @SunnyLion
    Cytat:
    Windows nie jest systemem czasu rzeczywistego i do zastosowań przemysłowych nadaje się w niewielu wypadkach.

    Przemysł najwyraźniej o tym nie wie :)

    0
  • #9 08 Wrz 2009 13:13
    SunnyLion
    Poziom 13  

    Windowsa masz co najwyżej w wizualizacjach, beckhoff poszedł trochę dalej i na embedded podmienia drivery sieciówki intela na swoje soft RT i spisuje się to nieźle, sam windows niewiele ma do gadania ;)

    0
  • #10 08 Wrz 2009 14:06
    jestam
    Specjalista Automatyk

    Win CE jest hard real time, jeżeli sprzęt jest odpowiedni. Ale nie o tym.

    Mało kto steruje czymkolwiek bezpośrednio z PC. Ze względu na niezawodność. Więc dość oczywiste że PC+Windows jest używane w wizualiacjach, akwizycji danych, HMI i innych podobnych. PC + Win spokojnie jako system soft real time sobie radzi. O ile programista zna swoją robotę.

    Znam instalacje, gdzie PC steruje bezpośrednio urządzeniami, a aplikacja sterująca jest napisana pod .NET Framework. Pomiary pokazały że czasowo radzi sobie świetnie. Instalacja jest całkowicie bezpieczna w przypadku awarii PC, rozwiązanie przyjęte ze względu na koszty.

    Cytat:

    podmienia drivery sieciówki intela na swoje soft RT i spisuje się to nieźle, sam windows niewiele ma do gadania


    Zobacz na msdn jaka jest architektura sterowników Windows, sterowników sieci i gdzie są "drivery sieciówek" w stosie sterowników. Sam zobaczysz ile Windows ma do gadania. Oczywiście że do systemów embedded może być warto specjalnie zrobić niektóre sterowniki i dobrze napisać soft aplikacyjny. Reszta to zwykły Windows. Działa. ;)

    0
  • #11 09 Wrz 2009 09:32
    SunnyLion
    Poziom 13  

    Kolega ma windowsa xp, nigdzie nie pisałem o CE ;)

    Znam też maszyny które działają pod embedded, soft napisany pod .NET może i działa ok, ale stabilność słaba, niestety nie mogę napisać co to za maszyny ze względu na sprawy zawodowe ;)

    Zobaczę na msdn architekturę, bo faktycznie mogę się mylić ;)

    pozdrawiam

    0
  • #12 09 Wrz 2009 12:02
    jestam
    Specjalista Automatyk

    Też znam maszyny z XP (czy embedded czy nie to w sumie bez różnicy), które działają tak sobie :)

    Da się zrobić dobrze, ale dość jest zrobione tak sobie. Niestety...

    Cytat:
    Zobaczę na msdn architekturę, bo faktycznie mogę się mylić

    [ur]=http://msdn.microsoft.com/en-us/library/aa973521.aspx[/url] i dalej.

    0
  • #13 09 Wrz 2009 12:29
    SunnyLion
    Poziom 13  

    No nie do końca bez różnicy, dobrze zrobiony system embedded daje dosyć sporą stabilność :)
    Mam jeden co chodzi już kilka lat bez zająknięcia, super jest możliwość w przypadku embedded zoptymalizować zapis tak że praktycznie nic się w systemie nie zmienia bo nie ma prawa :) zapomniałem tylko nazwy modułu, jak raz się dobrze zrobi to tylko licencje trzeba wpisywać przy kompilacji ;)

    0
  • #14 09 Wrz 2009 13:01
    jestam
    Specjalista Automatyk

    Tu masz rację, system embedded jest testowany jako całość i nikt tam gier nie instaluje ;) Ale sam Windows XP to właściwie to samo co XP embedded, minus parę nieistotnych dodatków :)

    0
  • #15 14 Wrz 2009 13:12
    mateuko
    Poziom 9  

    Udało się w końcu skomunikować z miernikiem 30-dniową wersją programu Modbus Poll. Z VEE też w końcu udało się skomunikować z miernikiem, po skorzystaniu z podpowiedzi, że ramka ma być wysyłana 8 bitowymi bajtami. Zmieniłem typ wysyłanych danych na BINARY i podtyp na BYTE i teraz po wysłaniu zapytania jest odpowiedź, którą odczytuję przez zmienną tablicową ARRAY 1D, której elementy są typu BYTE.

    Dzięki za podpowiedzi, koniec tematu.

    0