Polskie Centrum LabVIEW

witam wszystkich

mam urządzenie, które wysyła w sposób ciągły dane pomiaru w postaci:
- AA 55 (hex) - znacznik początku ramki
- licznik danych - stała wartość (nie wiem po co - tak ktoś sobie wymyslił)
- licznik ramki (00..FF - i tak w kółko)
- dwa bajty wyniku pomiaru napięcia
- dwa bajty wyniku pomiaru prądu
- jeden bajt kontrolny (xor z wszystkich poprzednich bajtów)

dane są wysyłane z prędkością 115200kb/s
co 2,5ms

nie wiem po co i dlaczego tak --- urządzenie pomiarowe wykonali koledzy studenci kilka lat wcześniej
teraz trzeba do tego dorobić odbiór tych danych
myślałem, że sobie poradzę.......

jakoś poległem
gubię ramki, mam problem z synchronizacja (może za wielkie słowo)

bardzo proszę o pomoc

z góry dziękuję


do tej pory (od dawna) czytywałem sobie posty na tym forum
ale nic mądrego w labview nie zrobiłem - dlatego się tak motam

PNSK - pokaż nam swój kod (pamiętając, żeby był uporządkowany).

Będzie wtedy można stwierdzić, czemu gubisz dane.

bogdani

Właśnie zrobiliśmy benchmark z 3 portami RS działającymi z niestandardową prędkością 2Mb/s, nadającymi w sposób ciągły i odbiornikiem takich zakodowanych danych na drugim PC.
Nie było żadnych problemów - działa.

Istotne informacje:
- bufor sprzętowy w karcie 4 portowej RS był wielkości 128 bajtów
- zwykły UART ma 16 bajtów fifo - zatem 10 razy mniej
115kb/s to 30 razy mniej niż 3Mb/s, zatem też powinno przejść bez problemu
- FIFO na karcie/porcie RS jest kopiowane w procedurze obsługi do RAMu w OSie, który standardowo jest alokowany na 4kB, chyba, że VISA property ustawi inaczej.
- 115kb/s to około 10kB/s
- 16B FIFO zapełniane jest zatem w czasie około 1.5ms - PC nie może być przeciążony, bo CPU nie obsłuży wszystkich przerwań z portu
- 4kB RAMu wystarcza zatem na 400ms (transfer 10KB/s) - potem się zapełnia, zatem aplikacja musi wybierać dane z bufora kernelowego do jakiegoś pomocniczego nie rzadziej, niż 4x na sekundę
- transfer danych binarnych wymaga czasem przesłania hex10 i hexA, podczas kiedy te znaki mogą być traktowane jako termination character - wniosek - wyłączmy termination w inicjalizacji portu

Oprócz powyższego, reszta to już tylko rzemiosło w LV i struktura maszyny stanu rozbierającej ramki.

Pozdrawiam,
PHdeR.

Miałem na myśli hexD i hexA oczywiście ...
No i ew. hex0.
(:

witam,

walczyłem, bylem na wakacjach i znowu walczę

kodu nie ma co pokazywać - można to zrobić pewnie na kilka sposobów, a mój nie jest idealny i cały czas go poprawiam

wykonałem urządzenie na procku, które wysyła cały czas taką samą ramkę danych - dla mnie to ułatwienie

jeśli wysyłam ramki z prędkością 19200bps co powiedzmy pół sekundy, to nie ma najmniejszego problemu
program wygląda prosto - ustawienie portu, dalej w pętli odczyt z portu tyle danych ile na nim jest + określone opóźnienie (tu pół sekundy)
zawsze odczytuję tyle bajtów ile ma być i wszystko się zgadza

natomiast jeśli zwiększam prędkość i wysyłam ramki częściej, to metoda ta nie działa - podejście jest raczej złe -- nie jestem w stanie rozpoznać prosto początku ramki
przy prędkości 115200b/s (wcześniej sie pomyliłem pisząc kbps) zaczynają dziać się rzeczy, których nie jestem w stanie objąć umysłem
nie potrafię rozpoznać początku ramki w sposób jaki wcześniej napisałem

wydaje mi się, ze jedyną metoda jest rozpoznawanie za każdym sekwencji startowej ramki, odczyt danych, sprawdzanie bajtu kontrolnego

jest tam bajt "licznik danych" (00..FFh itd.) - można w ten sposób wykrywać które i ile ramek jest gubionych

nie wiem ile bajtów i co jaki czas odczytywać - brak mi pomysłów

czy da sie z taka prędkością odczytywać dane i nie gubić ramek ?
jeśli tak, to proszę o pomoc - chodzi mi o podpowiedz


dziękuję i pozdrawiam

Rafal

Myślałem że post Pawła już dokładnie wyjaśnił problem.
Skoro nie to:
1. Podsyłam programik który ja zawsze używam do sprawdzania i konfiguracji komunikacji po RS232 i bluetooth.
2. Paweł już Ci zasygnalizował jakie mają być parametry transmisji - max 10kb/s, dla przećwiczenia ustaw: "Rozmiar bufora";"Przerwa pętli odczytu";"Timeout odczytu" kolejno na:
- 4000/400/500,
- 1000/100/150,
- 100/10/15,
- 10/1/2.
i przesymuluj transmisję danych wysyłając plik "dane przykładowe. txt" z Hyperterminala przez COM'a X na COM'a Y do którego podłączony jest serialgrabber (nul modem kabel) oraz sprawdź czy wszystkie dane docierają oraz jakie jest obciążenie Procka w Menedżerze Zadań oraz wyciągnij wnioski.
3. Kwestia doprogramowania analizy odebranych danych pod kątem wyodrębnienia wyniku pomiaru napięcia i prądu nie powinna sprawić trudności.
W razie pytań - pisz.
Rumcajs.

witam,

dzieki za odpowiedz
jednak niczego ona nie wnosi ( z calym szacunkiem)

przedstawilem problem na poczatku - podalem format ramki, predkosc, czestotliwosc przesylania danych
chcialem tylko i wylacznie dostac ze dwa zdania wskazujace kierunek - bym nie bladzil

bogdani dal swoja wyprobowana rade, ktora stosuje bardzo czesto - czyli by pokazac swoj kod - rada zacna - ale troszke kpiaca z czlowieka, ktory ma problem

a rumcajs pisze, ze predkosc max ma byc "10kb/s" (mam nadzieje, ze kilobajty - ja tez sie na poczatku pomylilem)

predkosc przesylania danych interesujacego mnie urzadzenia wynosi w rzeczywistosci 150000bps (bitow na sekunde) - rs422, karta pcmcia
na monitorze portu rs232 dane sa prawidlowe
jakis dziwny czlowiek tak sobie wymyslil i nic sie nie zmieni - mozna najwyzej problem obejsc lub wykorzystac inne srodowisko programistyczne


zatem prosze raz jeszcze o pomoc

problem nie wystepuje, gdy mamy odebrac np. 10 bajtow danych co pol sekundy
wtedy mozna sobie czekac te pol sekundy, odczytac 10 bajtow i juz mamy wszystko -- banalne dla wszystkich, ktorzy cos zrobili w labview
natomiast przy tak duzej predkosci danych jest za duzo by dzialaly te "zlote" przykaldy z labview (ktore zreszta bez poprawek nie nadaja sie do niczego)

poniewaz dane te na ta chwile maja byc wyswietlane tylko na wykresie, wiec mysle, ze jest ich zbyt duzo
mozna wiec rysowac punkt na wykresie co np. 50ms --- wiec mozna odczytywac port co 50ms i odbierac powiedzmy 17 bajtow - wsrod ktorych na pewno bedzie interesujace nas 9 bajtow ramki -- rozpoznac poczatek, wyluskac dane i wyswietlic

jak ktos ma lepszy pomysl - a pewnie jest prosta metoda by odczytywac wyszystkie dane (jakas kolejka itp.) - to prosze o rade


pozdrawiam,
Rafal

Witam

Nie wiem czy do końca zrozumiałem problem ale uważam, że wystarczy zastosowanie rejestru przesuwnego w pętli odczytującej z portu. Po odczytaniu pierwszego bajtu oraz odpowiedniej liczby bajtów (lub bajtu końcowego, co można sprawdzać w tej samej pętli), można wysłać te dane dalej. Nie próbowałem zabawy z takimi prędkościami ale mój RS232 spokojnie działa nawet bez żadnego odczekiwania czasu, właściwie działa z maksymalną prędkością wykonywania programu.

Pozdrawiam
Sir Saracen

LV to środowisko graficzne i rada PNSK wcale nie jest kpiną, tylko logiczną, najprostszą drogą prowadzącą do rozwiązania. Choćbyś pisał nam całe referaty na temat tego jak to działa, co nie działa i jak powinno działać, to nie powie nam to tyle, co 10s z Twoim kodem.

Ender - ja nadal twierdze, ze w tym przypadku pokazanie kodu nie mialo najmniejszego sensu - a jesli tego nie rozumiesz, to masz problemy z czytaniem ze zrozumieniem
sledze to forum od jego powstania - czesto po pokazaniu swojego kodu nastepowalo nastepnych 20 postow na temat nieoptymalnosci tego kodu

moze i slusznie - ale w 90% ludzie spodziewaja sie tylko porady

bardzo dziekuje Sir_Saracen - Twoj post powinien sie znalezc jako drugi i zamknac temat
ja tez wspomnialem o kolejce - ale wczesniej po prostu o tym nie pomyslalem

pozdrawiam,
Rafal