Re: SSN-688
: 20 maja 2011, 11:58
A już myślałem że to taki Luke Perry(Szkop):
- szczególnie, że szkopy (nawet jak się nazywają Perry) mnie nie pociągają...Forum Koga • Strona główna - Koga Portal - Modele - Żaglowce - Statki - Okręty - Forum modelarskie
Strona poświęcona modelarstwu szkutniczemu, historii żeglugi, żaglowcom, statkom i okrętom. Forum, galeria, wirtualna modelarnia. Serdecznie zapraszamy!
https://mail.koga.net.pl/phpbb3/
SSN-688
Strona 86 z 101
Re: SSN-688
: 20 maja 2011, 16:15
full satysfaction...no może mniej niż np po jedzeniu - szczególnie, że szkopy (nawet jak się nazywają Perry) mnie nie pociągają...
- szczególnie, że szkopy (nawet jak się nazywają Perry) mnie nie pociągają...Re: SSN-688
: 22 maja 2011, 17:48
Witam
No i zdarzyło się. Jeden z licznych przewodów łączących górną połówkę z dolną dostał się
pomiędzy połówki w trakcie skręcania. Przewody są cienkie, to i szczelina niewielka była.
Ale wystarczająca aby w ciągu paru sekund do wnętrza modelu wlała się setka wody.
Straty są ale stosunkowo małe. Komputer zdaje się nie uległ (co tam jedna setka).
Tylko uszczelka do wymiany - jeszcze na stanie. Na całe szczęście działał
czujnik WOB (water on the board) i wyjąłem model z wody zanim całkiem zatonął.
Ale zmusiło mnie to, do wynalezienia sposobu, oraz takiej konstrukcji, aby na przyszłość to
zdarzyć się nie mogło. Przy okazji wyszło, że inklinometr (ten do góry brzuchem z przylutowanymi
przewodami) może ulec uszkodzeniu gdy nacisną go przewody, których górą (nad nim) idzie
całe wiadro.
Zająłem się więc mikroelektroniką, a w tym wypadku, wytwarzaniem obudowy
do układu scalonego. Obudowa z polistyrenu 0.5 mm i wygląda tak :
Po zamontowaniu na płycie :
Teraz pozostało wymyśleć płot, który poważnie utrudni niesfornym przewodom włażenie
na krawędzie kadłuba przy skręcaniu.
Pierwszy pomysł jest taki, aby przewody połączyć w taśmę, która będzie miała wbudowaną
natruralną sztywność w kierunku na boki. Drugi pomysł to zbudowanie 10 milimetrowego płotu
na newralgicznych krawędziach płyty głównej w celu uniemożliwienia wyłażenia przewodów.
O efektach lub ich braku wkrótce.
Z ukłonami
Andrzej Korycki
No i zdarzyło się. Jeden z licznych przewodów łączących górną połówkę z dolną dostał się
pomiędzy połówki w trakcie skręcania. Przewody są cienkie, to i szczelina niewielka była.
Ale wystarczająca aby w ciągu paru sekund do wnętrza modelu wlała się setka wody.
Straty są ale stosunkowo małe. Komputer zdaje się nie uległ (co tam jedna setka).
Tylko uszczelka do wymiany - jeszcze na stanie. Na całe szczęście działał
czujnik WOB (water on the board) i wyjąłem model z wody zanim całkiem zatonął.
Ale zmusiło mnie to, do wynalezienia sposobu, oraz takiej konstrukcji, aby na przyszłość to
zdarzyć się nie mogło. Przy okazji wyszło, że inklinometr (ten do góry brzuchem z przylutowanymi
przewodami) może ulec uszkodzeniu gdy nacisną go przewody, których górą (nad nim) idzie
całe wiadro.
Zająłem się więc mikroelektroniką, a w tym wypadku, wytwarzaniem obudowy
do układu scalonego. Obudowa z polistyrenu 0.5 mm i wygląda tak :
Po zamontowaniu na płycie :
Teraz pozostało wymyśleć płot, który poważnie utrudni niesfornym przewodom włażenie
na krawędzie kadłuba przy skręcaniu.
Pierwszy pomysł jest taki, aby przewody połączyć w taśmę, która będzie miała wbudowaną
natruralną sztywność w kierunku na boki. Drugi pomysł to zbudowanie 10 milimetrowego płotu
na newralgicznych krawędziach płyty głównej w celu uniemożliwienia wyłażenia przewodów.
O efektach lub ich braku wkrótce.
Z ukłonami
Andrzej Korycki
Re: SSN-688
: 22 maja 2011, 19:21
Trudne to życie podwodniaka 
Re: SSN-688
: 24 maja 2011, 10:42
Witam
LAla błędów nie wybacza, dlatego ciężkie jest życie kataryniarza w Wielkim
Poście jak mu zdechnie papuga.
Dzisiaj rano kable łączące górę z dołem wyglądały tak :
Widać nieznaczną poprawę w stosunku do dni poprzednich.
Przy założeniu, że docelowo tej cienkiej niebiesko-czerwonej taśmy nie będzie,
widok jest już całkiem znośny.
Pozostała kontrola napięcia akumulatorów, ewentualne ładowanie.
Ładowanie zawsze wykonuję w ten sposób, że ładowarka rozładowuje
akumulatory do minimum napięcia (NiMh 0.9V na celę) i ładuje
od nowa. Prąd rozładowania troszkę więcej niż dziesięciogodzinny.
Ta kontrola jest potrzebna, bo elektronika zbiorników zachowuje się
źle gdy napięcie jest poniżej 8V. Ile poniżej tego nie wiem.
Gdy będę szukał błędów w programie, Gura będzie szukał przyczyn
w elektronice.
Z ukłonami
Andrzej Korycki
LAla błędów nie wybacza, dlatego ciężkie jest życie kataryniarza w Wielkim
Poście jak mu zdechnie papuga.
Dzisiaj rano kable łączące górę z dołem wyglądały tak :
Widać nieznaczną poprawę w stosunku do dni poprzednich.
Przy założeniu, że docelowo tej cienkiej niebiesko-czerwonej taśmy nie będzie,
widok jest już całkiem znośny.
Pozostała kontrola napięcia akumulatorów, ewentualne ładowanie.
Ładowanie zawsze wykonuję w ten sposób, że ładowarka rozładowuje
akumulatory do minimum napięcia (NiMh 0.9V na celę) i ładuje
od nowa. Prąd rozładowania troszkę więcej niż dziesięciogodzinny.
Ta kontrola jest potrzebna, bo elektronika zbiorników zachowuje się
źle gdy napięcie jest poniżej 8V. Ile poniżej tego nie wiem.
Gdy będę szukał błędów w programie, Gura będzie szukał przyczyn
w elektronice.
Z ukłonami
Andrzej Korycki
Re: SSN-688
: 25 maja 2011, 23:30
Witam
Oto efekt dzisiejszej pracy :
Zestawione stanowisko do testowania okrętów podwodnych w piwnicy :
i wynik testowania :
Za chwilę będę wiedział ... co poprawić w programie aby się dowiedzeć tego co chcę.
Z ukłonami
Andrzej Korycki
[Edit]
Następnego dnia rano :
Po dłuższym poszukiwaniu błędu w programie, znalazłem.
Otóż kompilator GCC nie potrafi porównywać z zerem zmiennych typu char (jednobajtowych).
Z moich trzydziestoletnich doświadczeń wynikało, że :
char c;
c = -10;
if ( c < 0 )
{// będzie wykonane zawsze. A tu kupa. c było traktowane jak liczba dodatnia.
// stąd krzywe zanurzanie okrętu i reszta kłopotów.
}
Zmienne typu char trzeba zastąpić wydumanym typem int8_t, też jednobajtowym i dopiero wszystko działa jak się przynależy.
Za to mam teraz inny problem :
Otóż okręt jest trochę za lekki. Trzeba go dociążyć, bo zbiorniki opierają się o krańcówki
i chcą dalej a tu nie ma pojemności. Trzeba wykonać kopytko z gipsu, odlać parę małych ciężarków
i włożyć je do okręta.
Z ukłonami
Andrzej Korycki
[End of Edit]
Oto efekt dzisiejszej pracy :
Zestawione stanowisko do testowania okrętów podwodnych w piwnicy :
i wynik testowania :
Za chwilę będę wiedział ... co poprawić w programie aby się dowiedzeć tego co chcę.
Z ukłonami
Andrzej Korycki
[Edit]
Następnego dnia rano :
Po dłuższym poszukiwaniu błędu w programie, znalazłem.
Otóż kompilator GCC nie potrafi porównywać z zerem zmiennych typu char (jednobajtowych).
Z moich trzydziestoletnich doświadczeń wynikało, że :
char c;
c = -10;
if ( c < 0 )
{// będzie wykonane zawsze. A tu kupa. c było traktowane jak liczba dodatnia.
// stąd krzywe zanurzanie okrętu i reszta kłopotów.
}
Zmienne typu char trzeba zastąpić wydumanym typem int8_t, też jednobajtowym i dopiero wszystko działa jak się przynależy.
Za to mam teraz inny problem :
Otóż okręt jest trochę za lekki. Trzeba go dociążyć, bo zbiorniki opierają się o krańcówki
i chcą dalej a tu nie ma pojemności. Trzeba wykonać kopytko z gipsu, odlać parę małych ciężarków
i włożyć je do okręta.
Z ukłonami
Andrzej Korycki
[End of Edit]
Re: SSN-688
: 26 maja 2011, 21:02
Witam
Teraz LAla w majtkach pływa tak :
http://www.youtube.com/watch?v=yeaNZ7sDpXg
W majtkach znajduje się dodatkowe obciążenie, które muszę dołożyć.
Z ukłonami
Andrzej Korycki
Teraz LAla w majtkach pływa tak :
http://www.youtube.com/watch?v=yeaNZ7sDpXg
W majtkach znajduje się dodatkowe obciążenie, które muszę dołożyć.
Z ukłonami
Andrzej Korycki
Re: SSN-688
: 26 maja 2011, 21:41
Andrzeju cóż Ty masz za piwnice ? ze okręt podwodny w niej zmieścisz ?
Piękny to widok jak Lalunia się zanurza , głośne są te mechanizmy wewnątrz ? czy to tylko taki pogłos w piwnicy jest?
Piękny to widok jak Lalunia się zanurza , głośne są te mechanizmy wewnątrz ? czy to tylko taki pogłos w piwnicy jest?
Re: SSN-688
: 26 maja 2011, 22:20
Z tego co wiem zmienne typu char są przypisane do obsługiwania łańcuchów literowych, tablic, i innych danych gdzie trzeba obsłużyć działanie na łańcuchach znakowych, dlatego też nawet jeżeli zmiennej tego typu nadamy sztucznie wartość cyfrową, to się może nie udać porównywanie zmiennej znakowej ze zmienną cyfrową, a czasami wręcz program wykrywa błąd i nie chce się skompilować nawet. Zmiana typu zmiennej na int który jest zmienną cyfrową powinien faktycznie rozwiązać problem.
Majty świetne, choć lala to raczej jako nowoczesna na wskroś powinna być wyposażona w stringi.
edit: zwykła zmienna typu int też jest oparta na rejestrze 8 bitowym, ale jeżeli używając zmiennej typu char też ci wszystko chodzi to ok, moje obawy dotyczą tego że może się to czasem wykrzaczyć przy wykonywaniu jakichś procedur, bo pomimo że zmiennej char nadajesz określoną wartość to gdzieś w podprocedurach może być potraktowana jako zmienna znakowa i wyjdzie że program będzie usiłował porównać wartości pętli nie z liczbą podstawioną pod zmienną char, tylko ze znakiem z tablicy ASCI odpowiadajacym wartości podstawionej liczby. I wtedy wyjdzie taki mały zonk bo się wywali.
Malutka uwaga: generalnie 8bitowa zmienna może być albo w zakresie 0-256 gdzie całe 8 bitów jest przeznaczone na liczbę, lub w zakresie (-128)do(128) gdzie 7 bitów przeznaczone jest na liczbę a 8 bit zawiera znak.
Stosując zakres zamiast -90 do 90, można zastosować zakres 0 do 180, asembler procesora oszczędza przy każdej operacji dodawania i odejmowania jedną operację sprawdzenia i przepisania znaku, ponieważ dostaje w rejestrze za każdym razem zmienna dodatnią i od razu wykonuje działanie bez operacji sprawdzania znaku zmiennej.
Majty świetne, choć lala to raczej jako nowoczesna na wskroś powinna być wyposażona w stringi.
edit: zwykła zmienna typu int też jest oparta na rejestrze 8 bitowym, ale jeżeli używając zmiennej typu char też ci wszystko chodzi to ok, moje obawy dotyczą tego że może się to czasem wykrzaczyć przy wykonywaniu jakichś procedur, bo pomimo że zmiennej char nadajesz określoną wartość to gdzieś w podprocedurach może być potraktowana jako zmienna znakowa i wyjdzie że program będzie usiłował porównać wartości pętli nie z liczbą podstawioną pod zmienną char, tylko ze znakiem z tablicy ASCI odpowiadajacym wartości podstawionej liczby. I wtedy wyjdzie taki mały zonk bo się wywali.
Malutka uwaga: generalnie 8bitowa zmienna może być albo w zakresie 0-256 gdzie całe 8 bitów jest przeznaczone na liczbę, lub w zakresie (-128)do(128) gdzie 7 bitów przeznaczone jest na liczbę a 8 bit zawiera znak.
Stosując zakres zamiast -90 do 90, można zastosować zakres 0 do 180, asembler procesora oszczędza przy każdej operacji dodawania i odejmowania jedną operację sprawdzenia i przepisania znaku, ponieważ dostaje w rejestrze za każdym razem zmienna dodatnią i od razu wykonuje działanie bez operacji sprawdzania znaku zmiennej.
Re: SSN-688
: 26 maja 2011, 23:09
Witam
Ryszardzie, rzeczywiście mechanizmy pracują głośno. Ale przenoszą dość duże siły i wykorzystane
zostały kółka z wibratorów wyznaczające konstrukcję pozostałych kól. Wyeliminowało to koła
o skośnych zębach. Proste zęby są głośne i ładne ....
Masz słusznego Mariuszu, ale ...
Każdy znak ma przypisaną "sztucznie" wartość liczbową .
W ASCII jest to tak :
Sory, ale część znaków się nie wyświetla poprawnie.
Extended ASCII zawiera resztę znaków do 255.
W mikrokontrolerach jest tak, że zmienne jednobajtowe są bardziej regułą niż wyjątkiem.
Powody są take :
1. Ograniczona ilość pamięci w procesorze.
2. Ograniczona wielkość stosu.
3. Najkrótszy z możliwych czas operacji na takiej zmiennej. Tylko jeden bajt pamięci.
4. Na czas odczytu takiej zmiennej (modyfikowanej w przerwaniu) NIE trzeba blokować
przerwań, bo odczyt odbywa się w jednej operacji (assemblerowej), która nie ulegnie
przerwaniu (jak się już zaczęła).
5. Bardzo często zakres oferowany przez zmienną char (-128...+127 za K&R) wystarcza.
U mnie inklinacja (przechył dziób/rufa) zmienia się w zakresie (-90 + 90)
6. W mikrokontrolerach często tablice mają mniej niż 255 elementów. Jakże ponętne jest
użycie jednobajtowej zmiennej kontrolnej pętli (unsigned char). Szybkie łatwe i przyjemne.
Można pewnie znaleźć inne (powody), ale czy nie starczy ?
I wreszcie dlaczemu wprowadzono dwa typy : char i unsigned char ?
Mają się różnić tylko nazwą ? nie sądzę. Dla mnie, to ewidentna niedoróbka GCC.
Dlatego, w LAli, zawsze gdzie mogę, stosuję zmienne typu char lub unsigned char (0...255).
Kompilator Visual Studio 2003 ( i wszystkie poprzednie do VC6) kompilują zgodnie z moimi
oczekiwaniami następujący kod (przed chwilą sprawdziłem) :
char c;
c = -10;
if ( c < 0 )
{// to się wykonuje
int i = c;
int k = i;
}
To co piszesz o ewentualnych błędach kompilacji może wynikać :
a) z przekroczenia zakresu zmiennej char :
char c;
c = 12000; // powinno wykryc błąd
MSVC2003 daje warninga : warning C4309: '=' : truncation of constant value
Podstawienie c = 12; przechodzi bez komentarza.
b) z ewentualnego braku rzutowania stałej int na typ char.
char c;
c = (char)12000; // nie powinno wykryć błędu mimo, że jest, ale wyraźnie zamierzony przez programistę
MSVC2003 nie sygnalizuje nic.
O ile pamiętem, kompilator C Keil'a dla 8051 też tak działa. Zresztą procesor Z80, wydaje mi się,
też miał operacje assemblerowe, ze znakiem i bez, na ośmiobitowych rejestrach. Co do Z80 mogę
się mylić - to było tak dawno.
Z ukłonami
Andrzej Korycki
[Edit]
Język ANSI C, Brian W. Kernighan, Dennis M. Ritchie, WNT, ISBN 83-204-2979-X na stronie 62
podaje :
To czy zwykły obiekt typu char jest liczbą ze znakiem czy bez znaku, zależy od maszyny ....
Z tego wynika, że moje zarzuty do GCC są bezpodstawne, a błąd wynikał ze zwykłej rutyny
i był tak głupi jak wszystkie znalezione błędy. A typ int8_t zagości na dobre w mózgu LAli.
Z ukłonami
Andrzej Korycki
[End of Edit]
Ryszardzie, rzeczywiście mechanizmy pracują głośno. Ale przenoszą dość duże siły i wykorzystane
zostały kółka z wibratorów wyznaczające konstrukcję pozostałych kól. Wyeliminowało to koła
o skośnych zębach. Proste zęby są głośne i ładne ....
Masz słusznego Mariuszu, ale ...
Każdy znak ma przypisaną "sztucznie" wartość liczbową .
W ASCII jest to tak :
Kod: Zaznacz cały
NUL 00 00 + 2B 43 V 56 86
SOH 01 01 , 2C 44 W 57 87
STX 02 02 - 2D 45 X 58 88
ETX 03 03 . 2E 46 Y 59 89
EOT 04 04 / 2F 47 Z 5A 90
ENQ 05 05 0 30 48 [ 5B 91
ACK 06 06 1 31 49 \ 5C 92
BEL 07 07 2 32 50 ] 5D 93
BS 08 08 3 33 51 () 5E 94
HT 09 09 4 34 52 -() 5F 95
LF 0A 10 5 35 53 ‘ 60 96
VT 0B 11 6 36 54 a 61 97
FF 0C 12 7 37 55 b 62 98
CR 0D 13 8 38 56 c 63 99
SO 0E 14 9 39 57 d 64 100
SI 0F 15 : 3A 58 e 65 101
DLE 10 16 ; 3B 59 f 66 102
DC1(X-ON) 11 17 < 3C 60 g 67 103
DC2(TAPE) 12 18 = 3D 61 h 68 104
DC3(X-OFF) 13 19 > 3E 62 i 69 105
DC4 14 20 ? 3F 63 j 6A 106
NAK 15 21 @ 40 64 k 6B 107
SYN 16 22 A 41 65 l 6C 108
ETB 17 23 B 42 66 m 6D 109
CAN 18 24 C 43 67 n 6E 110
EM 19 25 D 44 68 o 6F 111
SUB 1A 26 E 45 69 p 70 112
ESC 1B 27 F 46 70 q 71 113
FS 1C 28 G 47 71 r 72 114
GS 1D 29 H 48 72 s 73 115
RS 1E 30 I 49 73 t 74 116
US 1F 31 J 4A 74 u 75 117
SP 20 32 K 4B 75 v 76 118
! 21 33 L 4C 76 w 77 119
„ 22 34 M 4D 77 x 78 120
# 23 35 N 4E 78 y 79 121
$ 24 36 O 4F 79 z 7A 122
% 25 37 P 50 80 { 7B 123
& 26 38 Q 51 81 | 7C 124
‘ 27 39 R 52 82 }(Alt MODE) 7D 125
( 28 40 S 53 83 ~ 7E 126
) 29 41 T 54 84 DEL 7F 127
* 2A 42 U
Sory, ale część znaków się nie wyświetla poprawnie.
Extended ASCII zawiera resztę znaków do 255.
W mikrokontrolerach jest tak, że zmienne jednobajtowe są bardziej regułą niż wyjątkiem.
Powody są take :
1. Ograniczona ilość pamięci w procesorze.
2. Ograniczona wielkość stosu.
3. Najkrótszy z możliwych czas operacji na takiej zmiennej. Tylko jeden bajt pamięci.
4. Na czas odczytu takiej zmiennej (modyfikowanej w przerwaniu) NIE trzeba blokować
przerwań, bo odczyt odbywa się w jednej operacji (assemblerowej), która nie ulegnie
przerwaniu (jak się już zaczęła).
5. Bardzo często zakres oferowany przez zmienną char (-128...+127 za K&R) wystarcza.
U mnie inklinacja (przechył dziób/rufa) zmienia się w zakresie (-90 + 90)
6. W mikrokontrolerach często tablice mają mniej niż 255 elementów. Jakże ponętne jest
użycie jednobajtowej zmiennej kontrolnej pętli (unsigned char). Szybkie łatwe i przyjemne.
Można pewnie znaleźć inne (powody), ale czy nie starczy ?
I wreszcie dlaczemu wprowadzono dwa typy : char i unsigned char ?
Mają się różnić tylko nazwą ? nie sądzę. Dla mnie, to ewidentna niedoróbka GCC.
Dlatego, w LAli, zawsze gdzie mogę, stosuję zmienne typu char lub unsigned char (0...255).
Kompilator Visual Studio 2003 ( i wszystkie poprzednie do VC6) kompilują zgodnie z moimi
oczekiwaniami następujący kod (przed chwilą sprawdziłem) :
char c;
c = -10;
if ( c < 0 )
{// to się wykonuje
int i = c;
int k = i;
}
To co piszesz o ewentualnych błędach kompilacji może wynikać :
a) z przekroczenia zakresu zmiennej char :
char c;
c = 12000; // powinno wykryc błąd
MSVC2003 daje warninga : warning C4309: '=' : truncation of constant value
Podstawienie c = 12; przechodzi bez komentarza.
b) z ewentualnego braku rzutowania stałej int na typ char.
char c;
c = (char)12000; // nie powinno wykryć błędu mimo, że jest, ale wyraźnie zamierzony przez programistę
MSVC2003 nie sygnalizuje nic.
O ile pamiętem, kompilator C Keil'a dla 8051 też tak działa. Zresztą procesor Z80, wydaje mi się,
też miał operacje assemblerowe, ze znakiem i bez, na ośmiobitowych rejestrach. Co do Z80 mogę
się mylić - to było tak dawno.
Z ukłonami
Andrzej Korycki
[Edit]
Język ANSI C, Brian W. Kernighan, Dennis M. Ritchie, WNT, ISBN 83-204-2979-X na stronie 62
podaje :
To czy zwykły obiekt typu char jest liczbą ze znakiem czy bez znaku, zależy od maszyny ....
Z tego wynika, że moje zarzuty do GCC są bezpodstawne, a błąd wynikał ze zwykłej rutyny
i był tak głupi jak wszystkie znalezione błędy. A typ int8_t zagości na dobre w mózgu LAli.
Z ukłonami
Andrzej Korycki
[End of Edit]