A taki był warunek, czy choćby priorytet? Zamiast między masę i linię, wpinamy się między dwie linie -- i wszystko gra. Jak pojawi się problem z obciążalnością, to najwyżej będą potrzebne dwa tranzystory i dwa oporniki. Albo transoptor. Albo bógwico -- w każdym razie i tanie, i łatwe w zrozumieniu, a więc bezpieczne. Tu chodzi nie o te kilka groszy, tylko o nieporadność wielu ze współczesnych konstruktorów. "Raz mam osiem jedynek, innum razem osiem zer -- co robić, Droga Redakcjo?" -- Myśleć.
Jak nie dają, skoro dają? Drukarki drukują. I nawet daje się przewidzieć co wydrukują.
Dzwonią po niego. Póki co, nie ma jeszcze zbyt wielu fabryk, w których nie ma żywego ducha. A w takich, to system mu wyśle SMS. Poza tym ma się *w ogóle* nie restartować, najwyżej wyłączać.
Ma nie być "chwilowych spadków zasilania".
Ktoś uważa, ze powinno być inaczej?
Model płyty jest niezmienny dla konkretnego sterownika. Nawet w pececie, co na nim we fabryce recepcjonistka pasjansa układa (HP czy inny IBM), nie da się zmienić płyty głównej na inną, więc nie rozumiem skąd zdziwienie, że sterowniki używane przy produkcji są traktowanie inaczej niż składak gimnazjalisty.
Jeśli to jest "automatyka do zaciągania rolet w oknie obok komputera", to tak. A w ogólności, jeśli system jest w wydaniu jednostkowym i nie był wcześniej testowany, to o ile się da, to powinien być pisany w języku interpretowanym, z cały czas widocznym kodem.
Jeśli to jedyny sposób na przydybanie partacza projektanta na fuszerce i przesunięcie go do sekcji gimnastycznej, to tak.
No to tak samo jest z większymi systemami -- bierzemy element, który przewidział twórca i zastępujemy nim ten, który się zepsuł.
To trzeba było robić z sensem.
Proponuje nie "jednostkowe urządzenie", tylko radzę co ma zrobić żeby się nie narobić i skończyć w jeden wieczór. Gdy mu się ono zepsuje (jakie jest prawdopodobieństwo?) to najwyżej poświęci drugi wieczór. Albo i nie -- bo jakie jest prawdopodobieństwo, że trafi na inne zachowanie portu? Korzysta z dwóch linii, one moga być przed uruchomieniem programu ustawione na 00 albo 11. Innych możliwości nie ma. No to może od razu tego samego wieczora sieknąć obie wersje na wszelki wypadek.
Piękny idealizm. Producenci sprzętu za $$$ dwoją się i troją żeby jedynym wyspeecyfikowanym parametrem był numer katalogowy. A jak ktoś robi sam dla siebie, to i tak wie co robi (przynajmniej powinien)
Równie dobrze i równie niedobrze. Te same wady, żeadnych zalet. Jak się ktoś "postara", wad może być więcej. Chyba nawet łatwiej się postarać. Jedynie ETH ma jakościową przewagę -- tu wcześniej radziłem router z przekaźnikiem dolutowanym do diody LED.
"Programista PC (w tym przypadku) pisze kilka linijek skryptu działającego w znanym środowisku"
To jakie to środowisko? Jaki OS?
Jesli chcesz *swobodę* to zazwyczaj nie chcesz systemu operacyjnego. Systemy operacyjne powstały między innymi do ograniczania swobody.
Nie znam aż tyle szczegółów. Istotne jest że w wyniku awarii sprzętowej poszła sekwencja stanów załaczająca prasę. Awarii można bylo uniknąć gdyby nie wciskać jako sterownik urządzenia do tego nie przeznaczonego.
Mogą. Dlatego po drugiej stronie jest coś co to zauważy. np. Atmelek. Swego czasu miałem w rękach kartę sterującą CNC. Ładna, pod USB. No to pierwsze co zrobiłem to podczas pracy wyrwałem kabel. Zatrzymało, ale silnik po kilkunastu sekundach zaczyna śmierdzieć. Od, nastepny tępy debil zrobił sterowanie PWM z użyciem softu na PC a nie na karcie ... Nic dziwnego, na karcie był tylko konweter USB->GPIO.
Sterownikami. Jakimi - nie wiem. Ale pecety zostały tylko w zarządzania produkcją. Całe szczęscie, bo potem móglby ktoś zechcieć odpalać soft sterujacy na Windowsach.
Powiedz to fabrykom w chinach. W jednej znajomej blackout pojawia się kilka razy w tygodniu. Nie, to nie jest wyjątek.
Nie. Mamy kilkadziesią lat doświadczeń w pisaniu aplikacji. Naprawdę, potrafimy pisac programy niezawodne i przetestowane używając językow innych niż perl czy bash *nawet* w jednym egzemplarzu. Kwestia warsztatu.
- Panie Kaziu, niech pan mi tu da zapasowago peceta z LPT bo się zjarał znowu zasilacz i upier... płytę.
- Ale nie ma, zapasy się skonczyły, w sklepach nie ma
Przejście w automatyce na sterowanie przy pomocy standardowych PC uważam za jeden z najbardziej nietrafionych pomysłów. 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. 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. Jeszcze gorzej gdy aplikacja sterująca zostanie napisana na windowsa, dochodzi "zabawa" z zabezpieczeniem antywirusowym, firewallami, uaktualnieniami itd. A wykonanie? Oprócz ceny nie ma różnicy, na płytach Advantecha kondensatory schną tak samo szybko jak na "no-name" w domowym komputerze.
Zależy jak się rozumie swobodę. Jeśli jako "potrzebuję całego sprzętu, niech nikt i nic mi się nie waży zabraniać robić co chcę", to faktycznie lepiej nie chcieć. Ale jeśli jako "uruchomię ten czy inny program w zależności od fazy księżyca i kursu jena względem pesety", to lepiej mieć.
Wystarczy ten szczegół o wypadającej karcie.
Albo i nie ma -- jak opisano poniżej.
Dlaczego tępy debil? Człowiek o praktycznym podejściu do rzeczy. Jedyne co źle zrobił, to że nie uniemożliwił rozłączenia dwóch części urządzenia w czasie pracy. Albo przynajmnie nie napisał o skutkach i nie ostrzegł mniej kumatych. A może napisał, tylko ktoś nie przeczytał? Najśmieszniejsze, że gdyby to samo robić w oparciu o LPT, to takich niespodzianek o wiele łatwiej uniknąć (stwierdzeniem tego faktu nie chcę niczego dowodzić).
Prawidłowo. Zwłaszcza jak już wiadomo co jest potrzebne i wszystko jest ustabilizowane.
Jeśli od kilkudziesięciu lat nie wyszliście powyżej robienia automatyki do zaciągania rolet w oknie obok komputera i jeśli nie testujecie robionych rzeczy przed przekazaniem ich do użytkowania (mimo że potraficie), to nie ma się czym chwalić. Nawet warsztatem w takiej sytuacji nie ma co się chwalić, bo kogo to obchodzi.
Jeśli tam chadzają takie dialogi, to już dawno powinni zbankrutować. Ani trochę mi ich (was?) nie żal.
Nie przeszkadza Ci fakt że unix to nie jest środowsko real-time, że bash nie ma dostepu do potów I/O, że w normalnej sytuacji jako user nie masz dostępu do przestrzeni I/O?
Brak wyobraźni. Pomimo że gówniany kontroler za $2 załatwił by PWM to w myśl optymalizacji wypierniczono go i sterowano silnikami z USB. Czy wspominałem już że wygrywało melodyjki na silniku w zależności od obciązenia dysku?
Nie. On nie rózni się niczym od eksperów od sterowania przez LPT. Stany nieustalone? Ograniczenie prędkości? Jakieś przerwania w systemie? A kto by się przejmował duperelami. Ważne że nie ma skrajnie awaryjnych uC z fatalnymi błędami obsługi GPIO w których flash ulatuje po godzinie pracy.
Miło by to wygladało w instrukcji, prawda?
"I pamiętaj, że odłaczenie kabla USB może doprowadzić do pożaru. W celu uniknięcia pożaru proszę o owinięcie kabla i komputera załaczoną taśmą samoprzylepna używając węzła szotowego."
A tu mnie zaciekawiłeś. Windows i LPT? Chyba że masz namyśli protokół centronics. Po drugiej stronie trzeba by kupkę TTLi żeby to przerobić na coś sensownego.
Projektant hardwareu to chińczyk który produkował pecety do obslugi norton commandera w msdosie, a programista po wysunięciu karty z gniazda miał nikłe szanse na wyłączenie prasy bez wględu na to ile napisał wczesniej programów w turbo pascalu.
Przy opuszczaniu rolet i włączaniu grzejnika olejowego? Nie.
Raczej pomaga.
Nie mam żadnych przesłanek do oceny jego wyobraźni. W ogóle niewiele o nim wiem.
Mam szacunek do wszystkich ekspertów. Więc jeśli tak, to zasłużył na moje uznanie.
Kiedyś na końcówkach kabli USB były nalepki z ostrzeżeniem, by nie wtykać tego w komputer z systemem Windows, zanim się nie zainstaluje oprogramowania. No i faktycznie, gdy się to zignorowało, to jeśli ktoś nie był fachowcem, to po czymś takim nie udawało mu się już zmusić urządzenia do działania.
Jeśli to mogło skutkować pożarem, to oczywiście powinien o tym napisać. A jeśli się dało, to sam powinien zapewnić niemożnaość rozłączenia.
My. Programiści. My naprawde potrafimy pisać niezawodne programy. W wielu językach. Zalicza się do nich C i C++. Bywa ze java. Bywa że Ada. Bywa że lisp. Bash jest gdzieś na samym dnie jako utility language. Nic dziwnego, to padlina.
Jeśli, jesli, jesli. I wniosek. No pięknie.
A kogo obchodzi pisanie kodu do sterowania czymkolwiek w bashu? To chory język. Pod wieloma względami można w nim popełnić wiele błedow nieznanych w innych, znacznie sensowniejszych językach. Chwalenie się, że programy napisane w języku interpretowanym (a więc zapewne i dynamicznym) będa mniej awaryjne niż pisane w czymkolwiek innym obnaża twoją wiedzę dotycząca innych jezyków i metod utrzymywania jakości kodu. I przyznaje - znam wielu ludzi robiących w embedded (programiści pokolenia 8051) którzy o czymą takim jak abstrakcja, unit testy, constraints, silne typowanie, generyczność, interfejsy, asercje w życiu nie słyszeli. Nic dziwnego że robią szkole błedy i potem narzekają na C produkując kod gówniany do granic możliwości, nieprzetestowany (no bo jak, panie, to testować?) i działający na słowo honoru.
(Pewna niemiecka firma od 10 lat produkuje pewne urzedzenie które pomimo bledow w firmware zagrażających życiu (nie przesadzam) nie naprawia go bo człek co pisał odszedł a kod to kupa g... napisana w C na styl BCPLo podobny).
Co sugerujesz w zamian zamiast następnej nietrafionej oceny?
PS. Żeby była jasność. Nie jestem zwolennikiem stosowania *Atmela* jako sterownika. Jestem natomiast wrogiem stosowania peceta tam, gdzie nie ma miejsca na pomyłkę. A już na pewno nie peceta z gównianym bashem.
To bardzo skrajny przypadek sterowania. Zaryzykuje ze stosowanie w tym celu peceta jest mało ekonomiczne.
Fajnie. Znaczy odpalasz swoj skrypt jako admin? No i proszę, problem solved. A ja tu glupio rozmyślam jak zrobić coś lepiej. Brute force jest zawsze lepsze.
To wynik wielu czynników, ale jednym z nich są niedoróbki w kodzie windowsa i sterownikow. Niby mamy to za sobą, ale czy na pewno pewnego dnia następna prasa nie przywali kogoś w glowę bo sterownik się wypierniczy na dereferencji nulowego pointera? Masz jakieś gwarancje że kod składający się z milionów lini kodu do ktorego nawet nie masz wglądu jest lepiej wytestowany niż sto lini w C na avr?
Nierozłaczalne gniazdka USB. Czyli jak naprawić problem w innym miejscu niż występuje. Musze ten pomysł gdzies zanotować. Oczywiście, żeby nigdy na niego nie wpaść.
Wiem, wiele potraficie. Ale też przecież potraficie popełniać błędy...
...na przykład nie dostrzegając kilku istotnych "jeśli" i iść dalej jakby ich nie było. Nie zawsze wychodzi pięknie.
Tych co piszą.
Chlorchinaldin powinien pomóc.
Skoro rzeczywiście są mniej awaryjne, to co szkodzi się pochwalić? Ale przecież nie chodzi o bezawaryjność i bezbłędność, tylko o możliwość szybkiego dostrzeżenia i poprawienia pomyłek.
Ich (wasza?) ocena akurat jest trafna: powinni(ście) zbankrutować.
Ja nie jestem wrogiem stosowania czegokolwiek jako cokolwiek, o ile ma to uzasadnienie. Natomiast staram się unikać dawania możliwości decyzji inż. inź. Mamoniom, którzy potrafią docenić tylko to, co sami znają.
Mam nadzieję, że nie grywa Pan na giełdzie. Ocena ryzyka (ekonomicznego) słabo Panu wychodzi. Majstrowanie dodatkowego sterownika nigdy nie będzie tańsze.
Nie.
?
E tam lepiej. A poza tym, wszystko się zgadza.
???
Bash nie wie co to jest defragmentacja nulowego pointera, więc gdyby miał akurat takie obsesje, to bym mu poradził używanie basha.
Nie mam z góry zaufania ani do jednego, ani do drugiego. Ale na ogół ma się większe zaufanie do miliona linii sprawdzanych w praktyce od dwadziestu lat, niż do stu linni napisanych wczoraj przez jakichś debeściaków ("bo my to panie wszystko testujemy, a poza tym mamy kilkadziesiąt lat doświadczenia").
Albo brak gniazdka.
Przecież dymić się zaczęło po wyciągnięciu wtyczki.
Stosujesz żałosne metody A.L. do oceny dyskutantów?
Więc jak uzyskujesz prawa do przestrzeni I/O LPT? Sterownikiem kernela? Hackowaniem jądra?
Ciąg dalszy żalosnych metod A.L. czy zwykłe przejęzyczenie?
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. Powtarzalnego 100%, żeby nie było że to krasnoludki.
Debesciaki są w ogólności bardziej bezpieczni niż windows zaopatrzony w sterowniki produkowane na kolanie w chinach chodzace w trybie jądra. Chwilowo nie ma na rynku popularnych mikrokernelów, więc *zawsze* jesteś w czarnej dupie watpliwości co do tego czy sterownik myszki nie zrobi BSOD po 3 tygodniach i 14 sekundach pracy. Chińczyk nie ma czasu na testowanie takich dupereli.
I dzięki temu że to wiemy nauczyliśmy się również im przeciwdziałać. W sposób, ktory pozwala pisać programy o rzedy bardziej niezawodne niż w jezykach dynamicznych/interpretowanych a w szczegolności niż języki padlinowate jaki bash, perl czy inny cli-php.
NIE. Chodzi o to by nie dopuścić do pomyłek w momecie pisania. Nie dopuscić. Żadnego dostrzegania i poprawiania. W bashu nie ma o tym mowy. W C++ można ogromną ilość pomylek wyeliminować w compile-time bez jednego straconego cyklu w run-time. To dwa końce problemu jakości kodu w związku z językiem. Można dyskutować czy poprawienie buga w C jest łatwiejsze niż w bash, ale z doświadczenia powiem: jest łatwiejsze w C. Przynajmniej sa narzędzia.
Żeby była jasność: mowimy o sofcie który jest nieco bardziej rozbudowany niż klepanie przekaźnikiem. Klepanie przekaźnikiem pewno dało by się napisać w command.com w miarę bez błedow.
O dziwo czesto słyszę to od zwolenników wstawiania 8051 do
Nie wiem kto to taki ten A.L., więc nawet nie wiem czy jego metody są żałosne. Sądzę, że może być Pan znakomitym fachowcem w swojej dziedzinie (jakieś programowanie czegoś bardzo konkretnego?), ale uważam, że za tworzenie założeń i ocenę ekonomiki działań nie powinien się Pan brać.
Nie potrzebuję.
W tym momencie (pisania w bash) nie muszę sobie tym głowy zaprzątać.
Przejęzyczenie. A właściwie dyfuzja sąsiedniego z okienka.
Ten kernel był pisany w bashu?
No to całe szczęście. W takim razie nie ma tragedii.
Z Windows nigdy nie miałem na poważnie do czynienia. Z debeściakami czasem tak. Trudno mi porównywać, ale niebezpieczni są. Ponad tolerowane przeze mnie granice.
Nic mi jeszcze nie zrobiło BSOD, a co do Chińczyków, to nie mam uprzedzeń narodowościowych -- traktuję ich jak innych debeściaków. Z tego powodu, gdy chodzi o nowe rzeczy, staram się jak najwięcej robić we własnym zakresie (to znaczy przynajmniej mieć nad tym kontrolę).
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.
Z takim podejściem w ogóle nie ma co się zabierać za pisanie programu. Ani do żadnej roboty, bo człowiek jest omylny z definicji.
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".
Albo do *wszystkiego* używają jednego języka programowania.
Ten bash pracowal w środowisku stworzonym przez kernel. Sam z siebie pracować nie potrafi. Problem kernela jest problemem basha.
Jasne, skonczyło się na poprawianiu kodu w kernelu. 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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.