Fórum témák

» Több friss téma
Fórum » Arduino alapú, Programozható Logikai Vezérlő
Lapozás: OK   7 / 8
(#) asch válasza majkimester hozzászólására (») Máj 28, 2023 /
 
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.
(#) asch válasza sargarigo hozzászólására (») Máj 28, 2023 /
 
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.
(#) proba válasza Zoli_bácsi hozzászólására (») Máj 28, 2023 / 1
 
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.
(#) Zoli_bácsi válasza proba hozzászólására (») Máj 28, 2023 /
 
Idézet:
„az újra indítgatás a windows sportja, ahol esetlegesen a memóriában összekeveredhet valami.”

Ezzel teljes mértékben egyetértek.

Idézet:
„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)”

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.

Idézet:
„Ha külső válaszra vár, az sem jön időben később sem.”

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

Idézet:
„A külső watchdog arra jó, a többi szerkezetnek biztonságosan jelezze, tönkre ment a proci értelmes adatot ne várj,...”

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.
A hozzászólás módosítva: Máj 28, 2023
(#) Gafly válasza Zoli_bácsi hozzászólására (») Máj 28, 2023 /
 
Saját példa:
Issue description
Idézet:
„xxx board switching stack is hang for sometime after 447 days uptime.
Switch watchdog timer is not kicked off, and it resets the board.”

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.
Idézet:
„Aricent ISS switching stack uses Linux times() function to run internal
timer module. Linux times() may return -1 for several seconds when return
value is roll over (after n-days of uptime, depening on architecture) or
in short period after restart.
ISS time module does not handle such case and during this time all ISS
timers get stuck.”

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.
Idézet:
„Dehát ezt én most hogy???”

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...
(#) proba válasza Zoli_bácsi hozzászólására (») Máj 28, 2023 /
 
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.
(#) Zoli_bácsi válasza proba hozzászólására (») Máj 28, 2023 /
 
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.
A hozzászólás módosítva: Máj 28, 2023
(#) szendi001 hozzászólása Máj 28, 2023 /
 
Bővebben: Link A 0-10 volt szigetelés megoldható végülis.
(#) Massawa válasza Zoli_bácsi hozzászólására (») Máj 28, 2023 /
 
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.
(#) Zoli_bácsi válasza Massawa hozzászólására (») Máj 28, 2023 /
 
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.
(#) vargham válasza Zoli_bácsi hozzászólására (») Máj 29, 2023 /
 
A mikrokontrollerben lévő WD teljesen külön álló hardveres egység, nincs rá hatással a szoftver.
(#) vargham válasza Zoli_bácsi hozzászólására (») Máj 29, 2023 /
 
Teljesen jó a belső WD. Az is hardveres WD, csak egy tokban van a mikrokontrollerrel.
(#) GPeti1977 válasza vargham hozzászólására (») Máj 29, 2023 /
 
Csak nem minden arduino bootloaderrel kompatibilis.
(#) vargham hozzászólása Máj 29, 2023 /
 
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.
A hozzászólás módosítva: Máj 29, 2023
(#) vargham válasza GPeti1977 hozzászólására (») Máj 29, 2023 /
 
Én egy ilyen helyről kihagynám az Arduino bootloadert, és olyat tennék a helyére, ami megfelel a célnak.
(#) Massawa válasza Zoli_bácsi hozzászólására (») Máj 29, 2023 / 1
 
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.
(#) Zoli_bácsi válasza Massawa hozzászólására (») Máj 29, 2023 /
 
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?
(#) proli007 válasza Zoli_bácsi hozzászólására (») Máj 29, 2023 /
 
"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..
(#) zosza18 hozzászólása Máj 29, 2023 / 2
 
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...
(#) Gafly válasza proli007 hozzászólására (») Máj 30, 2023 /
 
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.
A hozzászólás módosítva: Máj 30, 2023
(#) proli007 válasza Gafly hozzászólására (») Máj 30, 2023 /
 
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..
(#) lokátoros válasza proli007 hozzászólására (») Máj 30, 2023 /
 
Idézet:
„Mikrokontrollereket már nagyon rég óta nem tesztelik.”

Ezt kifejtenéd bővebben? Nem világos mire gondolsz.
(#) proli007 válasza lokátoros hozzászólására (») Máj 30, 2023 /
 
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.
(#) HeZ hozzászólása Máj 30, 2023 / 2
 
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.
(#) Massawa válasza HeZ hozzászólására (») Máj 30, 2023 / 1
 
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.
(#) vargham válasza Massawa hozzászólására (») Máj 30, 2023 / 1
 
Idézet:
„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”

Í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.
(#) szendi001 hozzászólása Máj 31, 2023 /
 
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.
(#) Peter65 válasza szendi001 hozzászólására (») Máj 31, 2023 / 1
 
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.
(#) dB_Thunder válasza Peter65 hozzászólására (») Máj 31, 2023 / 1
 
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!
A hozzászólás módosítva: Máj 31, 2023
(#) sargarigo válasza dB_Thunder hozzászólására (») Máj 31, 2023 /
 
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..
Következő: »»   7 / 8
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem