ATNEL tech-forum

Re: ComPort - odbieranie długich stringów

2017-11-06T06:59:24+01:00

Ok dzięki:)

Dzięki Wam za odpowiedzi, intuicyjnie doszedłem do takich samych wniosków, ale wolałem zapytać szerszego grona:)

No więc tak jak piszesz trzeba będzie troszkę poczytać i chętnie się za tą książkę zabiorę.
A co do samego terminala to podejdę troszkę z innej strony. Bo trochę się nad nim napracowałem i chciałbym go jednak troszkę udoskonalić.

Co do zipa to wtopa:) ok biorę sie programowanie a windy nie znam:) hehe

Jeszcze raz serdecznie dziękuję za dyskusję.
A jak coś uda mi się wymyślić coś konstruktywnego z tym terminalem to się za wami podzielę wynikami:)

Pozdrawiam wszystkich

Statystyki: Napisane przez Artur_26 — 6 lis 2017, o 06:59

Re: ComPort - odbieranie długich stringów

2017-11-05T23:24:17+01:00

Artur_26 napisał(a):

Jak ty byś rozwiązał takie odbieranie danych tworząc terminal?? w ogóle czy bawiłbyś się w takie wyświetlanie danych?? jak ja zrobiłem?

sam pomysł uważam za fajny, nawet chociażby w celach ćwiczebnych - to fajne wyzwanie ...

no ale jak rozwiązać transmisję binarną ... na pewno nie w ten sposób - bo sam widzisz, że nie idzie to jak chcesz. Z tego co teraz opisałeś to wynikałoby że potrzebujesz prawdziwej komunikacji binarnej z timeoutami na poziomie np długości ramki jednego bajtu a jak wiadomo czas będzie się zmieniał w zależności od prędkości transmisji

to co napisał wyżej kolega o dokładnym odmierzaniu czasów w windowsie jest prawdą i możesz sobie darować takie podejście ... w ogóle z takimi komponentami, które w ogóle np nie przewidują obsługi transmisji binarnej ...

więc albo poszukać komponentu do transmisji binarnej albo zacząć pisać samemu taką obsługę od podstaw - jest taka książka

https://helion.pl/ksiazki/rs-232c-prakt ... m#format/e

poczytaj i zobacz z czym to się wiąże i jak się do tego podchodzi od podstaw

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 23:24

Re: ComPort - odbieranie długich stringów

2017-11-05T23:17:30+01:00

Artur_26 napisał(a):

[quote="micky]Pliki wstawiamy w zipie.[/quote]
A to przepraszam, ale ma tylko winrara:)[/quote][/quote]

Winrar też robi archiwa w zipie

Statystyki: Napisane przez Marhef — 5 lis 2017, o 23:17

Re: ComPort - odbieranie długich stringów

2017-11-05T23:16:14+01:00

Quote:

A to przepraszam, ale ma tylko winrara:)

toż KAŻDY windows za FREE ma wbudowaną obsługę ZIP'a więc jak można mówić, że mam tylko RAR'a no ... chyba że masz linuxa ale wtedy też wątpię żeby nie było dostępnego pakera do zipa

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 23:16

Re: ComPort - odbieranie długich stringów

2017-11-05T22:04:54+01:00

micky napisał(a):

Po drugie w systemach Windows zapomnij o odliczaniu równych czasów rzędu milisekund.

To to ja wiem, dlatego pytam jak takie coś zrobić

-- 1 minucie --

micky napisał(a):

Pliki wstawiamy w zipie.

A to przepraszam, ale ma tylko winrara:)

Statystyki: Napisane przez Artur_26 — 5 lis 2017, o 22:04

Re: ComPort - odbieranie długich stringów

2017-11-05T22:01:19+01:00

Pliki wstawiamy w zipie.

Po drugie w systemach Windows zapomnij o odliczaniu równych czasów rzędu milisekund.

Statystyki: Napisane przez micky — 5 lis 2017, o 22:01

Re: ComPort - odbieranie długich stringów

2017-11-06T08:01:18+01:00

mirekk36 napisał(a):

dla ciebie 5 ms w takim wypadku to timeout ? .... sorki ale to hmmm kiepski pomysł

Mirku te 5 ms to przykład chodziło mi o to że Timer nie odlicza równych odcinków czasu.

Może źle zadałem pytanie, może powinienem zapytać "Jak za pomocą Delphi odmierzyć dokładnie równe odcinki czasu" ale liczone w milisekundach. Za pomocą Timera tego nie zrobię.

Czas jaki odmierzam to czas po miedzy nadchodzącymi "porcjami" danych założony prze zemnie, po którym stwierdzam, że to koniec nadsyłanej porcji danych
tylko problem z tym, że te odmierzane odcinki czasu przez Timer nie są dokładnie takie same i ja rozumiem, że tak nie będzie.

Na rysunku jest to czas 2*T1

mirekk36 napisał(a):

Tak jak myślałem - nie do końca albo nie za bardzo rozumiesz idei Timeoutu ...

Może wyjaśnię jak ja rozumiem idę, jeśli błędnie proszę o sprostowanie : przykład nie elektroniczny
1. Proszę córkę aby poszła do sklepu, ma informacje, że zaraz po zakupach ma przyjść do domu. Zakupy nie powinny jej zająć dłużej niż godzinę.
2. Po wyjściu z domu córki zaczynam odmierzać czas czyli tą godzinę.
3. Jeśli córka wróci przed upływem tej godziny kończę odliczanie czasu i daję jej cukierka za dobre sprawowanie:) hihihi
4. Jeśli córka nie wróciła po upływie godziny no to wtedy jakoś tam reaguję:)) np idę w kierunku sklepu )) albo coś tam:) ale wtedy cukierka nie dostanie:)

Wybacz taką przenośnię ale tak mi się akurat skojarzyło:)

mirekk36 napisał(a):

czemu nie dasz dużo dłuższego czasu np na początek dla testu 1000 ms ?

jeśli dam tak długi czas to jeśli z jednego terminala wyślę dane przez kliknięcie "Wyślij dane" i w ciągu nie całej sekundy kliknę drugi raz to wtedy dane które zostały wysłane dwa razy z dużym odstępem czasu zostaną potraktowane jako jedna porcja danych, np: wysyłam 123456 i po pół sekundy wyślę to samo to wtedy odebrane dane wyświetlone będą jako:
123456123456
a nie osobno:
123456
123456

Właśnie dlatego resetuję Timer w każdym zdarzeniu onRxChar po wejściu do zdarzenia Timera również go wyłączam. Do puki nie nadlecą nowe dane Timer jest cały czas wyłączony
Następne załączenie dopiero w kolejnym zdarzeniu onRxChar

Pisząc ten terminal ja nie wiem jaki będzie dokładnie odstęp pomiędzy tymi porcjami danych ale zakładam bo coś założyć muszę, że to będzie nie mniejszy niż dwukrotny czas trwania wysłania jednego bajtu (uwzględniając bit startu, stopu 2 albo jeden , bit parzystości jest czy nie ma) na tej podstawie wyliczam czas jaki jest potrzebny na wysłanie odbiór jednego bajtu. I mnożę go np. razy 2. I jeśli lecą jakieś dane i Timer liczy i odmierzył ten czas tzn, że dane już nie lecą.

Taka jest moja idea, którą zastosowałem w pisanym przeze mnie Terminalu.
Oglądałeś go może? w poście wyżej wstawiłem plik z nim.

Mirku dziękuję za cierpliwość i chęć pomocy.

Jak ty byś rozwiązał takie odbieranie danych tworząc terminal?? w ogóle czy bawiłbyś się w takie wyświetlanie danych?? jak ja zrobiłem?

Pozdrawiam wszystkich czytających:)

Statystyki: Napisane przez Artur_26 — 5 lis 2017, o 21:52

Re: ComPort - odbieranie długich stringów

2017-11-05T20:54:19+01:00

dla ciebie 5 ms w takim wypadku to timeout ? .... sorki ale to hmmm kiepski pomysł

czemu nie dasz dużo dłuższego czasu np na początek dla testu 1000 ms ?

Tak jak myślałem - nie do końca albo nie za bardzo rozumiesz idei Timeoutu ... On powinien być aktywowany tylko gdy nadleci taka twoja np niepełna paczka a nie za każdym zdarzeniem

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 20:54

Re: ComPort - odbieranie długich stringów

2017-11-05T19:01:21+01:00

mirekk36 napisał(a):

Artur_26 napisał(a):

Mirku piszesz o timeout, no właśnie zrobiłem to na Timerze ale jak wspominałem i ty też mówiłeś to nie jest najlepsze rozwiązanie dlatego czasem działa jak trzeba a czasem nie bo mi łączy porcje danych razem i

no bo nie zrobiłeś wcale timeouta - może nie wiesz co to oznacza ? ... Timer ma zareagować tylko gdy zostanie przekroczony jakiś tam czas, a gdy w międzyczasie przychodzą jakieś dane to go wciąż resetujesz

dokładnie tak zrobiłem
w obsłudze zdarzenia onRxChar najpierw wyłączam Timer i włączam go ponownie czyli po odebraniu danych zaczynam od nowa odliczać czas i jeśli nie nadejdą nowe dane to jeśli timer odliczy zadany czas to wtedy w obsłudze zdarzenia Timera wyświetlam dane patrz kod 1 post.

Jeśli dane (porcje) lecą stosunkowo szybko to się te porcje sklejają i wtedy dwie odrębne porcje traktowane są jako jedna. Bawiłem się czasami no i nie znalazłem "złotej wartości" najgorzej jest jak komp coś tam zaczyna robić wtedy Timer (tu mogę się mylić) odlicza dłuższy czas np nie 5 ms tylko troszkę więcej

[syntax=delphi]procedure TForm1.cPort1RxChar(Sender: TObject; Count: Integer);
var
dane : string;
begin
if cPort1.Connected then
begin
Timer1.Enabled := False; // wyłączenie timera
Timer1.Enabled := True; // włączenie timera - jeśli po odliczeniu czasu nie nadejdzie już zadna dana to
// w obsludze onTimer dopiero następuje wyświetlenie wcześniej odebranych danych
cPort1.ReadStr(dane, Count);
str := str + dane;
//cPort1.ReadStr(str, Count);
//Memo1.Lines.Add(str + ' ' + 'Count= ' + IntToStr(Count));
end;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
Timer1.Enabled := False; // zatrzymanie Timera
Memo1.Lines.Add(str); // wyświetlenie danych
str := '';
end;[/syntax]

Dlatego pytam czy jest możliwość zrobienia czegoś takiego inaczej.

Statystyki: Napisane przez Artur_26 — 5 lis 2017, o 19:01

Re: ComPort - odbieranie długich stringów

2017-11-05T18:38:12+01:00

Artur_26 napisał(a):

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 18:38

Re: ComPort - odbieranie długich stringów

2017-11-05T18:54:44+01:00

Witam ponownie
Dziękuję za cierpliwość:)

micky napisał(a):

Kolega chyba chce 'tylko' zwizualizować dane które przylatują po RSie.

Staram się napisać właśnie terminal, tzn napisałem takowy program i dokładnie chodzi o wizualizację
nie jest to konkretna aplikacja do analizy konkretnych ramek tylko właśnie do tego co lata po RS232 jak kolega micky napisał (oj widzę, że coś ciężko w postaci tekstu wyjaśnić mi o co chodzi).
Dlatego chcę się dowiedzieć w jaki sposób odbierać dane tak aby te (porcje) były traktowane pojedynczo czyli jeśli porcja ma np 40 bajtów to chcę wyświetlić jako jeden ciąg. I teraz jeśli nadejdzie druga porcja danych np 32 bajty w odstępie czasu trwania 2 bajtów, ten czas to przerwa cisza na linii czyli terminal nie odbiera danych w tym czasie, to te 32 bajty są wyświetlane w drugiej linii.
W zasadzie to osiągnąłem przy pomocy timera ale są wady takiego rozwiązania. Co sam zauważyłem w czasie testów a Mirek powiedział, że to błędne rozwiązanie i z tym nie dyskutuję bo się z tym w 100% zgadzam:)

poglądowy rysunek

To może jeszcze raz:
staram się napisać własny terminal (przedstawiłem we wcześniejszej odpowiedzi jak wygląda i w jaki sposób wizualizuję dane)
Od razu mówię, że piszę ten terminal aby nauczyć się co nieco i żeby mieć właśnie taki sposób prezentacji danych jaki bym chciał.
Korzystam czasem z terminala autorstwa Broy:

Ja bym chciał mieć taki sposób wizualizacji dla mnie osobiście wygodny, ponieważ widzę co wysłałem i jaką odpowiedź otrzymałem.

dane wysyłane np:
Tx-> Witam wszystkich na forum ATNEL

a dane odebrane np:
Rx-> Właśnie odebrałem długi tekst lub jakieś tam dane z jakiejś tam jednej porcji danych
Rx-> a tu odebrałem dane z kolejnej porcji danych, które zostały przesłane za raz po pierwszej porcji danych ale jako odrębna porcja danych jako drugi ciąg

czyli tak jak tu zrobiłem:

mirekk36 napisał(a):

Wydaje mi się, że mieszasz co nieco pojęcia i stąd twoje problemy..

no nie wykluczone:)) może dziś mam kiepski dzień do formułowania myśli

micky napisał(a):

Możesz np formatowac je w taki sposób, że po np. 16 odebranych bajtach przechodzisz do następnej linii.

no ale właśnie ilość przychodzących danych w jednej "paczce" porcji danych jest zmienna w zależności od tego co się aktualnie "podsłuchuje":)

Mirku piszesz o timeout, no właśnie zrobiłem to na Timerze ale jak wspominałem i ty też mówiłeś to nie jest najlepsze rozwiązanie dlatego czasem działa jak trzeba a czasem nie bo mi łączy porcje danych razem i to wychodzi wtedy kiedy np w czasie przesyłu danych otwieram jakiś inny program np przeglądarkę a czasem się tak dzieje ze ta porcja danych jest dzielona na dwie części.

A jeśli chcecie zobaczyć moje wypociny jak to działa to poniżej załączam program. Jeszcze dużo pracy przede mną i sporo do poprawy no i pewne rzeczy kuleją i wiele rzeczy można zrobić inaczej:) więc .... proszę o wyrozumiałość uczącego się:)

Mam nadzieję, że teraz wyjaśniłem co chcę stworzyć:)

Statystyki: Napisane przez Artur_26 — 5 lis 2017, o 17:02

Re: ComPort - odbieranie długich stringów

2017-11-05T15:23:37+01:00

micky napisał(a):

Kolega chyba chce 'tylko' zwizualizować dane które przylatują po RSie.

a no chyba że tak - może źle zrozumiałem ...

no ale w takim przypadku tak jak piszesz zliczać do 16 i wyświetlać każdą paczkę - w czym problem ? jak nie przyleci 16 tylko mniej do czekać na kolejny pakiet chyba że minie jakiś timeout który trzeba sobie niestety samemu zorganizować w przypadku comporta

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 15:23

Re: ComPort - odbieranie długich stringów

2017-11-05T15:06:25+01:00

Kolega chyba chce 'tylko' zwizualizować dane które przylatują po RSie.
Możesz np formatowac je w taki sposób, że po np. 16 odebranych bajtach przechodzisz do następnej linii.
Możesz podpatrzeć sposoby wyświetlania jak to jest robione w Realterm'ie.

Statystyki: Napisane przez micky — 5 lis 2017, o 15:06

Re: ComPort - odbieranie długich stringów

2017-11-05T14:57:46+01:00

Wydaje mi się, że mieszasz co nieco pojęcia i stąd twoje problemy - bo jak chcesz binarkę to nie mów, że chcesz terminal bo ma się to wtedy niestety czy tego chcesz czy nie - jak przysłowiowa pięść do nosa ...

Najgorzej jest gdy się chce mieć wszystko w jednym

Moim zdaniem to najpierw opanuj dobrze komunikację ASCII ... jak ten etap zakończysz, wtedy weź się za czystą komunikację binarną ...

zapewniam cię, że wtedy dopiero wiele ci się wyjaśni i nie będziesz się dziwił dlaczego tak a nie inaczej działa Comport i dlaczego wysyłając binarnie dostajesz dane pakietami.

Poza tym tak jak wyżej radził kolega rskup - jak już chcesz binarkę to nie będziesz miał ANI początku ANI końca danych, więc czy tego chcesz czy nie musisz się zdecydować albo na ramki stałej długości albo na ramki dowolnej długości ale do tego jakiś system ich formatowania i analizy wg tego co przylatuje na początku ramki ...

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 14:57

Re: ComPort - odbieranie długich stringów

2017-11-05T14:41:20+01:00

Witam,
dziękuję za odpowiedzi

Mirku za poradnik już się zabieram, dzięki

mirekk36 napisał(a):

Pani autor - nie słyszałeś o zakańczaniu stringów ENTEREM ?

Tak słyszałem, osobiście używam ten sposób przy komunikacji uC z PC, lub chociażby komunikując się z modułem GSM.

mirekk36 napisał(a):

... a wraz z Comportem masz komponent Datapacket który się z nim łączy ...

no właśnie w pierwszym poście pisałem, że jeśli to możliwe to nie chciałbym korzystać z Datapacket .

I również uważam, że użycie Timerów do tego celu jest nieporozumieniem, stąd mój post.

Chodzi mi mi o to aby poprawić sobie działanie terminala, który kiedyś napisałem.
Dlatego wspominałem, że chodzi o odbieranie danych, które nie mają ani początku ramki ani końca ramki lub samego końca, po prostu lecą jakieś dane i te dane chcę wyświetlać w oknie, ale te dane mogą mieć raz długość 40 bajtów raz 2 bajty raz 150 bajtów, no jak to dane odbierane przez terminal, i chciałbym aby te "dane" (paczki) nie mające wyraźnego początku i końca wyświetlały się tak jak przedstawiłem na 3 fotce.
Czyli chciałbym w jakiś sposób badać, że została odebrana nowa porcja danych

No i w sumie w pierwszym poście nie precyzyjnie wyjaśniłem o jakiego rodzaju dane chodzi, napisałem o stringach jako dane przykładowe mój błąd w tłumaczeniu problemu. SORKI. Również chodzi o dane przesyłanie binarnie, które również wyświetlam w terminalu w postaci HEX

Poniżej przedstawiam przykłady co na razie udało mi się uzyskać wykorzystując TIMER ale jak wspominałem nie zawsze to działa jak chce:((

w pierwszej linii znaki w postaci HEX

w pozostałych przedstawione jako ASCII tuż pod ASCII to samo tylko w HEX
no i jak widać jakoś to działa ale nie zawsze
dlatego szukam jakiegoś rozwiązania aby rozróżniać porcje danych dowolnych danych o dowolnych rozmiarach i o nie określonym wyglądzie ramki

Jej mam nadzieję, że teraz trochę jaśniej.

Generalnie efektem końcowym ma być terminal

Wybaczcie proszę jeśli znów nie przekazałem zrozumiale o co mi chodzi:)

Pozdrawiam serdecznie i jeszcze raz proszę o analizę tematu.

Statystyki: Napisane przez Artur_26 — 5 lis 2017, o 14:41

Re: ComPort - odbieranie długich stringów

2017-11-05T12:52:26+01:00

mirekk36 napisał(a):

No tak . Ja chyba zawsze używam binarnych protokołów, więc zero jest dla mnie normalnym znakiem do przesyłania.
Ale przy takim zwykłym rozwiązaniu znak ENTERa jest najbardziej oczywisty.

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 5 lis 2017, o 12:52

Re: ComPort - odbieranie długich stringów

2017-11-05T12:37:53+01:00

rskup napisał(a):

A nie możesz tego stringa wysyłać jako string w sensie języka C, czyli z "zakończeniem" go zerem?

nie zerem nie zerem ... tego się nie robi a znaków NULL w ogóle się nie przesyła zazwyczaj poza binarką, no ale oczywiście racja że stringi zwykle się kończy

Pani autor - nie słyszałeś o zakańczaniu stringów ENTEREM ?

Zobacz jak mówiłem mój poradnik do Delphi gdzie pokazuję przecież pełną komunikację opartą o stringi ... a wraz z Comportem masz komponent Datapacket który się z nim łączy ... i tam ustawia początek i albo ew tylko koniec ramki, no ale ciężko tu opisywać wszystko co zostało pokazane w poradniku i to bardzo jasno prosto i przejrzyście

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 12:37

Re: ComPort - odbieranie długich stringów

2017-11-05T12:31:19+01:00

A nie możesz tego stringa wysyłać jako string w sensie języka C, czyli z "zakończeniem" go zerem?
Wtedy czekasz na to zakończenie i go całego wyświetlasz .

--
Pozdrawiam,
Robert

Statystyki: Napisane przez rskup — 5 lis 2017, o 12:31

Re: ComPort - odbieranie długich stringów

2017-11-05T12:19:22+01:00

Proponuję obejrzeć mój poradnik o tym komponencie i zobaczyć jak się go obsługuje - bo w tym zdarzeniu tak zawsze będzie - a próba używania do tego timerów to niestety nieporozumienie totalne

Statystyki: Napisane przez mirekk36 — 5 lis 2017, o 12:19

ComPort - odbieranie długich stringów

2017-11-05T10:52:27+01:00

Witam,
Panowie mam pytanie co do sposobu odbioru danych przez użycie zdarzenia onRxChar w komponencie ComPort.

Mianowicie w tym zdarzeniu odbieram dane i dla przykładu chcę je wyświetlić w MEMO. Dla przykładu wysyłam taki ciąg znaków : 0123456789ABCDEFGHIJKLMNOPRSTUWXYZ

No więc moim zamiarem jest aby w MEMO wyświetlić dokładnie taki ciąg znaków jak wysłałem. Ale w MEMO nie ma wyświetlonych danych w jednym ciągu tylko jest podzielony na kilka linii,
co świadczy o tym, że zdarzenie onRxChar wykonało się kilka razy. Więc dopisałem sobie do wyświetlanych danych ilość odebranych znaków i otrzymałem taki efekt:

No dobra skoro tak działa to zdarzenie to zrobiłem taki o to test: dołożyłem sobie Timer, którym odliczam czas (teoretycznie) nieco dłuższy od czasu który jest potrzebny do wysłania jednego bajtu przez RS232 (uwzględniam tutaj całą długość ramki czyli bit startu stopu itd).
Czyli to działa tak
1. Przychodzą dane, wywołuję się onRxChar
2. Wyłączam i włączam Timer.
3. Odczytuję dane i dodaję je zmiennej string
4. Jeśli w czasie odmierzania czasu przez Timer znów wywoła się onRxChar to powtarzają sie punkty 1 do 3
5. Jeśli w czasie odmierzania czasu przez Timer nie wywoła się onRxChar, to Timer odmierza czas do końca i wywołuję się obsługa zdarzenia onTimer
6. W zdarzeniu onTimer zatrzymywany jest Timer i wyświetlany cały odebrany string co widać poniżej:

No ale to nie jest jakieś eleganckie rozwiązanie Wiadomo że czas odmierzany przez Timer nie jest dokładnie taki jaki zadaliśmy. Wystarczy, że komp zacznie robić coś innego i te czasy się wydłużają no i wtedy całe działanie programu z takim rozwiązaniem w łeb bierze:( bo jak dane będą nadchodzić stosunkowo często ale z odstępami na tyle długimi czyli dłuższymi niż czas trwania wysyłania "jednego bajtu" to się te dane połączą.

tu przedstawiam kod testowy:
[syntax=delphi]unit Unit1;

interface

uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, CPort, Vcl.ExtCtrls;

type
TForm1 = class(TForm)
cPort1: TComPort;
Memo1: TMemo;
Button1: TButton;
Edit1: TEdit;
Button2: TButton;
Timer1: TTimer;
procedure FormCreate(Sender: TObject);
procedure Button1Click(Sender: TObject);
procedure cPort1RxChar(Sender: TObject; Count: Integer);
procedure Button2Click(Sender: TObject);
procedure Timer1Timer(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;

var
Form1: TForm1;

implementation

{$R *.dfm}

var
str : string;

procedure TForm1.Button1Click(Sender: TObject);
begin
if cPort1.Connected then
cPort1.WriteStr(Edit1.Text);
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
Memo1.Clear;
end;

procedure TForm1.cPort1RxChar(Sender: TObject; Count: Integer);
var
dane : string;
begin
if cPort1.Connected then
begin
Timer1.Enabled := False; // wyłączenie timera
Timer1.Enabled := True; // włączenie timera - jeśli po odliczeniu czasu nie nadejdzie już zadna dana to
// w obsludze onTimer dopiero następuje wyświetlenie wcześniej odebranych danych
cPort1.ReadStr(dane, Count);
str := str + dane;
//cPort1.ReadStr(str, Count);
//Memo1.Lines.Add(str + ' ' + 'Count= ' + IntToStr(Count));
end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
cPort1.Open;
Memo1.Clear;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
Timer1.Enabled := False; // zatrzymanie Timera
Memo1.Lines.Add(str); // wyświetlenie danych
str := '';
end;

end.[/syntax]

Mam nadzieję, że w miarę jasno przedstawiłem o co mi chodzi.

Pytanie takie: czy znacie sposób aby za pomocą tego komponentu ComPort zrobić tak aby po odebraniu np 40 bajtów w jakimś zdarzeniu można było odebrać na raz 40 bajtów,
czyli uzyskać taki efekt jak z tym Timerem.
Nie chodzi mi o to aby wykorzystywać DataPacket ponieważ nadchodzące dane nie będą w postaci ściśle określonych ramek, w których jest konkretny początek i koniec lub tylko sam koniec.

Chcę to wykorzystać do własnego terminala, tak aby nie zależnie od tego ile by nie przyszło danych, była rozróżniana "jedna porcja" tak aby można było ją wyświetlić tak tu:

Obecnie mam wykorzystany sposób z Timerem ale jak dane lecą stosunkowo szybko to nie zdaje do końca egzaminu:( choć częściowo cel został osiągnięty.
Z góry dzięki za wszystkie sugestie

Statystyki: Napisane przez Artur_26 — 5 lis 2017, o 10:52