>> Większość maszyn CNC sterowanych jest przez PC - takiego standardowego.
>> Może tylko w lepszym wykonaniu.
>
> Przejście w automatyce na sterowanie przy pomocy standardowych PC uważam
> za jeden z najbardziej nietrafionych pomysłów.

A co oznacza CNC?

> Sterowniki PLC czy inne dedykowane rozwiązania potrafiły bezawaryjnie
> pracować 24/7 przez kilkanaście i więcej lat, pecet zwykle pada po kilku.

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?

> A jak już padnie to zaczyna się problem, bo w świecie pecetów elementy
> sprzed kilku lat są już trudno dostępną egzotyką. Wymiana sprzętu na
> nowszy powoduje konieczność kombinowania z oprogramowaniem, które często
> nie zadziała bez poprawek/uaktualnień z nowym hardwarem.

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

> Jeszcze gorzej gdy aplikacja sterująca zostanie napisana na windowsa,
> dochodzi "zabawa" z zabezpieczeniem antywirusowym, firewallami,
> uaktualnieniami itd.

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.

--
Desoft

do góry

On 2011-09-17 23:29, Jarosław Sokołowski wrote:
>> Ale to jedyny kernel jaki masz, bo starsze nie obslugują hardware a
>> nowszych nie ma. Jesteś w dupie.
> Wiem gdzie jestem -- nie tam. Tu nie mamy takich problemów.

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

>> Pozostaje rękodzieło, poprawianie buga po kimś.
> Brrr, wstrętne.

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

>> Należy powiedzieć: kernel pisany jest przez przypadkowych ludzi
>> tworzących jako-tako działajace oprogramowanie.
> A ludzie powstali w wyniku przypadkowych mutacji DNA.

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

>> 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.
> Ja nie lubię literatury s-f. Znana mi rzeczywistość wygląda inaczej.

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.

do góry

W dniu 2011-09-17 23:31, Sebastian Biały pisze:
>
> Nie znam szczegółów poza ogólnym ustaleniem przyczyn wypadku.

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

pozdrawiam

do góry

On 2011-09-17 23:39, Piotr wrote:
>> Nie znam szczegółów poza ogólnym ustaleniem przyczyn wypadku.
> A miałbyś możliwość zdobycia źródłowych materiałów, ewentualnie więcej
> szczegółów?

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

do góry

Pan Sebastian Biały napisał:

>>> Czekaj, skąd wytrzasnałeś brak umiejętności analizy założeń?
>> 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.
>
> 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.

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).

>>>>> NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania.
>>>> Z takim podejściem w ogóle nie ma co się zabierać za pisanie programu.
>>> Prezentujesz poziom zblizony do poglądow programistów z lat 80.
>> Programowałem również wcześniej.
>
> 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 -- 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.

>>> Widuje ich na codzień. Ta dyskusja wraca bardzo czesto i zazwyczaj
>>> kończy się na inwektywach.
>> Mam się spodziewać, że zaraz zacznie Pan rzucać mięsem?
>
> 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?".

Nie mam alergii, nawet na pyłki.

>>> Błedy lepiej blokować niż dopuszczać i debugować. Języki interpretowane
>>> i dynamicznie typowane nie potrafią blokować błedów poza trywialnymi w
>>> składni. Na tej planecie są całe stada programistów którzy sobie tego
>>> nigdy nie uświadomią.
>> 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.
>
> 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.

A co tu jest bez sensu?

>> Bo ja nie oddam swego życia (a nawet rzeczy o wiele mniej cennych)
>> w ręce koderów.
>
> Oddajesz codziennie.

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

>>> Bo doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć.
>> Świetnie. Widzę, że praca w zespole przynosi efekty.
>
> Jakim zespole?

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

>>> Pomimo tego nie potrafie nawet naszkicować zbioru warunków na które
>>> odpowiedzią byłby bash.
>> Nie wszyscy potrafią wszystko.
>
> Spodziewałem się raczej przykladu ale jak zwykle zostala tylko żałosna
> złośliwość.

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

>>> Zawsze jest lepsza alternatywa.
>> Zawsze. Od początku Panu o tym mówiłem.
>
> Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do
> czegokolwiek. Podobnie jak i perl.

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

--
Jarek

do góry

On 2011-09-17 23:53, Jarosław Sokołowski wrote:
> 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).

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.

>>> 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.
>> 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.
> A co tu jest bez sensu?

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

>> Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do
>> czegokolwiek. Podobnie jak i perl.
> Bash może być lepszą alternatywą dla perla, podobnie perl może być
> lepszą alternatywą dla basha.

Stack overflow.

do góry

Pan Sebastian Biały napisał:

>>> Ale to jedyny kernel jaki masz, bo starsze nie obslugują hardware a
>>> nowszych nie ma. Jesteś w dupie.
>> Wiem gdzie jestem -- nie tam. Tu nie mamy takich problemów.
>
> A ja takie problemy mam/miewam. Ale ja jestem szumem statystycznym.

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

>>> Pozostaje rękodzieło, poprawianie buga po kimś.
>> Brrr, wstrętne.
>
> Zajmuje czas, nie daje żadnych gwarancji. W przypadku systemow
> krytycznych jest skandaliczne/niebezpieczne.

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

>>> Należy powiedzieć: kernel pisany jest przez przypadkowych ludzi
>>> tworzących jako-tako działajace oprogramowanie.
>> A ludzie powstali w wyniku przypadkowych mutacji DNA.
>
> Co jednoznacznie udowania wyższość kernela Linu... oh wait.

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

>>> 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.
>> Ja nie lubię literatury s-f. Znana mi rzeczywistość wygląda inaczej.
>
> 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.

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.

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

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.

--
Jarek

do góry

Pan Sebastian Biały napisał:

>> 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).
>
> 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.

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.

>>>> 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.
>>> 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.
>> A co tu jest bez sensu?
>
> Używanie stwierdzeń z okolicy Captain Obvious unikając w ten sposób
> ustosunkowania się do czegokolwiek merytorycznie.

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.

>>> Nie. Bash nie jest lepszą alternatywą. Naprawdę, w stosunku do
>>> czegokolwiek. Podobnie jak i perl.
>> Bash może być lepszą alternatywą dla perla, podobnie perl może być
>> lepszą alternatywą dla basha.
>
> Stack overflow.

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

--
Jarek

do góry

On 2011-09-18 00:05, Jarosław Sokołowski wrote:
> 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.

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ń.

do góry

On 2011-09-18 00:16, Jarosław Sokołowski wrote:
> 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.

Co *konkretnie* uważasz za bzdury? Twierdzenie że języki silnie typowane
zapewniają lepszą jakośc kodu? Że bugi lepiej wykrywać wczesniej nie
dopuszczając do wystapnienia? Cos innego? Możesz być mniej tajemniczy?

> nie ma języków bezwzględnie
> lepszych i bezwzględnie gorszych

Thank You again, Captain Obvious!

do góry