TESTY KAMERY :
cd
/opt/pi/dev/pisys/daq/ndir/results/EthTest/RealCAM
test2K2K k20 -eth=100.100.100.102
or
nohup ccdsingle > out 2>&1 &
- 2005 - 12 - 12
1/ wywalanie sie nie zostalo zlokalizowane, Robertowi nie udalo sie
tego znalezc
2/ wzialem stara wersje dodalem printfy i testuje mam pewna hipoteze,
wydaje mi sie ze to sie wiesza,
bo nie robi sie tym BkgListener cond_singal - czy
jest to mozliwe ?
dodalem pare printf-ow, powinny wyjasnic sprawe !
Linia 402 - czy to jest OK ?
3/ sytacja w zwisie wyglada tak w funkcji BkgListener dostaje :
state = pt->_comm->GetState(); //
state=1 , co
oznacza NUDP_READY
if ( state & NUDP_DATA )
i wtedy on wogole nie wchodzi w kawalek w ktorym moze
zwolnic ten cond_wait, co powoduje ze WaitForRawData wisi FOREVER
bo on chodzi w tej petli glownej tylko wykonujac :
pt->_h->Select( 0, 20000 );
a nigdy nie zwoli - pytanie , jak do tego doszlo ze
GetState zwraca NUDP_READY mimo ze poszla komenda ze ma byc GetData ????
4/ najwyrazniej NudpSocekt zatraca informacje ze state jest w NUDP_DATA
i to powduje ze tam latamy w kolko i nic ... a
WaitForRawData wisi.
Dodalem printfa, i w zwisie to wlasnie on sie
wypisuje !!! :
if( pt->_data_taking ){
printf("In data taking mode !!!\n");fflush(0);
}
if( bIsTransfer
){
printf("previously was transfer\n");fflush(0);
if( !bWasSignal ){
printf("ERROR !!! No pthread_cond_signal called !!!\n");fflush(
}
}
pt->_h->Select( 0, 20000 );
5/ na koncu CEthCamera::SendCmd dodalem :
if( cmd0x08 ){
printf("NudpSocket state =
%d\n",_comm->GetState());
}
ciekawe czy w zwisie bedzie 17 , a potem wpadnie w zwis, czyli w
miedzyczsie to przeczysci
6/ dodalem kolejnego printfa :
if ( !_comm->SendCmd( src_number, src_data,
src_data_length, src_top ) )
{
if ( cmd0x08 )
_comm->StopData();
sprintf( log_buf,
"CEthCamera::SendCmd() (number field = %.8X):\nCommand
LogErr( log_buf );
printf("Command not sent - zwis ???\n");fflush(0);
return false;
}
bo moze z jakis powodow jednak sie do Error-loga nie zapisalo to wyzej
i dlatego nie widac ze tak naprawde comenda 0x08 sie nie wyslala
i dlatego Nudp ma state=1
Przy zwisie sie to nie wypisalo !, czyli to jest ok , wyglada ze
komenda sie wykonuje poprawnie
7/ dodalem jeszcze jednego printfa,
zobaczymy teraz
if ( !_comm->SendCmd( src_number,
src_data, src_data_length, src_top )
{
if (
cmd0x08 ) _comm->StopData();
sprintf( log_buf, "CEthCamera::SendCmd() (number field = %.8X):\nCo
LogErr( log_buf );
printf("Command not sent - zwis ???\n");fflush(0);
return false;
}else{
if(
cmd0x08 ){
printf("SendCmd cmd0x08 OK\n");fflush(0);
}
}
Ciekawe czy sie wypisze - powinien przy zwisie sie wypisac inaczej to
by znaczylo ze wogole nie wykonal SendCmd !
8/ dodalem kolejnego printf-a teraz trzeba sprawdzic oba ^ tego
wyzej i tego , w tym kawalku :
else if ( (state & 0x0F) ==
NUDP_READY )
{
repeat = false;
if (
cmd0x08 ) _data_taking = true;
sprintf( log_buf, "CEthCamera::SendCmd() (number field =
%.8X):\nOK.
Log( log_buf );
if(
cmd0x08 ){
if( !(state & NUDP_DATA) ){
printf("ERROR!!!!!!
- incorrect state after 0x08 !!!\n
}
}
}
To by znaczylo , ze 0x08 zostala niby dobrze wyslana , a
mimo to state nie jest na NUDP_DATA - to jest blad w kodzie !!!
No tak jest wlasnie tak wypisalo sie ze :
SendCmd cmd0x08 OK
AsynchroAstro FAILED
on camera 0
waiting 20 sec for
next frame ..
ERROR!!!!!! - incorrect state
after 0x08 !!!
I juz jest zwis !!! Czyli state w NudpSocket sie nie
zmienil , czemu ?????????????????????????
9/ kolejny printf w NudpSocket::SendCmd , sekwencja jest taka :
Transfer FAILED : Packets# = 8024 , expected = 8248
Number of lost packages 224 exceeds limit of 1
Repeating GetData of whole image
Before SendCmd 8 0 0 0
cmd0x08
//previously was transfer
- After Select !
NudpSocket::SendCmd(0x08)
return true _state=18
SendCmd
cmd0x08 OK
//////////////////////////////////////////////////////////////////////////////
185 pixels above treshold Tn=0 ADU
ret=0
FAST_PHOTOMETRY stars# = 122
OK
ASTROMETRY : to few stars 122 ( limit is 1000 )
identified on frame, astrometry
FAILED - on star number check
cleaning FITS/MAG/AST used for astrometry ...
ERROR!!!!!! -
incorrect state after 0x08 !!!
NudpSocket state = 1
SendCmd ret=1
kod z printfami debugujacymi jest tutaj zbackupowany :
/opt/pi/dev/pisys/daq/ndir//install/12_12_2005/source.tar.gz
- 2005 - 12 - 11
1/ nowa wersja drievera pada na linii 406 w CEthCamera.cpp :
pt->LogErr( "CEthCamera::BkgListener():\nStill
waiting for data...\n\n" );
Wprowadzilem poprawke gmtime -> gmtime_r w Log i LogErr
:
//
struct tm *t = gmtime( &now );
struct tm tm_s;
gmtime_r( &now,
&tm_s );
struct tm *t = &tm_s;
Testuje moze to pomoze ...Nie pomoglo wywali sie na :
(gdb) bt
#0 0x009477a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x03e36e49 in raise () from /lib/tls/libc.so.6
#2 0x03e38872 in abort () from /lib/tls/libc.so.6
#3 0x060717aa in TUnixSystem::Abort () from
/opt/pi/ext/dload/root/lib/libCore.so
#4 0x06070124 in TUnixSystem::DispatchSignals ()
from /opt/pi/ext/dload/root/lib/libCore.so
#5 0x0606f0af in SigHandler () from
/opt/pi/ext/dload/root/lib/libCore.so
#6 0x0607362f in sighandler () from
/opt/pi/ext/dload/root/lib/libCore.so
#7 <signal handler called>
#8 0x00667224 in ?? () from
/opt/pi/dev/pisys/daq/ndir//slib/libpicamdrv.a
#9
0x0067ae01 in CEthCamera::BkgListener (pthis=0x8a61e58) at
CEthCamera.cpp:394
#10 0x0036998c in start_thread () from /lib/tls/libpthread.so.0
#11 0x03ecb16a in clone () from /lib/tls/libc.so.6
- 2005 - 12 - 10
1/ Wyglada na to ze zwis nastepuje na WaitForRawData , dodalem printfa
przed tym :
before WaitForRawData ...
Transfer OK : Packets# = 8248 ,
expected = 8248
After WaitForRawData
Jesli to zwis na tym to wypisze sie tylko 1 linijka
- ciekawe do rana powinno sie okazac ...
2/ 15:17 Robert ma nowa wersje , sprawdzic ja - wywalic to StopData -
powinno przestac byc potrzebne, zobaczyc z max=1 czy bedzie juz dobrze
3/ 15:46 Nowa wersja Roberta daje poprawe , nie potrzeba robic StopData
zeby powtorzyc transmisje ( wczesniej pisal w logach ze jest w trakcie
wykonywania 0x08 i nie moze jej po razu drugi zrobic
) . Wywalilem StopData i na razie dziala ...
4/ w
cam_driver.err jest wpis : RAW data packet #2179 (offset=220C00)
duplicated
Oznacza to ze kamera wyslala 2 razy ten sam pakiet - spytac GK
czemu tak sie stalo ?
5/ Niestety o godzine 17:03 driver zwisl
na komendzie WaitForRawData , nie wiadomo na razie dlaczego - logi
out20051210a cam_driver.err.20051210a
6/ zawartosc stosu w zwisie :
(gdb) bt
#0 0x009477a2 in _dl_sysinfo_int80 () from
/lib/ld-linux.so.2
#1 0x00329790 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#2 0x001dbf80 in CEthCamera::WaitForRawData
(this=0x9b9dbc0) at CEthCamera.cpp:427
#3 0x001d9dbf in
DeviceEth2K2K::GetDataInternal (this=0x9bc2b00,
buffer=0xef4d0008 "",
size=8445952, recur_level=0) at DeviceEth2K2K.cpp:325
#4 0x001d9c9b in DeviceEth2K2K::GetData
(this=0x9bc2b00, buffer=0xef4d0008 "",
size=8445952) at
DeviceEth2K2K.cpp:294
#5 0x00abc6a9 in RunCollectingThread_New
(pPtr=0x9b9e4c8) at ccd_controller.cpp:693
#6 0x0032698c in start_thread () from
/lib/tls/libpthread.so.0
#7 0x039db16a in clone () from
/lib/tls/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread -490615888 (LWP
21834))]#0 0x009477a2 in _dl_sysinfo_int80 () from
/lib/ld-linux.so.2
(gdb) bt
#0 0x009477a2 in _dl_sysinfo_int80 () from
/lib/ld-linux.so.2
#1 0x039d3e61 in ___newselect_nocancel () from
/lib/tls/libc.so.6
#2 0x0806e20d in SocketHandler::Select
(this=0x9b9a7c8, sec=-514, usec=-514)
at SocketHandler.cpp:279
#3 0x001dbecc in CEthCamera::BkgListener
(pthis=0x9b9dbc0) at CEthCamera.cpp:410
#4 0x0032698c in start_thread () from
/lib/tls/libpthread.so.0
#5 0x039db16a in clone () from
/lib/tls/libc.so.6
(gdb)
(gdb) bt
#0
0x009477a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1
0x039a6446 in __nanosleep_nocancel () from /lib/tls/libc.so.6
#2
0x039a626f in sleep () from /lib/tls/libc.so.6
#3
0x001dd155 in RefreshThread::EntryPoint (pthis=0x9b88ff0) at
CEthCamera.cpp:717
#4
0x0032698c in start_thread () from /lib/tls/libpthread.so.0
#5
0x039db16a in clone () from /lib/tls/libc.so.6
(gdb) c
- 2005 - 12 - 09
1/ 0xAA nie dziala i wiesza kamere - wyslalem maila do GK , zmienilem w
device.cfg zeby wylaczyc sprawdzanie full status tymczasowo :
CCD_READ_FULL_STATUS_FREQ=-100
2/ czasem kamera wpada w zwis przy czytaniu brakujacych i wyglada to
tak ze trwa to nawet >60 sec - co znaczy ze moze
ona sie resetuje w tym czasie ??? Dlaczego
CEthCamera.cpp nie wypada na jakims timeoucie ?
3/ wyglada ze dziala calkiem niezle ( przy wylaczonym pytaniu o pelny
status ) to moze to to pytanie o pelny status tak psuje czasem ???
Np wchodzi w jakis konflikt z odpowiedzia na
odswiezanie watchdog-a ??? - spytac RS
4/ dalsze wyniki dodalem printfa w
ReadMissing i widze ze zawislo na :
doing i=3883
natomiast w error logu jest :
19:38:32:
CEthCamera::ReadMissing():
Packet #3882 retransmitted.
19:38:32:
CEthCamera::BkgListener():
RAW data timeout.
19:39:37:
CEthCamera::ReadMissing():
Packet #3883 retransmitted.
Ten log wskazuje ze to kamera sle dane a mu czytamy pojedyncze
pakiety !!!
5/ Sprawdzam taka sekwencje :
// temporary check - NEW :
printf("Calling StopData ...\n");fflush(0);
m_pEthCamera->StopData();
printf("sending 0x09 ( stop trnasfer ) first ...\n");fflush(0);
int
reset_ret = SendBytes_1( 0x01 , 0x09 );
printf("reset returned ret=%d\n",reset_ret);fflush(0);
ReadMissing
bo wyglada na to ze czasem wychodzi z
WaitForData mimo ze wcale nie skonczyl !!! ( punkt 4/ powyzej ! )
Stad probuje zrobic StopData i dopiero czytac
missing pakiety . Wyglada na razie ze jest ok - tzn nie ma zwisow
powyzej 5 sec przy ReadMissing !
- 2005 - 12 - 07
Wyszly takie rzeczy :
1/ 0xAA powoduje te problemy z przeplotem komend ,
driver dostaje czasem odpowiedz na 0xAA jak czeka juz na odpowiedz z
innej komendy
Okazuje sie ze 0xAA
zajmuje 2 sec , w tym czasie jak kamera dostanie inna komende to na nia
odpowie , a driver moze pojsc w buraki ,
bo najpierw oczekuje
odpowiedzi na 0xAA !!!
Stad dodalem sleep po
0xAA zeby poczekac na odpwiedz kamery zanim wysle jakakolwiek inna
komende
2/ jak zrobic przerwanie transmisji z kamery ? - czy
jest odpowiednia komenda ?
Odpowiedz GK : jest to
0x09 - dodalem do dokumentacji
3/
heplx43:/opt/pi/dev/pisys/daq/ndir/results/EthTest/RealCAM
cam_driver.err.bug1:koniec pliku sync_opt.out.bug1: 50618- tu jest to
ze uznal ze SendCmd( 0x08 )
failed , bo (chyba?) inna 0x08 jest wykonywana - tymczasem ReadMissing
sie skonczylo i wygladalo na to ze nie jest ...
- 2005 - 12 - 06
- RS , blad taki sie robi :
buf = 4294967295 0
4294967168 4294967254 4294967210 0 0 0
_chk_header = 4294967295 0
4294967168 116 12 0 0 0
ffffffff 00 ffffff80
ffffffd6 ffffffaa 00 00 00
ffffffff 00 ffffff80 74 0c
00 00 00
TESTY - uwagi, dodac na WWW :
- 0xAA - full status check
zajmuje troche czasu i trzeba na nia
poczekac dluzej
bo inaczej jak pojdziemy to kamera
wysle odpowiedz
pozniej a my ja odbierzy jako odpowiedz na
cos innego i na
checksum-ie sie wywali
- 0xAA - jak sie za dlugo
czeka to Asynchro mode nie nadaza
sciagnac klatki
przed koncem naswietlenia ( moze trzeba
troche
zmniejszyc czas oczekiwania na 0xAA do 1sec ( z 2 sec )
- 2005 - 11 - 25
Grzesiek Kasprowicz mowi ze jak transfer danych sie opoznia to nalezy
go przerwac ( komenda 0x09 ) i poprosic ponownie o klatke