ponoć ciekawosc to 1szy krok....

Pan Sebastian Biały napisał:

Ale to kernel był skopany. Więc wiadomo kto winny i gdzie poprawiać.

Toć mówię, że dobrze. Źle by było, gdyby skończyło się wcześniej.

Kernel został napisany w C. Czy w tej sytuacji należy powiedzieć:

1. C jest gównianym językiem. 2. A co to ma do rzeczy? 3. Masaj.

Wiem. Na szczęście ta mniejszość ma lepiej niż większość.

Nie mam potrzeby, jestem zadowolony z tego co jest. Ale jak jeden taki nie był zadowolony, to napisał.

Pan Sebastian Biały napisał:

Z dyskusji w tym wątku (ale też trochę z wcześniejszych obserwacji). A dokładnie z ignorowania wcześniej opisanych warunków przy formułowaniu własnych sądów.

Z użycia liczby mnogiej wywnioskowałem, że wypowiada się Pan w imieniu jakiejś grupy (chyba programistów).

Programowałem również wcześniej.

Jak już Pan zdążył zauważyć, jestem w mniejszości. Nigdy nie robiłem kodu embedded (choć zdarzało mi się pisać soft do urządzeń, które gdyby miały być produkowane w dłuższych seriach, to powinny taki kod otrzymać).

Mam się spodziewać, że zaraz zacznie Pan rzucać mięsem?

Więcej błędów powstaje przy tworzeniu założeń, a nawet przy określaniu wymagań. A jeśli nawet nie więcej, to są one bardziej istotne.

Bo ja nie oddam swego życia (a nawet rzeczy o wiele mniej cennych) w ręce koderów. Czasy Leonardów skończyły się wraz z Odrodzeniem, nie ma takich, co potrafią wszystko. Tak więc koderzy do kodowania, a ja nie łudzę się, że będą oni w stanie pojąć całość zagadnienia.

Moje gratulacje.

Świetnie. Widzę, że praca w zespole przynosi efekty.

Nie wszyscy potrafią wszystko.

Zawsze. Od początku Panu o tym mówiłem.

Po pierwsze, to w szpitalu umarł chłop na oko, szczególnie że szczegółów nie znasz.

Po drugie, zamiast wysnuć wniosek, że autor felernego rozwiązania miał niewielkie pojęcie o zapewnieniu bezpieczeństwa kolega wysuwa wniosek, że to LPT bee, no ciekawe, ciekawe, ale jakby pasujące do kolegi tezy.

Po trzecie, robienie sterownika na przysłowiowym Atmelku jest wbrew pozorom dość drogim oraz niebezpiecznym rozwiązaniem dla użytkownika końcowego. Szczególnie jak urządzenie ma pracować wiele lat. Też na początku swej kariery dziwiłem się, dlaczego w większych fabrykach i odpowiedzialniejszych zadaniach spuszcza się Atmelkowców na drzewo. Trochę doświadczenia i wszystko stało się jasne. A maszyny sterowane przez PC pracowały, pracują i pracować będą jeszcze wiele lat, niezagrożone, bezpieczne, tanie, modyfikowalne.

To "ciekawe" to ustalenia ekspertów powołanych do zbadania przyczyn wypadku. Osoba z którą rozmawiałem była w gronie tych ekspertów jako miejscowy automatyk.

Z kupą drutów na LPT ...

I mała uwaga: nie jestem zwolennikiem Atmelków.

W dniu 2011-09-16 20:39, Sebastian Biały pisze:

Pomijając kwestię sterowania z PC, sprzętowo układ sterowania też musiał być zupełnie spieprzony. Przy prawidłowo zaprojektowanych obwodach bezpieczeństwa nie ma możliwości by sterowanie procesowe (obojętnie czy to PLC czy PC) wymusiło przypadkowy ruch narzędzia prasy.

pozdrawiam

Ale to jedyny kernel jaki masz, bo starsze nie obslugują hardware a nowszych nie ma. Jesteś w dupie. Pozostaje rękodzieło, poprawianie buga po kimś. A miało być tak tanio a wyszlo jak zwykle.

Należy powiedzieć: kernel pisany jest przez przypadkowych ludzi tworzących jako-tako działajace oprogramowanie. Problem buga we własnym kodzie to tylko jeden z milionów miejsc gdzie coś się może popsuć. Przy czym w kernelu który poza obsługą LPT zajmuje się jednoczesnie obsługą chińskich myszek, chińskich kart sieciowych, chińskich mostków supportowanych dzięki reverse-engeneering i reakcją na pierdyliard przerwań na sekundę mamy poważne powody by nie dawać mu zadań od których wprost zależy czyjeś życie.

W przypadku Windowsa jest w sumie tak samo, może poza tym ze zamiast reverse-engeneering mamy "stabilizacje sterownikow poprzez sprzężenie zwrotne od userów".

I tak, jezyk C w embedded to gówno. Przy czym już kiedyś pisalem czemu.

Pan Sebastian Biały napisał:

Wiem gdzie jestem -- nie tam. Tu nie mamy takich problemów.

Brrr, wstrętne. To tak, jakby myć zęby cudzą szczoteczką do zębów. Na samą myśl robi mi się niedobrze.

Nie miało być tanio, miało być dobrze.

A ludzie powstali w wyniku przypadkowych mutacji DNA.

Ja nie lubię literatury s-f. Znana mi rzeczywistość wygląda inaczej.

W takim razie jeśli będę chciał wiedzieć co nie jest gównem, poszukam sobie w archiwach.

A jakie warunki były opisane? Bo ja się wtryniłem z butami w dyskusję która dawno wykraczala poza potrzebe inicjatora wątku i wy tam sobie wesoło ględziliście o wyższośc LPT nad atmelkami w sytuacjach ogólnych.

To bardzo wiele tłumaczy. Szczególnie styl: jak zabraknie argumentu to ucieczka w "za młody jesteś żeby pamiętać jak żeśmy z Józkiem klepali sterowniki na PDP w kodzie maszynowym na kartach perforowanych".

Wręcz przeciwnie, zazwyczaj to reakcja alergiczna strony przeciwnej na hasło "przeciez od dawna jest silne typowanie w C++" albo "po co tyle niebezpiecznego kodu, nie słyszaleś o RAII?".

Wow, to była szybka ucieczka w bok. Nie doceniałem doświadczenia usenetowego kolegi. Zapomniałeś jednak wyciąć cytatu, było by bardziej z sensem.

Oddajesz codziennie.

Jakim zespole?

Spodziewałem się raczej przykladu ale jak zwykle zostala tylko żałosna złośliwość.

Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do czegokolwiek. Podobnie jak i perl.

Nie znam szczegółów poza ogólnym ustaleniem przyczyn wypadku.

W dniu 2011-09-17 22:26, Grzegorz Krukowski pisze:

Maszyny *sterowane* przez PC to jednak wyjątki, PC'ty w automatyce zwykle służą wyłącznie jako HMI/wizualizacja procesu. A gdyby ktoś wpadł na pomysł budowy sterowania na pececie np. wcześniej wspomnianą prasą, to proponuję poczytać aktualną dyrektywę maszynową, i już będzie wiedział dlaczego jednak nie chce tego robić ;)

pozdrawiam

A co oznacza CNC?

Jakoś ciężko wyobrazić mi sobie maszynę sterowaną przez PLC. Fanuc może trochę przypomina podrasowany PLC. A jak zrobić HMI na czymś innym oprócz PC-ta?

Oprócz kasy to raczej mały problem. Najczęściej padają HDD, płyty praktycznie wcale.

Siemens stosuje (stosował) win XP, w starszych maszynach można spotkać DOS. Poza tym to własne. Jednak nie spotkałem się z tym co piszesz.

A ja takie problemy mam/miewam. Ale ja jestem szumem statystycznym.

Zajmuje czas, nie daje żadnych gwarancji. W przypadku systemow krytycznych jest skandaliczne/niebezpieczne.

Co jednoznacznie udowania wyższość kernela Linu... oh wait.

Tak. Developerzy Linuxa dostają pełną dokumentacje scalaków, a każdy z nich, bez wyjątku, pracuje zgodnie z nią. No i kod piszą automaty, bez żadnych bugow. I się budzisz.

Developerzy windowsa natomiast żadko zawracają sobie dupę pisaniem sterowników, przecież producent dostarczy.

Nie ma znaczenia styl developingu OS - jakoś kodu w obszarze zainteresowań automatyka w obydwu rozwiązaniach jest mizerna.

W dniu 2011-09-17 23:31, Sebastian Biały pisze:

A miałbyś możliwość zdobycia źródłowych materiałów, ewentualnie więcej szczegółów?

pozdrawiam

Sprobuje odszukać człowieka, ale przypuszczam że podobnie jak wtedy może dalej nie mieć prawa opowiadać o szczegółach ustaleń.

Pan Sebastian Biały napisał:

Nie mogę każdemu wszystkiego tłumaczyć i nakazywać jakie ma zająć stanowisko w dyskusji. Może sobie ględziliśmy wesoło, może o wyższości, ale jak się wchodzi w dyskusję (z butami lub bez), to dobrze jest robić to tak, by odnieść się do tego, co mówia inni. A nie po to, by zamianifestować swoje poglądy (uprzedzenia, kompleksy czy co to tam jest).

Wręcz przeciwnie -- niech teraz młodzi kodują, im to szybciej idzie, nie zastanawiają się nad każdą rzeczą, tylko piszą i idą do przodu. Wystarczy takimi pokierować, a efekty są znakomite.

Nie mam alergii, nawet na pyłki.

A co tu jest bez sensu?

Jeśli już, to bez udziału woli. To całkiem co innego. Ale gdy mogę, unikam takich sytuacji.

Jeden analizuje, drugi koduje -- tak jak napisano wyżej.

Przykłady (niepotrafienia) są wyżej. Więcej nie potrzeba.

Bash może być lepszą alternatywą dla perla, podobnie perl może być lepszą alternatywą dla basha.

Pierwszy raz na usenecie jesteś czy co? Jest rzeczą naturalną że gdybym chciał się odnieść do pierwtnego problemu to bym odpowiedział kilkanaście postown niżej. Ja tu tylko protestuje przed wciskaniem kombinacji pc+linux+bash do sterowania czegokolwiek. To niebezpieczne.

Używanie stwierdzeń z okolicy Captain Obvious unikając w ten sposób ustosunkowania się do czegokolwiek merytorycznie.

Stack overflow.

Pan Sebastian Biały napisał:

Współczuję. "A miało być tak pięknie."

Niektórzy tylko potrafią systematycznie krytykować. To im zajmuje cały czas.

Miało coś udowodnić? To co "należało powiedzieć" o kernelu też miało?

Jeśli mam podejrzenia, że super-duper scalak z USB czy czymś jeszcze nowszym ma bugi (w sobie lub w oprogramowaniu do niego) to wtedy używam na przykład starego sprawdzonego LPT.

Jest tu pewna symetria -- jakość pewnych automatyków oceniam jako mizerną. Wypadają poza obszar zainteresowań tak daleko, że nawet nie mam ochoty na sprawdzanie pisanego przez nich kodów.

Pan Sebastian Biały napisał:

Trzeb się odnisić do tego *co* piszą inni, a nie *o czym* piszą. Reakcje na zasadzie "piszą o bashu, to trzeba napisać, że bash jest gówniany", to są dobre w laboratorium Iwana Pietrowicza Pawłowa, a nie w Usenecie.

Ale tu nie można się ustosunkować merytorycznie inaczej niż w mniej jub bardziej delikatny sposób mówiąc: to są duby smalone. Poprzednio próbowałem delikatniej.

Parse error ("może", to co inego nić "jest"; nie ma języków bezwzględnie lepszych i bezwzględnie gorszych).

Ktorego nie ma we współczesnym PC. Chyba że chcesz użyć nowego niesprawdzonego LPT na PCI. A oczekuj przygody, moja karta LPT na PCI generowała śliczne szpileczki co każde restartowanie systemu (nawet nie wlaczenie zasilania). Wylądowała w końcu w smieciach jak się okazało że byle przepięcie uwaliło połowę portów. Aż się boje jakie przygody miewają osoby które LPT bawią się na codzień.