Polskie Centrum LabVIEW

Witam,
Mam problem z radarem do pomiaru prędkości. Posiada on wyjście RS485 ale podłączony jest przez przejściówkę na RS232. W bloczku Visa Configure podaję wszystkie parametry współpracy zgodnie z danymi z instrukcji (19,2kBaud, 1 bit startu, 8 bitów danych, 1 bit stopu, no parity) ale z bloczka do odczytu danych dostaję tylko jakieś krzaki. To jedna sprawa. Druga sprawa, jak mam rozumieć tabelę na stronie 53 z protokołem RS232? Header, bloki danych od 1 do 10 i footer są wysyłane w kolejnych ramkach i tak w kółko? I co oznaczają przy header pola "0C hex" i "FC hex"?
Instrukcja jest dostępna pod adresem:
https://docs.google.com/viewer?a=v&pid= ... y=CPumwdoK
Z góry dzięki za pomoc

introvert_84 pisze:Witam,
Mam problem z radarem do pomiaru prędkości. Posiada on wyjście RS485 ale podłączony jest przez przejściówkę na RS232. W bloczku Visa Configure podaję wszystkie parametry współpracy zgodnie z danymi z instrukcji (19,2kBaud, 1 bit startu, 8 bitów danych, 1 bit stopu, no parity) ale z bloczka do odczytu danych dostaję tylko jakieś krzaki.

Jakie krzaki? Zamieść przykładowy odczyt, może będziemy w stanie pomóc. Co do krzaków... pewnie jest tak, że urządzenie wysyła dane w hexie a nie w ASCII. Skorzystaj z bloczka String To Byte Array w palecie String gdzieś... nie pamiętam.

introvert_84 pisze: To jedna sprawa. Druga sprawa, jak mam rozumieć tabelę na stronie 53 z protokołem RS232? Header, bloki danych od 1 do 10 i footer są wysyłane w kolejnych ramkach i tak w kółko? I co oznaczają przy header pola "0C hex" i "FC hex"?
Instrukcja jest dostępna pod adresem:
https://docs.google.com/viewer?a=v&pid= ... y=CPumwdoK

0C hex i FC hex oznaczają, że header składa się z dwóch bajtów: 0CFC... Dzięki temu np. łatwo jesteś w stanie oddzielać kolejne ramki od siebie.
Wygląda na to, że każda ramka składa się z dwóch bajtów na header, 12 bajtów danych i jeden bajt na sumę kontrolą (footer)

Dzięki za odpowiedź.
Oto co dostaję z wyjścia radaru:
ŕ„üş rb ŕ„ü» tb ŕüĽ ub ŕü˝ rb ŕüľ tb ŕ~üż ub ŕ|üŔ wb ŕyüÁ tb ŕ{ü tb ŕzüĂ vb ŕwüÄ wb ŕuüĹ tb ŕwüĆ vc ŕsüÇ wc ŕqüČ uc ŕrüÉ nc ŕxüĘ nc ŕwüË pc ŕtüĚ nc ŕuüÍ nc ŕtüÎ pc ŕqüĎ qc ŕoüĐ nc ŕqüŃ pc ŕnüŇ qc ŕlüÓ pc ŕlüÔ pc ŕküŐ rc ŕhüÖ sc ŕfü× rc ŕfüŘ qc ŕfüŮ rc ŕdüÚ tc ŕaüŰ qc ŕcüÜ rc ŕaüÝ tc ŕ^üŢ rc ŕ_üß qc ŕ_üŕ tc ŕ[üá uc ŕYüâ tc ŕYüă sc ŕYüä uc ŕVüĺ vc ŕTüć uc ŕTüç tc ŕTüč vc ŕQüé wd ŕNüę vd ŕNüë td ŕOüě wd ŕKüí xd ŕIüî vd ŕJüď ud ŕJüđ wd ŕGüń yd ŕDüň wd ŕEüó ud ŕFüô xd ŕBüő zd ŕ?üö xd ŕ@ü÷ qd ŕFüř pd ŕFüů rd ŕCüú pd ŕDüű od ŕDüü qd ŕAüý td ŕ=üţ rd ŕ>ü˙ rd ŕ=ü sd ŕ;ü td ŕ9ü sd ŕ9ü sd ŕ8ü ud ŕ5ü vd ŕ3ü r
z kolejnej próby:
ŕüM ~/ ŕüN / ŕüO €/ ŕüP ~/ ŕüQ |/ ŕüR 0 ŕüS €0 ŕüT 0 ŕüU ‚0 ŕüV ~0 ŕüW 0 ŕ
üX 0 ŕ
üY ‚0 ŕüZ ƒ0 ŕü[ 0 ŕü\ 0 ŕü] 0 ŕü^ ƒ0 ŕü_ „0 ŕ ü` …0 ŕţüa ƒ0 ŕ˙üb 0 ŕ üc ƒ0 ŕýüd „0 ŕűüe …0 ŕůüf †0 áöüg „0 á÷üh |0 áţüi {0 áţüj }0 ŕüük 0 ářül ~0 ářüm ~0 á÷ün |0 ářüo ~0 áőüp €0 áňüq 1 áďür ‚1 áíüs ~1 áđüt 1 áîüu €1 áěüv ‚1 áéüw 1 áëüx x1 áńüy w1 áńüz y1 áîü{ z1 áěü| x1 áíü} w1 áíü~ z1 áéü {1 áçü€ {1 áćü y1 áçü‚ z1 áĺüƒ {1 áăü„ |1 ááü… z1 áâü† y1 áâü‡ €1 áÚüˆ ‚1 á×ü‰ ƒ1 áŐüŠ „1 áÓü‹ €1 áÖüŚ 1 áÔüŤ ƒ1 áŃüŽ „1 áĎüŹ …1 áÍü ‚2 áÎü‘ {2 áÔü’ z2 áÔü“ |2 áŃü” }2 áĎü• ~2 áÍü– x2 áŇü— s2 áÖü˜ t2 áÔü™ v2
Ktoś ma jakiś pomysł? :/

Skorzystaj z bloczka String to Byte Array w palecie String -> Conversion. Otrzymasz poszczególne bajty w tablicy. Teraz możesz sobie tą tablicę podzielić na poszczególne ramki. Wyszukuj header (0CFC, czyli 12, 252 w systemie dziesiętnym). Jak już będziesz miał poszczególne ramki z tablicy powyciągane, możesz sobie na podstawie tego dokumentu, co dodałeś, każde pole zdekodować.

Uzupełnij profil o wersję środowiska. Pozwoli to przygotowywać przykłady dla Ciebie w odpowiedniej wersji LabVIEW.

faktycznie, bloczek string to byte array wyrzuca zawsze wartość 12 i 252 czyli 0C i FC. Tylko teraz przydałoby się jakoś zsynchronizować odczyt bo jak daję na wejście bloczka visa read wartość byte count = 13 to za każdym razem poszczególne bajty są w innych miejscach i skaczą po arrayu.

Możesz zawsze odczytywać więcej niż cała ramka (tak x2). Wtedy napewno trafi Ci się w odczycie cała ramka.

Ustawiłem odczyt na 30 bajtów danych - wtedy na pewno wpada cała ramka. Między dwoma footerami zgodnie z protokołem radar powinien wysyłać 11 bajtów danych. Co dziwne wysyła 11, 8, 3, 11, 8, 3, i tak w kółko. I jeszcze chciałem spytać, zgodnie z instrukcją wysyła zmierzoną prędkość w 2 kolejnych bajtach - jak mam to rozumieć? Część całkowita i po przecinku? czy jakoś połączyć to w jedną wartość?

Ramki dostajesz cyklicznie, co 10 ms (chyba, że klient życzył sobie inaczej, 1. wiersz tabeli na stronie 53), w pierwszym bajcie każdej z nich zapisana jest liczba = liczba bajtów w ramce - bajt sumy kontrolnej (FCS). Zawsze dostajesz tylko ramki 13-bajtowe?
Możesz sprawdzać wartość własności VISA Bytes at Serial Port i dokonać odczytu dopiero wtedy, jak masz tych bajtów w buforze co najmniej 13. Jak na wejściu byte count obiektu VISA Read będzie liczba 13, to wtedy obiekt zwróci Ci całą ramkę.

Zgodnie z instrukcją wysyła w dwóch bajtach zmierzoną prędkość z rozdzielczością 16 bit. Tak, jak tam napisali: 1 LSB odpowiada 0.009155 km/h.
Przykładowo dostajesz hex 102F, co odpowiada dec 4143, czyli prędkość wynosi 4143*0.009155 km/h = 37,93 km/h.
Albo łatwiej: 4143/65535 * 600 km/h (czyli 4143/2^16 * 600)

darekc pisze:Ramki dostajesz cyklicznie, co 10 ms (chyba, że klient życzył sobie inaczej, 1. wiersz tabeli na stronie 53), w pierwszym bajcie każdej z nich zapisana jest liczba = liczba bajtów w ramce - bajt sumy kontrolnej (FCS). Zawsze dostajesz tylko ramki 13-bajtowe?
Możesz sprawdzać wartość własności VISA Bytes at Serial Port i dokonać odczytu dopiero wtedy, jak masz tych bajtów w buforze co najmniej 13. Jak na wejściu byte count obiektu VISA Read będzie liczba 13, to wtedy obiekt zwróci Ci całą ramkę.

VISA Bytes at Serial Port zwraca cały czas wartość 4096. Zrobiłem algorytm który pobiera 30 bajtów danych, sprawdza gdzie ma pierwszy footer i kolejny, czyli początek i koniec ramki, i bierze dane które są pomiędzy footerami. Co dziwne tych bajtów nie zawsze jest 11, czasem jest mniej, 3 lub 8

PiDi pisze:Zgodnie z instrukcją wysyła w dwóch bajtach zmierzoną prędkość z rozdzielczością 16 bit. Tak, jak tam napisali: 1 LSB odpowiada 0.009155 km/h.
Przykładowo dostajesz hex 102F, co odpowiada dec 4143, czyli prędkość wynosi 4143*0.009155 km/h = 37,93 km/h.
Albo łatwiej: 4143/65535 * 600 km/h (czyli 4143/2^16 * 600)

Czyli przykładowo po zamianie dwóch bajtów prędkości za pomocą string to byte array dostaję wartości 2 oraz 154, jako wartość którą mnożę razy 1 LSB biorę 2154?

Radar cały czas wysyła różną liczbę bajtów pomiędzy headerami, czasami wysyła 11 lub 12, czasem 2. Ktoś ma pomysł jak to rozumieć? i jak to ogarnąć w kodzie?

Jeśli wysyła za mało/dużo ramek to po prostu ignoruj taką ramkę i po kłopocie. Pisałeś, że dostajesz na raz z urządzenia 4096 bajtów, więc możesz sobie w całej tej paczce wyszukiwać odpowiedniej ramki...

Może "wyczyść" bufor odbiorczy przy użyciu obiektu VISA Flush I/O Buffer, a dopiero potem przystąp do odbioru ramek w taki sposób, jaki zaproponowałem. Aha, jeszcze na zacisk Enable Termination Char podprogramu VISA Configure Serial Port dołącz stałą FALSE, bo w przeciwnym razie, jeśli w ramce będzie się znajdować bajt '\n' (wartość 10, ustawienie domyślne) VISA Read zwróci Ci <= 13 bajtów.

Koncepcja oczekiwania na 13 bajtów jednak nie jest dobra - przecież nie ma gwarancji, że pierwszy odczytany bajt będzie miał wartość 0C. Poza tym rzeczywiście radar wysyła co 10 ms ramkę, której znacznik początku stanowią bajty 0C FC. Odczytuj blok 30 bajtów (chociaż wystarczyłoby 26 ), następnie wyszukaj w tym bloku dwa podciągi 0C FC. Po ich odnalezieniu oblicz odległość między nimi - jeżeli wynosi 13 bajtów, to masz ramkę. Kawałek bloku zaczynający się od drugiego podciągu 0C FC musisz uwzględnić przy analizie zawartości kolejnego bloku 30 bajtów - nowy blok po prostu "doklejasz" i wykonujesz kolejną analizę. Pamiętaj, że mogą wystąpić błędy transmisji i w bloku o długości >= 30 bajtów możesz nie znaleźć dwóch podciągów 0C FC.

Ostatni pomysł też nie jest najlepszy, bo będą eliminowane ramki z bajtami 0C FC między znacznikiem początku a bajtem sumy kontrolnej. Rozważ taki algorytm: