Pokrewne
menu      Zmiana architektury z x86 na x86_64
menu      Problem z wejście na forum i takie komunikat: Warning...
menu      kilka serwerow w ovh, komunikacja miedzy nimi
menu      Dziwny komunikat [błąd: Invalid default value for 'id']
menu      Niestety ale trzeba wydać forsę na komunię ;-). Co kupić?
menu      Bląd bazy MySQL zwrócił komunikat
menu      Moja stronka - komunikatory.ovh.org
menu      Komunikacja FAXowa z uzyciem niefaxowego modemu
menu      Festo FC640 i komunikacja po TCP/IP
menu      Komunikacja wykorzystujac siec elektryczna 220V
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • kamax.opx.pl
  • Komunikacja po RS232 i TComPort 2.64





    roxy - 08-02-2007 20:45
    Komunikacja po RS232 i TComPort 2.64
      Witam Szanownych Czytelnikow.
    Mam pewien problem z komponentem do obslugi portow szeregowych COM. Program
    napisany jest w C++ Builder 5.
    Aplikacja komunikuje sie z urzadzeniem ktore na zapytanie odpowiada
    okreslona ramka.
    Odpowiedz otrzymuje max po 600ms od wyslania ramki z zapytaniem ( plus
    dodatkowo czas potrzebny na transmisje ramki okolo 320ms( transmisja: 19200
    8N1 - spodziewam sie odebrac 611 bajtow stad te dodatkowe 320ms).
    Cały problem w tym że po upływie jednej sekundy i odczytaniu ramki z bufora
    odbiorczego funkcja ComPort1->ReadStr(ramka,rozmiar_bufora);
    w zmiennej "ramka" znajduje sie tylko czesc odebranych danych. Brakująca
    czesc znakow znajduje sie jak podejrzewam w jakim dodatkowym buforze
    poniewaz po uplywie kilkuset milisekund i ponownym odczytaniu odbieram
    pozostala czesc brakujacych danych.
    Uzywalem funkcji Win Api FlushFileBuffers aby oproznic bufor:

    FlushFileBuffers((void*)(ComPort1->Handle));

    ale to niestety nic nie pomoglo.
    Jezeli ktos ma jakies sugestie bardzo chetnie wyslucham.
    Dziekuje za wszelka pomoc;





    neuron - 08-02-2007 22:45

     
    Użytkownik "roxy" <kicak@o2.pl> napisał w wiadomości
    news:eqfuc8$afd$1@news.onet.pl...
    > Witam Szanownych Czytelnikow.
    > Mam pewien problem z komponentem do obslugi portow szeregowych COM.
    > Program napisany jest w C++ Builder 5.
    > Aplikacja komunikuje sie z urzadzeniem ktore na zapytanie odpowiada
    > okreslona ramka.
    > Odpowiedz otrzymuje max po 600ms od wyslania ramki z zapytaniem ( plus
    > dodatkowo czas potrzebny na transmisje ramki okolo 320ms( transmisja:
    > 19200 8N1 - spodziewam sie odebrac 611 bajtow stad te dodatkowe 320ms).
    > Cały problem w tym że po upływie jednej sekundy i odczytaniu ramki z
    > bufora odbiorczego funkcja ComPort1->ReadStr(ramka,rozmiar_bufora);
    > w zmiennej "ramka" znajduje sie tylko czesc odebranych danych. Brakująca
    > czesc znakow znajduje sie jak podejrzewam w jakim dodatkowym buforze
    > poniewaz po uplywie kilkuset milisekund i ponownym odczytaniu odbieram
    > pozostala czesc brakujacych danych.
    > Uzywalem funkcji Win Api FlushFileBuffers aby oproznic bufor:
    >
    > FlushFileBuffers((void*)(ComPort1->Handle));
    >
    > ale to niestety nic nie pomoglo.
    > Jezeli ktos ma jakies sugestie bardzo chetnie wyslucham.
    > Dziekuje za wszelka pomoc;

    W zdarzeniu
    procedure TForm1.ComPort1RxChar(Sender: TObject; Count: Integer);
    var z:string;
    i:integer;
    begin
    z:='';
    comport1.Readstr(z,count);
    for i:=0 to count-1 do
    begin
    inbuff[ls]:=w; // odebrany bajt do tablicy
    inc(ls);
    if ls= 611 then begin
    ls:=0;
    ustawienie inforaacji o kompletnej
    ramce etc
    end;
    end;
    end;

    To jest mniej wiecej tak ze sysemowy sterownik odebiera jakas porcje danych
    i ja buforuje generujac jednoczesnie komunikaty do aplikacji
    ze cos jest w buforze UARTu wysylajac to cos i ilosc bajow tego czegos.
    Potem kasuje bufor i znowu cos tam zbiera i znowu to wysyla jesli aplikacja
    odebrala to co wyslal poprzednio. I tak w kolko puki jest cos do odebrania.
    W idealnych warunkach powinien to byc w zasadzie jeden bajt ale jak system
    jest zajety to idzie srednio po kilka bajtow.
    dlatego powinienes stosowac funkcje ReadStr w zdarzeniu onRxChar starajac
    sie na bierzaco odebierac wysylane bajty inaczej nigdy nie wiesz ile czego
    jest w buforze. Co prawda TcomPort ma zaimplementowane rozne rozwiazania do
    kompletowania bufora ale nigdy ich nie analizowalem ani nie stosowalem. Ten
    sposob odczytu ktory podalem stosuje od lat i nie mam zadnych problemow (mam
    jeszcze identyfikacje bajtow startowych i kasowanie indeksu LS jesli
    konstrukcja ramki sie nie zgadza i przepisywanie kompletnego buforu z inbuff
    do buff po odebraniu okreslonej ilosci znakow.
    Mysle ze bez problemu przetlumaczysz sobie przyklad z pascala na C

    podrawiam
    wojtek
    www.neuron.com.pl
    CMMS Maszyna
    Golem OEE
    Produkt - Baza Wiedzy




    markofes - 09-02-2007 01:46

     
    > w zmiennej "ramka" znajduje sie tylko czesc odebranych danych. Brakująca
    > czesc znakow znajduje sie jak podejrzewam w jakim dodatkowym buforze
    > poniewaz po uplywie kilkuset milisekund i ponownym odczytaniu odbieram
    > pozostala czesc brakujacych danych.
    >.......
    Sprawdz jak masz ustawione Buffe -> InputSize i ew. zwiększ jego rozmiar
    (prawdopodobnie masz ustawione: 512 ).

    Mk.




    roxy - 09-02-2007 07:45

     
    > Sprawdz jak masz ustawione Buffe -> InputSize i ew. zwiększ jego rozmiar
    > (prawdopodobnie masz ustawione: 512 ).
    >
    > Mk.
    >
    Mam ustawione 1024 bajty
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • konstruktor.keep.pl
  • Design by flankerds.com