VISA: (Hex 0xBFFF006C) przy komunikacji po RS232

[Zer0]

Witam!
Ostatnio stworzyłem centralkę do 4-punktowego pomiaru tempearatury. Całośc wygląda mniej więcej tak: centralka oparta o ATmega8 pretwarza wartości z kanałów ADC, tworzy string dla LV i wysyła przez RS232 do aplikacji, gdzie prowadzone są 4 wykresy wraz zapisem danych. Dopóki ATmega siedziała na programatorze transmisja śmigała z prędkością 115,2kbps oraz wykonywanych było 10 pomiarów na sekundę. Teraz, gdy ATmega stałą się "samodzielna" wszystko się popsuło - prędkość transmisji obniżyłem do 9,6kbps, zmniejszyłem ilość pomiarów do 2 na sekundę, oraz w waplikacji LV dodałem flush buffer - o ile to załatwiło "framing error", to nadal po około 1,5 minuty działania centralki wystakuje mi VISA: (Hex 0xBFFF006C) An overrun error occurred during transfer i zabawa się kończy ;/ Ktoś może ma pomysł co może być winne i jak to "wyleczyć"?
ATmega8 komunikuje się z komputerem za pośrednictwem układu MAX232...

[Pitol]

Z opisu błędu i tego co można na necie wyczytać to wygląda na to, że Twój program nie nadąża z czytaniem danych z portu. Ale skoro piszesz, że zmniejszyłeś prędkość to trochę dziwnie moje wyjaśnienie wygląda. Nie wiem jak wygląda Twój diagram więc ciężko jest coś zaproponować. Jeśli możesz, to dołącz VI. Ułatwi nam to pomoc.

[Zer0]

Dziękuję za zainteresowanie
Bo ten problem jest na prawdę dziwny... Obniżyłem predkość transmisji do śmiesznych 2,4kbps i dalej to samo - systematycznie, za każdym razem po 2 minutach pojawiał się overrun. Ale sytuacja ta miała miejsce tylko na laptopie, na którym pośrednikiem komunikacji była przejściówka USB <--> RS232...
Po podłaczeniu centralki pomiarowej do komputera stacjonarnego (który jest wyposażony sprzętowo w RS232) problem zniknął
Pomiar trwał 5 minut i nic (w sensie bez błędów).
Że przejściówki są o kant D, to wiedziałem... ale nie spodziewałem się, że aż tak, zważywszy na fakt, że programator AVR śmiga na tej właśnie przejściówce i to z prędkością 115,2kbps... Gdybym wiedział, to za wczasu zrobiłbym centralkę z interfejsem RJ45
Co do VI - chętnie zamieszczę aplikację, bo problem ten chcę nadal rozwiązać (centralka ma działać na lapku z przejściówką) i chciałbym się podzielić (w moim odczuciu) całkiem ciekawym projektem, z tym, że proszę o wyrozumiałość - strukturę VI starałem się zrobić możliwie najprościej i minimalnie, ale wyszedł byk

EDIT:
Zauważyłem, że niektórzy zalecają w przypadku układu MAX232 dać kondensatory 10uF - ja dałem "ksiązkowo" 1uF...
Kabel USB łączący przejściówkę z lapkiem może być za długi...
W każdej chwili mogę dorzucić schemat centralki ze zdjęciem

[PiDi]

strukturę VI starałem się zrobić możliwie najprościej i minimalnie

No cóż, minimalnie to nie wyszło Przynajmniej porządek jest w samych kabelkach i bloczkach, ale zdecydowanie musisz zacząć używać subVI, bo kopiowanie i wklejanie kodu kilkukrotne prowadzi tylko do rozrastania się kodu - i potężnej frustracji przy najmniejszej zmianie w algorytmie. Na przykład tutaj:

Co do samego problemu, to to nie jest kwestia baud rate. On tylko decyduje o tym, jak szybko przepchniesz dane przez sieć. Ty masz zapewne problem z tym, że jak już te dane przejdą przez sieć i zostaną odebrane przez system, to odczytujesz je z bufora systemowego za wolno, następuje jego przepełnienie i stąd błąd. Sprawdź przede wszystkim, jak często twoja aplikacja czyta z VISA nowe dane, czyli jaki jest okres tej pętli (wstaw tick count do niej i odejmuj sobie przez shift register poprzednią wartość od nowej, wyświetlaj wyniki na panelu). Jeśli się okaże, że jej częstotliwość jest mniejsza niż twoje 10 razy na sekundę, to wiadomo, w czym problem. Rozwiązaniem może być zastosowanie kontroli przepływu. Chociaż do końca nie wiem, jak będzie to działać przez przejściówkę, ale softwareowy flow control powinien działać, hardwareowy chyba odpada.

[Zer0]

Tam więcej case'ów nadawałoby się na SubVI, pomyślę o tym rozwiązaniu. ;) Na pewno będzie to czytelniejsze, zajmie mniej miejsca i będzie bardziej poprawne... Co do kontroli przepływu, to centralka jest zrobiona jako urządzenie DTE, które udaje pełny handshaking (RTS zwarte do DCD i CTS, oraz DTR zwarte do DSR). Tak więc RTS/CTS oraz DSR/DTR można by spróbować jeszcze Na pewno spróbuję podłaczyć centralkę przez przejściówkę ale do stacjonarnego komputra - jeżeli "zahula" dłużej niż te magiczne 2 minuty, to znaczy, że laptop zamula i jedyne lekarstwo to format albo śmietnik
Późnym wieczorem porobię parę testów i dam znać co mi z tego wyszło ;)

[PiDi]

A, i byłbym zapomniał: http://www.explosm.net/comics/2301/ ;)

[Zer0]

A, i byłbym zapomniał: http://www.explosm.net/comics/2301/ ;)

Ta rozmowa schodzi na niewłaściwy tor
No ale, przejściówka wywołuje błędy, a żadna z dostępnych metod kontroli przepływu nie powoduje naprawienia tego błędu. Na przejściówce aplikacja działa 60, góra 120 sekund - a potem kaplica.
No widać przejściówki USB <--> RS232 nie są przystosowane do tworzenia urzadzeń, które w kółko mają coś do powiedzenia komputrowi i w kółko nasłuchują odpowiedzi
Zostaje mi tylko przerobić plik VI na samodzielny EXE, tak by mozba było odpalać na komputrach bez LV (nowe wyzwanie przede mną)

[Zer0]

No i proszę Państwa stał się chyba cud nad Wisłą - przejściówka USB <--> RS232 (konkretnie PROLIFIC 2303) działa!
Pomiar trwał ok 7 minut, co jest miarodajne bo zwykle overrun error wyskakiwał max po 2 minutach.
Zapytacie co zrobiłem? Otóż nic nie zrobiłem, jedynie kabelek USB łączący komputer z przejściówką zamieniłem z długości 180 cm na 40 cm. Transmisja śmiga na pewno, gdy urządzenie DTE odzywa się do komputera 2 razy na sekundę (2 pomiary na sekundę), a port skonfigurowany jest tak:

Czy da się z tego wycisnąć coś więcej? Pewnie tak, w wolnej chwili podniosę prędkość transmisji do docelowych 115,2kbps oraz zwiększę ilość odczytów (chociaż odczytywanie temperatury z tak dokładnego termistora jak LM235 więcej niż 2 razy na sekundę jest przesadne).
Tak BTW może się okazać, że flush buffer na zdjęciu powyżej też okaże się niepotrzebny ;)

W każdym razie - empirycznie stwierdzono, że przy stosowaniu przejściówki PROLIFIC 2303 należy zadbać o jak nakrótszą drogę pomiędzy przejściówką a gniazdem USB płyty głównej komputera.

Problem jest oficjalnie rozwiązany, ale niechaj wątek pozostanie dla innych uzytkowników przejściówek PROLOFIC 2303, których strzela frustracja (jak mnie), że coś nie działa i "HGW" dla czego?
Dziękuję wszystkim za zainteresowanie i chęć pomocy

[rivui]

Hej

U mnie w pracy uzywamy przejsciowek Prolific 2303 z kablem dlugosci okolo 1m i komunikacja dziala jak nalezy. Komunikujemy sie przez te przejsciowke co 100ms i w ten weekend nawet lecial test gdzie skomunikowalismy sie z naszym urzadzeniem okolo 2mln razy i nigdy nie otrzymalismy takiego bledu jak ty.

Moze problem lezy w samej konstrukcji SubVi sluzacego do zczytywania danych? Generalnie dla bezpieczenstwa ja bym dodal funkcje Wait do tej petli while jako ze teraz bedzie ona sie wykonywac tak szybko na ile Twoj procesor pozwoli ale jezeli mowisz ze 2 razy na sekunde wystarcza to zapisujesz i odczytujesz dane o wiele za szybko..

Michal

[artbi82]

Witam,
Ja też używam konwerter z układem PL2303 i miałem problem gdy aplikacja działała pod windowsem 7 (64-bit). Problem rozwiązał się po instalacji najnowszych sterowników ze strony Profilic, te dołączone z konwerterem nie działały poprawnie. Przejściówkę testowałem z różnymi prędkościami od 9600 do 115200 i jest ok. Obecnie odczytuję dane z prędkością 50 pomiarów na sekundę. Problem może być też po stronie atmegi na płytce jest kwarc czy działa na wewnętrznym zegarze?

[Zer0]

Rivui, byc może wszystko lezy w jakości przewodu USB, ja używałem belkin 180cm i np ekranowany na pewno nie jest. Ty się bawiłeś na przewodzie 100cm z tego co piszesz i raczej lepszej jakości niż wspomniany belkin ;) Pamiętajmy, że sygnał USB to zaledwie 5V, więc impedancja falowa przewodu, oraz sam przewód, który w rzeczywistości można traktować jako układ RLC szybko taki sygnał wytłumi.
A czy transmisja idzie za szybko, skoro robię 2 pomiary na sekundę? Atmega nie narzeka ;) po prostu ma czas aby "się ponudzić" pomiędzy transmisjami. Poza tym, jeżeli (jak już wspominałem) wymieniłem przewód USB ze 180 cm na 40 cm i wszystkto ruszyło, nawet na prędkości 115,2kbps to winowajca raczej został znaleziony ;)
A tak swoją drogą to na tym przewodzie od belkina nic nie pomagało - ani opóźnienia, ani sekwencje, ani obniżenie prędkości do 2,4kbps - po najdalej 120s była kaplica...

Artbi82, też mam Win7 w wersji x64 i też się użerałem ze sterownikami dołączonymi na płytce... A co do rezonatora, to owszem zastosowałem rezonator kwarcowy 11,0592MHz. Tutaj problem może tkwić w tym np, że rezonator wisi na zwykłych kondensatorach ceramicznych o wątpliwej dokładności. To samo dotyczy układu MAX232, który ma podpięte zwykłe elektrolity o wartości 1uF (mogłem dać tantalowe albo polimerowe 10uF i to te o wyższej dokładności)...

Błędem mogło być też zastosowanie obciążeń indukcyjnych (centralka jest wyposażona w 3 wyjścia przekaźnikowe) zasilanych z tego samego stabilizatora napięcia, którym zasilam również Atmegę, MAX232, diody LED i inne elementy centralki.