Mindig a felhasználás módjából kell levezetni a hibákra adandó választ. Ha sérülést vagy halált is tud okozni a gép, akkor más szabályok vonatkoznak rá, azt hobbi cuccal nem szabad üzemeltetni (A papírral védi a seggét a mérnök ugye, illetve az iparági szabályok betartása garantálja a minőséget. Dokumentált a fejlesztés és tesztelés folyamata, harmadik fél ellenőrzi az egész dokumentációt, stb.).
Ha viszont nem tud sérülést és halált okozni, akkor meg szerintem bőven jó a belső watchdog, amit erre a célra terveztek. Még az is felesleges, ha legalább a biztonságos állapotba állás nincsen megtervezve és megvalósítva. Például egy végtelen ciklusban újraindulás és "rángatózás" lehet egy ilyen watchdog vége, annak meg mi az értelme? Ha nem működik a rendszer akkor úgyis emberi beavatkozás lesz szükséges, és az ember az újraindításra úgyis képes lesz. "Húzza ki a konnektorból, várjon 5 másodpercet és dugja vissza!"
Amiatt, hogy több alkatrész, több potenciális tervezési vagy egyéb hiba lehetőség. Emiatt én nem tennék hobbi cuccba watchdog áramkört.

Igen, és ha a watchdog áramkör csak újraindítja a gépet, akkor ezt pont lehetetlen lesz megvalósítani, mert azt sem fogja tudni a program, hogy miért indult újra. Legalább egy hibajelzés kell a watchdog áramkörtől ahhoz, hogy egyáltalán azt tudja a vezérlő, hogy a watchdog indította újra.
Watchdog interruptból viszont van esély "core dumpot" csinálni, ami segíthet a nyomonkövetésben utólag is. De ezzel is csak akkor próbálkoznék, ha elkezdenek másképp megmagyarázhatatlan hibák jönni, a hibakeresés részeként. Legalábbis hobbi szinten.

Egyet értek Gafly-val, az újra indítgatás a windows sportja, ahol esetlegesen a memóriában összekeveredhet valami. Egy jól megtervezett mikrovezérlő ne menjen tévútra. Ha tévútra tévedt, és észre veszem, akkor haljon meg végleg ( valószínű hardver hiba, az meg mitől javult volna meg) . Ha külső válaszra vár, az sem jön időben később sem. Max arra jó hogy az esetleges programhibát lefedje a felhasználó felé. A külső watchdog arra jó, a többi szerkezetnek biztonságosan jelezze, tönkre ment a proci értelmes adatot ne várj, és az esetleges ki/bemeneteket valamiféle biztonságos pozícióba kényszerítse hardveresen.

Ezzel teljes mértékben egyetértek.


Ez abszolút nem biztos, hogy kizárólag hardwer hiba. Lehet egy kósza EMC impulzus is, ami kiakasztaja a programkódot. Szerintem a végleges halál nem jó irányvonal. Épp az előbbi gondolat miatt.


Ez pedig szerintem nem vezérlő, vagy program hiba, lehet egy szenzor nem jó, hibás, és azért nem jön signal.


Miért ment volna tönkre a proci. Persze benne van a pakliban, de nem kizárólag processzor tömkremenetel miatt jó a watchdog.

Saját példa:
Issue description

Azaz 447 naponta a watchdog ujrainditotta a kártyát, mivel lefagyott. Mivel több kártya is van, ezek egymás tartalékai is. Dehát pont egyszerre fagytak le.

Mellesleg az Aricent nem kutyaütő garázs cég.
Tehát a Linux times() függényben volt egy hiba, ami miatt néha (esetünkben 447 naponta) idő helyett "-1"-et küldött. Szegény szoftver fejlesztő, meg erre nem számított, ezért lefagyott tőle a szoftvere. Szerencsére ott volt a jó öreg watchdog, és resetelt. Aki a kártyát tervezte és írta rá a szofvert, meg nézett ki a fejéből, hogy mi fenét ronthattam el? Aki meg összerakta az egész nodet-t, és az azt működtető szotvert, szintén.

Sajnos amikor már a kártyán is van külön operációs rendszer, még a kapcsolási rajz is úgy van letöltve (FPGA), és "magas szintű" nyelven van programozva, akkor bármi megtörténhet...

Szerintem a jól működő szerkezetek jól működnek, az egyszer újra indulónak meg az válik szokásává. Vagy rendesen meg kell(ene) építeni, hogy évente max egyszer álljon le, és akkor a felhasználó odaballag, megnézi mi történt, vagy amikor kedve van újra indulgat, de akkor értelmetlen biztonságról beszélni, és plusz alkatrészeket beépíteni. (nem etikus eltakarni a tervezési hibát).
Ha a processzor kimeneteinek állapota nem garantálható (márpedig ha adott lábán nem jön adott időben impulzus akkor az az eset biztosan az) Akkor bármely kimenete tetszőleges állapotot felvehet. Erre minimum az lehet a jó válasz, a vezérelt részt semleges módba küldi valami, esetleg egy vészleállító érintővel. Az hogy rossz a proci hardveresen vagy nem, lényegtelen. A külvilág felé hibás.

Itt nem a tervezési hibáról van szó alapvetően. Haenm a nem várt eseményekről, ami esetleges fagyást okozhat a programban. Erre, illetve ennek kivédésére, kezelésére szeretném a hardveres watchdog-ot beépíteni a vezérlőbe.

Bővebben: Link A 0-10 volt szigetelés megoldható végülis.

Olyan elektronika nincs ami a “nem várt” eseményeket kezelni tudja. Az elektronika csak azt tudja kezelni amit te el tudsz képzelni ( elvárod) és akkor megoldod az arra valo reakciot.

Végső soron mégis lehet, hogy talán van. Szerintem. Példa: Egy nem várt esemény miatt lefagy a program. A nem várt esemény, amit nem ismerek, nem tudom mikor érkezik (ha érkezik) Legyen egy véletlen EMI impulzus, ami kiakasztja a programot. A program fagyást viszont a watchdoggal tudom kezelni. Persze abban igazad van, hogy "amit el tudok képzelni". Valóban. Nekem az a véleményem, hogy egy hardveres watchdog hasznos kiegészítője lehet a PLC (ALC)-nek.

A mikrokontrollerben lévő WD teljesen külön álló hardveres egység, nincs rá hatással a szoftver.

Teljesen jó a belső WD. Az is hardveres WD, csak egy tokban van a mikrokontrollerrel.

Csak nem minden arduino bootloaderrel kompatibilis.

Amiket javasolni tudok:
- Minden komponens alapállapota legyen hardveresen kódolt! Mindenhol legyen fel és lehúzó ellanállás a komponensek kikapcsolt/reset állapotában.
- A mikrokontroller BOD (alacsony tápfesz) detektora legyen bekapcsolva! Egy túlságosan alacsony feszültségről járatott MCU csúnya hülyeségeket tud csinálni.
- Ha van normális táp, akkor induljon el az MCU, és az önteszt lefuttatása után sorban kapcsolja be a többi komponenst, ahol lehet próbáljon tesztet futtatni, hibát detektálni.
- MCU fagyás esetén a beépített WD reseteli az MCUt. Ekkor minden kezdődik elölről a fentiek szerint. A vezérelt gép pedig mindaddig áll, amíg a szoftver újra nem indul.
- Általában nem szükséges az észrevétlen újraindulás. Ha az adott hardver támogatja, akkor szoftverből le kell kérdezni az újraindulás okát, és ha az WD vagy BOD, akkor tájékoztassa a kezelőszemélyzetet.
- A gépen semmilyen biztonsági rendszer nem lehet függőségben a vezérlő mikrokontrollertől. Tehát túlfeszültség, túláram, túlnyomás, stb érzékelőknek az MCUtól függetlenül biztonságosan le kell tudniuk állítani a gépet. Ha ezek a biztonsági berendezések is elektronikus vezérlésűek, akkor ezekhez második mikrokontrollerre van szükség.

Én egy ilyen helyről kihagynám az Arduino bootloadert, és olyat tennék a helyére, ami megfelel a célnak.

Szerintem a feladat nagyságrenddel bonyolultabb mint azt gondolod, de sajnos nem igen hallgatsz másokra, igy nem igen lehet neked tanácsokat adni.
Azt sem tudjuk pl mi mindent akarsz a készülékkel vezérelni, mert egészen másképp kell kezelni egy veszélyes gépet, aminek megakadhat a SW hiba miatt a mozgása. Ahol a külsö WD aligha segithet, mire az elinditja az Arduinot, addigra a forgó gép stb. már komoly károkat okozhat stb.

Leírtam, hogy hogyan működik az én verzióm, aztán jött a sok írás, hogy az ipar nem így, meg nem úgy szokta, meg az én verzióm nem jó. Elfogadom az ipari szabvány kapcsolástechnikát, ha olyan eszközt építenék, amit bárki bárhol beépíthet. Csakhogy nem ez a helyzet. Kizárólagops telepítés és szervíz csak is az enyém. Senki más nem nyúlhat bele a rendszerbe. Ezzel megvédem magam, az egyéb esetleges hibás javításoktól, amit mások hajtanak végre. Azért, mert ez egy komplett AUTONÓM, FÜGGETLEN összetett egység, amihez más nem kapcsolódik. (csak szenzorok, végállás, mágneskapcsoló) Ha az én verzióm fog működni a tesztek után, akkor nekem IS igazam van. Természetesen neked is, nem vitatom. De ha nem működik stabilan, akkor átgondolom, és majd akkor kérek tanácsot. Pillanat. Én nem akarom a WD-vel megváltani a világot. Nem a WD lesz az elsődleges, de még a másodlagos biztonsági funkció. Az csak azért felel, hogy ha lefagy a szoftver, újra induljon az arduino. Az elsődleges, másodlagos védelmi, biztonsági berendezések teljesen függetlenek az arduino-tól. A gyári PLC-ben hogyan oldják meg, ha netán kifagy a szoftver?

"Nem a WD lesz az elsődleges, de még a másodlagos biztonsági funkció."
Naná! Van ennél már fejlettebb is Pld..

Ismét csak azt látom, hogy a lehetőségeket és a variációkat ostoroljátok kézzel lábbal, holott nem ez a téma!
Az hogy Zoli_bácsi mit működtet a PLC-vel, vagy ALC-vel az a kutyát nem érdekli, senkinek semmi köze hozzá. Nyílván van Mindenkinek tapasztalata különböző területekről, de attól még jó volna a témánál maradni!
Ne a kóstolgatás legyen már a fő téma, hanem az eredeti kérdés megoldása...
Eddig 2-3 kolléga tudott érdemlegesen hozzászólni a témához, Mindenki más csak megmagyarázta a saját nézetét.
Segítsünk egymás elképzeléseinek a megvalósításában, nem pedig hátráltassuk...

Arról azért ne feledkezzünk el, hogy egy tökéletesen megtervezett program egy tökéletesen kivitelezett vason is tud hibázni.
Régen például a programok EPROM-ban voltak. Régi EPROM-ok adatmegtartási ideje eléggé korlátozott volt (különösen ha nem ragasztották le, stb.). Adott esetben akkor is EPROM lehet benne, ha nincsen rajta ablak, OTP (One Time Programming) -> Ugyanaz a chip, olcsó műanyag tokban. Régen volt olyan, hogy időszakonként újra kellett írni az EPROM-okat. Nagyjából hasonló a helyezet az EEPROM esetében is. Ha elfelejti a programot a kontroller, akkor az ellen a WD sem véd...
Mostanában egyre inkább látókörbe kerül a "szoft error". Annyira sok és főként annyira pici alkatrészt integrálnak egy chip-re, hogy már egy szerencsétlenül helyre becsapódó részecske is hibát tud okozni. Átbillen egy bit a memóriában, de még a szoftver nélküli logikai hálózat is tévedhet, ha mondjuk az Androméda ködben a Klingonok fézerrel lövöldöznek, és pont felénk állt a csöve. Butaságnak hangzik, de létezik ilyesmi. Mindjárt itt is van két cikk.
Wiki
Tudományos
Na ez ellen például jó, a WD. Reset után megy tovább minden, mintha mi sem történt volna. A teljes igazsághoz azért hozzá tartozik, hogy nagyságrendekkel gyakrabban fordul elő szoftver hiba (emberi mulasztás miatt), mint űrinvázió...Egy SN5400 vagy CD4011 nem szokott hibázni emiatt még Pakson sem.

Természetesen meg van a véleményem és tapasztalatom, szoftverről-biztonságról ipari körülményekről, gyártókról, gyártók hozzáállásáról, eszközök vételéről, dokumentálásukról.
De őszintén szólva ezt itt nem fejteném ki. Mert igen messzire mutat a dolog és nem tartozik a hobbi kategóriába. De a biztonságnak és a biztonság-technikának szintjei vannak.
Hogy hol, mit lehet alkalmazni, arról csak egy történet, hogy az ABB majdnem megfeküdt mint cég, mikor egy harmadik fél beszállítójaként volt egy per ellenük. Ezért nem szállítottak Európába ilyen berendezéseket. (Szinte minden országban mások a követelmények és a jogok ezen a területen.)
Én EPROM adatvesztést nem tapasztaltam, de statikus RAM-nál már találkoztam ilyesmivel. Minden esetre a mindenáron való "törpösítés", nem kedvez a dolgoknak. A szoftveres csapda, pont a következetes viselkedésében van. Vagy is egy fel nem ismert hiba bekövetkezése esetén minden egység ugyan azt fogja elkövetni, ellenben az analóg dolgokkal, aminél hol ilyen hol olyan hiba okoz gondot, de általában nem viselkedik egységesen. Ezért fontos szempont a divezifikáció is a biztonságnál. Mikrokontrollereket már nagyon rég óta nem tesztelik.
De inkább ne tárgyaljuk ezeket, ezért értettem egyet Zosza-val..

Ezt kifejtenéd bővebben? Nem világos mire gondolsz.

Egyszerű a dolog. Régen még foglalkoztak ilyesmivel, da ma már annyi funkció/variáció van, hogy nem fér bele az időbe meg az anyagiakba. Inkább kiadják a kezükből, aztán ha jeleznek, hogy vannak hibák vagy kijavítják, vagy úgy marad és csak közlik a hibajegyzékben.

A hibajegyzék (errata) kötelező olvasmány minden szoftver írónak, mert hajmeresztő dolgokat tartalmaz. Sajnos sok önjelölt atommáglyát ellenállásból akaró építőnek ez újdonság. Szintén tisztelet a kivételeknek.

Az a gond, hogy az többnyire csak azt a kodot vizsgálja amit az iro irt, de ma már szinte még a legprimitivebb berendezésben több szoftware fut anélkül, hogy iróik egyáltalán ismernék a egymást
. ( pl display, szenzorok stb meghajtoi).
Az ilyen programbol kapott hibakod, is legfeljebb azt tárja fel ami nem müködik a belsö rendszerben, de nem azt, amire a külsö jelek hatással vannak. Arra meg nincs idö meg pénz sem, hogy valamennyi elképzelhetö gondra jo választ lehessen találni és ezt beprogramozni a szerkezetbe. Láttuk a Boeing balhéját, de hasonlok, szerencsére ritkán járnak ilyen tragikus következményekkel, mindennaposak, gyakran a felhasználok észre sem veszik.
Pl a minap is két vonat kerül egymàssal szembe az egyvágányu pályán, holott ez a lehetöség már vagy 120 éve a vasuti berendezések kulcsparamétere és a legtöbb berendezésen még készakarva sem lehet ilyen hibát elöidézni, mégis elég gyakran sikerül.
Ilyenkor általában valamit csinálnak a berendezésen, hogy ez ne ismétlödhessen meg, mégis egy idö után ujra sikerül ilyen hibát összehozni.

Így van. Ez sokszor elég nagy probléma. A különféle libek minősége erősen eltérő. De olyan is van, hogy a libek önmagukban jól működnek, ám kettő együtt összeakad. Az a legszebb, amikor nem azonnal, hanem bizonyos speciális esetekben. Például egy számláló néhány naponta jár le, és ha pont akkor történik IO interrupt is, akkor a két interrupt handler összeakad. Sajnos találkoztam már pár ilyennel, és nagyon nehéz volt őket megfogni.
Ezért is léteznek biztonsági szabványok, amiket már a tervezés során be kell tartani. Tervezés, kockázatelemzés, részletes szoftver terv, teszt terv, teszt jegyzőkönyv, stb. Biztonságkritikus rendszerekben, mint vasút, orvostechnológia, stb. olyan szoftverkomponenseket használhatsz, ami ugyanezen szabvány alapján készült. Igen, az stdlib és társai is. Igen, van belőlük ilyen verzió, jó drágán. B verzió, hogy ha nem a szabvány szerinti folyamat alapján fejlesztett komponenst használsz, akkor te vállalod érte a felelősséget, igen a GCC-vel érkező stdlibért is. Kockázatelemzést végzel, tesztelsz, és dokumentálsz. A lényeg, hogy a te kódod ne hasalhasson le ilyen külső komponens miatt.
Ez például orvostechnikai eszközökre vonatkozik.

Sziasztok!

Érdeklődtem más topicban a nano határairól. Úgy tűnik a kínai nem véletlenül 7 DO-t 4 AI-t és 5 DI-t talált ki. Szerintem 5 analóg bemenet átlagos vezérlési funkcióhoz nem kell. Szintén megfonmtolandó, hogy megéri-e a teljes 0-10 volt leválasztás vagy nem. Költség növelő tényezők. Mindenesetre a következő lépésem, hogy szerezek dobozokat, DC DC invertert, és EBayről 0-10 volt leválasztó nyákot. Az eszköz paneljét úgy rajzolom meg, hogy elférjen mindegyik. Ha nem kell, nem épül be, csak átkötés lesz.

Szia!
Nem tudom milyen célfeladatra lenne szánna a készülék, de szerintem bemenetből általában több kell mint kimenetből. Szóval inkább 7DI, 5DO, és egyéb. Ez az összesen 12db IO nekem kevésnek tűnik, nagyon hamar el tudnak fogyni, ha valamit vezérelni kell.

A legkisebb PLC-k általában pont ennyi IO-t tartalmaznak...ahogy mondod, szinte semmire sem elég! Ezért gondolt a gyártó a portbővíthetőségre! Legyen az akár digit IO, vagy analóg esetleg kommunikáció.
Lásd Omron CP1 család, vagy A-B microLogix820.
Az előbbinek kb. 40-50e az utóbbinak kb 70e a használtpiaci értéke, és ezek mostani modellek, még gyártásban vannak.
A házamat vezérlő PLC több mint 200 IO, 8AI, soros komm. stb!

Ez mindig érdekelt: mi vezérelni való van egy házon? Redőnyök, fűtés, okos világítás meg mondjuk öntözés, de mi van még ami miatt érdemes kiépíteni? Lehet más témában jobb helyen lenne a kérdés..