Goto page Previous 1, 2, 3 ... 7, 8, 9 ... 11, 12, 13 Next
Sebastian Biały
Guest
Sat Sep 17, 2011 9:31 pm
On 2011-09-17 23:10, Piotr wrote:
Quote:
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.
Nie znam szczegółów poza ogólnym ustaleniem przyczyn wypadku.
Piotr
Guest
Sat Sep 17, 2011 9:32 pm
W dniu 2011-09-17 22:26, Grzegorz Krukowski pisze:
Quote:
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.
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
Desoft
Guest
Sat Sep 17, 2011 9:36 pm
Quote:
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?
Quote:
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?
Quote:
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.
Quote:
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
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 9:38 pm
Pan Sebastian Biały napisał:
Quote:
Albowiem bash działa w przestrzeni równoległej gdzie pojęcie nulowego
pointera nie istnieje i już! W szczegolności w sterowniku do LPT! I
wtedy się budzisz. Ja też kiedyś sniłem do czasu aż kernel z lini 2.4
zrobił oopsa przy obsłudzie - wydawało by się - trywialnego COMa.
Ten kernel był pisany w bashu?
Ten bash pracowal w środowisku stworzonym przez kernel. Sam z siebie
pracować nie potrafi. Problem kernela jest problemem basha.
Ale to kernel był skopany. Więc wiadomo kto winny i gdzie poprawiać.
Quote:
Powtarzalnego 100%, żeby nie było że to krasnoludki.
No to całe szczęście. W takim razie nie ma tragedii.
Jasne, skonczyło się na poprawianiu kodu w kernelu.
Toć mówię, że dobrze. Źle by było, gdyby skończyło się wcześniej.
Quote:
Jeszcze jedna do miliona niewiadomych o stabilności całości systemu.
Przy takiej ilości nie ma już żadnego znaczenia, kontrole straciłeś
wiele milionów lini kodu wczesniej.
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.
Quote:
Nic mi jeszcze nie zrobiło BSOD
Jesteś w mniejszości.
Wiem. Na szczęście ta mniejszość ma lepiej niż większość.
Quote:
gdy chodzi o nowe rzeczy, staram się jak najwięcej robić we własnym
zakresie (to znaczy przynajmniej mieć nad tym kontrolę).
Czyli kernel też piszesz samodzielnie?
Nie mam potrzeby, jestem zadowolony z tego co jest. Ale jak jeden taki
nie był zadowolony, to napisał.
--
Jarek
Sebastian Biały
Guest
Sat Sep 17, 2011 9:39 pm
On 2011-09-17 23:29, Jarosław Sokołowski wrote:
Quote:
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.
Quote:
Pozostaje rękodzieło, poprawianie buga po kimś.
Brrr, wstrętne.
Zajmuje czas, nie daje żadnych gwarancji. W przypadku systemow
krytycznych jest skandaliczne/niebezpieczne.
Quote:
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.
Quote:
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.
Piotr
Guest
Sat Sep 17, 2011 9:39 pm
W dniu 2011-09-17 23:31, Sebastian Biały pisze:
Quote:
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
Sebastian Biały
Guest
Sat Sep 17, 2011 9:42 pm
On 2011-09-17 23:39, Piotr wrote:
Quote:
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ń.
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 9:47 pm
Pan Sebastian Biały napisał:
Quote:
Co z tego, że macie sposoby na pisanie programów niezawodnych, skoro
nie umiecie przeanalizować założeń? Owszem, może uda wam się w ten
sposób zrobić działający program, ale to na nic, gdy robi on nie to,
co powinien.
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.
Quote:
skąd to poprzednioustrojowe używanie "Wy" ?
Z użycia liczby mnogiej wywnioskowałem, że wypowiada się Pan w imieniu
jakiejś grupy (chyba programistów).
Quote:
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.
Quote:
Tak, doskonale sobie zdaje sprawę że wiekszośc z nich przetrwala
w przechowalni o nazwie embedded.
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ć).
Quote:
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?
Quote:
Ani do żadnej roboty, bo człowiek jest omylny z definicji.
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.
Quote:
Trudno. Takie języki też sa potrzebne, ale u diabła dlaczego ma od
nich zależeć czyjeś życie?
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.
Quote:
Ale przecież wy wszystko robicie tak samo, niezależnie czy chodzi
o klepanie przekaźnikiem czy czymś innym. Bo pisanie w innym języku
jest "gówniane".
Sam pisze oprogramowanie sterujące pewnym cusiem w JavaScript.
Moje gratulacje.
Quote:
Bo doskonale wiedzialem, po analizie, czego i jak potrzebuje użyć.
Świetnie. Widzę, że praca w zespole przynosi efekty.
Quote:
Pomimo tego nie potrafie nawet naszkicować zbioru warunków na które
odpowiedzią byłby bash.
Nie wszyscy potrafią wszystko.
Quote:
Zawsze jest lepsza alternatywa.
Zawsze. Od początku Panu o tym mówiłem.
--
Jarek
Sebastian Biały
Guest
Sat Sep 17, 2011 10:03 pm
On 2011-09-17 23:53, Jarosław Sokołowski wrote:
Quote:
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.
Quote:
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.
Quote:
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.
Sebastian Biały
Guest
Sat Sep 17, 2011 10:17 pm
On 2011-09-18 00:05, Jarosław Sokołowski wrote:
Quote:
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ń.
Sebastian Biały
Guest
Sat Sep 17, 2011 10:23 pm
On 2011-09-18 00:16, Jarosław Sokołowski wrote:
Quote:
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?
Quote:
nie ma języków bezwzględnie
lepszych i bezwzględnie gorszych
Thank You again, Captain Obvious!
Jacek Radzikowski
Guest
Sat Sep 17, 2011 11:08 pm
On 09/17/2011 05:36 PM, Desoft wrote:
Quote:
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?
"Computer numerical control" - czyli sterowanie komputerem. Często używa
się tej nazwy w odniesieniu do obrabiarek sterowanych numerycznie.
Quote:
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?
W środowisku przemysłowym używa się specjalizowanych paneli
operatorskich. Może w takim panelu siedzieć pecet przemysłowy z
windowsem, czy czymkolwiek innym, ale to nie jest niezbędne.
Wiele lat temu robiłem UI do maszyny na czymś takim:
http://avgautomation.com/avgmodconnect/assets/images/vfd_pci185bg.jpg
Maszyna miała w sobie 3 PLC, przez panel można było kłapać zaworami,
uruchamiać sekwencje działań, zmieniać nastawy PIDa, itp. Część operacji
była dostępna dla wszystkich, część zabezpieczona dwoma poziomami haseł,
czyli dość rozbudowane UI. Jedyna styczność jaką panel miał z pecetem to
programowanie.
pzdr.
j.
PS: Najwięcej pochwał od operatorów urządzenia dostaliśmy za funkcję
zegarka, którą dodałem "z nudów".
Sebastian Biały
Guest
Sat Sep 17, 2011 11:19 pm
On 2011-09-18 00:36, Jarosław Sokołowski wrote:
Quote:
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?
A nie da się powędrować w górę po gałązce wątku i przeczytać?
Myslę że jak się komuś pluje w twarz "bzdury" to można choć troche je
precyzyjniej określić. Tak żeby się dalo odnieść. Inaczej to inwektywa
na poziomie podłogi politycznej na która można tylko wzruszyć ramionami.
Quote:
Tu konkretnie ocenę znaczenia błędów.
Czy ja gdzieś twierdze które błedy są ważniejsze od innych? Masz jakieś
massage-id? Śmiem natomiast wierdzić że pewien zbiór błedow można
wyeliminować poprzez *nie* używanie gównianych języków. To całkiem spory
zbiór.
Quote:
Ale wiele innych rzeczy
oczywiście też.
Jasne. Super.
Jarosław Sokołowski
Guest
Sat Sep 17, 2011 11:29 pm
Pan Sebastian Biały napisał:
Quote:
Ale to kernel był skopany. Więc wiadomo kto winny i gdzie poprawiać.
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.
Quote:
Pozostaje rękodzieło, poprawianie buga po kimś.
Brrr, wstrętne. To tak, jakby myć zęby cudzą szczoteczką do zębów.
Na samą myśl robi mi się niedobrze.
Quote:
A miało być tak tanio a wyszlo jak zwykle.
Nie miało być tanio, miało być dobrze.
Quote:
Jeszcze jedna do miliona niewiadomych o stabilności całości systemu.
Przy takiej ilości nie ma już żadnego znaczenia, kontrole straciłeś
wiele milionów lini kodu wczesniej.
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.
Należy powiedzieć: kernel pisany jest przez przypadkowych ludzi
tworzących jako-tako działajace oprogramowanie.
A ludzie powstali w wyniku przypadkowych mutacji DNA.
Quote:
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.
Ja nie lubię literatury s-f. Znana mi rzeczywistość wygląda inaczej.
Quote:
I tak, jezyk C w embedded to gówno. Przy czym już kiedyś pisalem czemu.
W takim razie jeśli będę chciał wiedzieć co nie jest gównem, poszukam
sobie w archiwach.
--
Jarek
Sebastian Biały
Guest
Sat Sep 17, 2011 11:44 pm
On 2011-09-18 01:34, Jarosław Sokołowski wrote:
Quote:
A nie da się powędrować w górę po gałązce wątku i przeczytać?
Myslę że jak się komuś pluje w twarz "bzdury" to można choć troche je
precyzyjniej określić. Tak żeby się dalo odnieść. Inaczej to inwektywa
na poziomie podłogi politycznej na która można tylko wzruszyć ramionami.
To dołożę kolejną na tym samym poziomie: trzeba wiedzieć do czego służy
"References" i umieć zrobić z tej wiedzy użytek.
EOT.
Goto page Previous 1, 2, 3 ... 7, 8, 9 ... 11, 12, 13 Next