Onderwerp: Betrouwbaarheid open bron software + Raspberry Pi

WADnWIND schreef :
Die test die je gedaan heb wdw, waren die conform de "richtlijnen" zoals een goede voeding met een goede usb kabel, op de goede manier uitgezet(!?) en supported sd kaart ?

WADnWIND schreef :
Hier moet ik je gelijk geven. In het geval dat je stroomvoorziening zo onbetrouwbaar is dat hij gemiddeld om de tien minuten uitvalt is het niet verstandig die stroomvoorziening te gebruiken voor een computersysteem wat regelmatig gegevens op slaat. Ook al zou de hardware er tegen kunnen is de kans op data verlies groot.

WADnWIND schreef :
Op een IC zal een stroomuitval wel niet zo vaak voorkomen. Om je eerlijk te zeggen je argument om een Rpi niet te gebruiken in een beademingsapparaat omdat de Rpi niet tegen stroomuitval bestand is vrij bizar. De patiënt die aan het apparaat ligt kan daar namelijk ook bijzonder slecht tegen. Maar zelfs aan boord vind ik een regelmatige stroomuitval niet acceptabel.
Overigens een Rpi met een SD kaart met een read only files system kun je die zo vaak uit/aan schakelen als je wilt, daar gebeurt niets mee. Weet ik uit eigen ervaring. Uiteraard ben je dan wel alle standaard log functies van linux kwijt.

Is dat gehele beademings apparaat Open Source (zoals de Prusa 3D printers) of alleen de software? In het eerste geval ben ik benieuwd hoe deze professionals hiermee om gegaan zijn.

3Noreen schreef : Ik ook, heb er honderden in het veld die alleen via de schakelaar kunt uitschakelen pas sinds december lever ik de "open" versie die je kan afsluiten als je dat wilt of als dat nodig is afhankelijk van de gebruikte software.

Nachtvlinder schreef :

Met de Rpi is zoals gezegd weinig mis, maar als je SD kaartje 'corrupt' raakt heb je daar weinig aan. Zoiets als een prima auto met een lege tank, niks mis met de auto maar rijden ho maar.

Het grootste probleem is de manier waarop SD kaartjes beschreven worden. Technisch kan je namelijk niet zomaar een willekeurig bitje ergens op de kaart veranderen, maar moet je eerst een heel 'blok' (zeg 10000 bitjes) lezen en opslaan, dan het hele blok vullen met 'nullen', en dan het hele blok met aangepase data weer terugschrijven.

Gaat er iets mis (stroomuitval) gedurende deze aktie dan is dus je hele blok data naar de kloten, en is ook je oude data niet meer beschikbaar. Als er ook net een onmisbaar stukje data voor het OS in dat blok stond zal de computer niet meer opstarten. Met de Pi zelf is dan niks mis, maar met het SD kaartje wel.

Sluit je het geheel altijd netjes af dan heb je hier geen last van, en alleen de normale 'wear en tear' van de SD kaaart. Een oplossing kan zijn een UPS te gebruiken, dat automatich netjes afsluit als de voedingsspanning wegvalt. Zelf heb ik een poging gedaan met het 'read only' maken van de SD, zodat bij normaal gebruik het OS niet kan schrijven en de hele schrijfaktie dus ook niet fout kan gaan.

Zie ook https://zeilersforum.nl/index.php/forum-hoofdmenu-37/raspberry-pi-arduino-etcetera/585858-raspberry-met-openplotter-op-readonly-fs#1114702 gaat hier nu ruim vier maanden dagelijks uit en aan via de voedingspanning schakelaar en tot nu toe geen problemen. (Behaalde resultaten in het verleden.....)

brambo schreef :
Een correctie het woord prutsers moet vervangen worden door zeilprutser. Omdat bij meervoud anderen zich ook mogelijk voelen aangesproken. Mijn excuses voor deze omissie. Groet, Bram

Gek genoeg is dit relatief eenvoudig als project. Goed te doen inderdaad met studenten.

Een ander probleem wat hier opgelost moet worden: Persoonlijke beschermingsmiddelen. Mondkapjes.

In 2 weken een machine bouwen waar die dingen in de miljoenen uit komen, is gek genoeg, een stuk ingewikkelder. Niet zo sexy, maar even noodzakelijk.

Evengoed een leuke opsteker voor de RPI als t ze lukt.

Joop66 schreef : Precies.

Helaas heb ik geen kennis op het gebied van textiel productie.

Zo zijn er zogenaamd ook tekorten voor gezicht beschermers en die worden nu zelfs 3D geprint, en de productie bedrijven waaronder ook een spuitgieter om mij heen die ik 2 weken geleden heb gebeld gingen hun productie toen al terugdraaien naar 50%......
Zij kopen alleen materiaal in als ze er ook productie voor hebben en de groothandelaren kopen ook geen materiaal in bij de fabrikanten, en dan heb je straks ook geen materiaal meer.......
Met een goedgekeurd model heb je in 2 dagen de mal klaar en kunnen ze in productie, prima te handelen en waarschijnlijk goedkoper dan nu als je de tekening beschikbaar stelt aan iso bedrijven en dan garandeert er minimaal 10.000 per bedrijf af te nemen.

Dat geld ook voor die 3D geprinte koppelstukjes van de longmachines en ik hoorde dat er ook aan mondstukjes voor de slangen te korten waren, ondertussen zitten er ontwerpers, draaiers, frezers, mallen en instrumenten makers thuis en staan er een heleboel machines stil......

Ik heb deze visie 2 weken geleden gedeeld binnen mijn netwerk, ik kreeg alleen een vraag naar mondkapjes, helaas is dat niet mijn kennisgebied.

Beste Dirk,

een computer systeem goed afsluiten is bij alle systemen aan te raden om corruptie van files te voorkomen.

Of een read-only instelling de oplossing is ? Er zijn allerlei applicaties die bij het afsluiten de actuele stand van zaken wegschrijven. Dat doet ook OpenCPN.

Ik gebruik al geruime tijd allerlei RPI's en nog geen problemen met de SD kaartjes ervaren, anders dan een loszittende contactpuntje. Deze SD kaart is onder garantie door de fabrikant vervangen.

De betreffende fabrikant geeft 10 jaar garantie op de kaartjes.

Aan boord heb ik een doosje met een aantal back-up SD kaartjes. Die heb ik nog nooit hoeven aanspreken. Waar praten we over. Zo'n kwalitatief hoogwaardig en snel kaartje koop je voor circa € 15,-.

Met Pi-clone software (SD-copy), die standaard in Raspbian zit, maak je eenvoudig een reserve kaartje. Ook nog van het ene naar het andere formaat.

Ander kaartje erin en je hebt in 10 tellen weer een vanouds werkend navigatie systeem.

Groet,

Bram

Het gaat in dit draadje om het be-ademing apparaat met de interne raspberry.
Als de zuster het apparaat in haar haast opeens los koppelt kan de techneut een ander kaartje gaan halen. Of opnieuw het opstarten regelen met een apart scherm. Niet altijd hoor, toegegeven meestal gaat het goed. Maar Murphy komt zeker langs . De zuster kan ook niet gaan staan wachten op het lange opstarten. Het gaat om mensenlevens.

Je schijft het zelf net Bram: quote: een computer systeem goed afsluiten is bij alle systemen aan te raden om corruptie van files te voorkomen.
unquote.

De raspberry is precies daarom gewoon niet de beste oplossing voor dit project. Je wil dit niet!

Oh, begrijp me niet verkeerd, de raspberry is echt een mooi bordje. En ook leuk voor aan boord, ik geef het met alle plezier toe. Er zijn miljoenen verkocht met die zeker lage prijs.
Maar er zijn echt beperkingen. Er is nu eenmaal weinig I/O en weinig seriele poorten beschikbaar. En de voeding en SD beperken het ook. Dat is echt geen probleem, en er zijn allerlei oplossingen beschikbaar. Met losse printplaatjes , aparte voedingen etc. Dat weet ik, en dat hoef je niet te herhalen.

De studenten hebben de raspberry gebruikt. Prima. Het zal ook best wel werken. Proof of concept , dat idee.
Toch weet ik zeker dat wanneer versie 2 komt er een embedded oplossing in zit. Waarom? Omdat ik al 30 jaar elektronica projecten ontwerp. En gewoon weet dat dat wel de beste oplossing is. Dat is geen arrogantie, zo ben ik niet. Sorry als het zo overkomt.
Ik zou het zelf overigens niet durven om de raspberry te gebruiken voor dit project. En ik hoop ook dat ik niet ziek wordt. Je zal maar extra lucht nodig hebben en ze komen met dat apparaat aanzetten....

Als een schilder mij verteld dat ik beter 2 componentenverf kan gebruiken, dan ga ik dat niet eigenwijs tegen zitten spreken. Ik kan vragen naar de motivatie, dat wel. Maar hij heeft de kennis en de ervaring die ik zelf niet heb. Dan kan ik natuurlijk beslissen om toch latex te gebruiken. Maar of dat dan slim is? Ik denk het niet.

Nogmaals, het gaat hier niet om een broodje kroket.

noot:
Overigens wil ik jou niet overtuigen Bram, ik ga niet met je in een zinloze discussie. Ik geef een inhoudelijke reactie met mijn technische kennis waarom ik denk dat embedded in dit project de beste oplossing is, en ze daar voor hadden moeten kiezen.
Omdat het in dit draadje nu eenmaal over gaat. Met zeilen heeft het niks te maken, maar dat gebeurt vaker hier momenteel.

brambo schreef :
Wellicht lichtelijk off-topic (hoewel, niet als je naar de titel van het draadje kijkt), maar daar heb ik dus helemaal niet zulke goede ervaringen mee. Dat klonen probeer ik dan met een USB micro-SDcard readertje dat onder Windows prima functioneert, maar om één of andere reden stopt het schrijven vaak al na korte tijd en gebeurt er helemaal niets meer.

Voor een rpi in een beademingsapparaat gebruik je zeer waarschijnlijk een SOM.
En beademingsapparatuur krijgt een eigen accu om continu door te draaien natuurlijk.

Uitschakelen doe je alleen naar stand by.

Okay, goed punt. Er is altijd wat te verzinnen, maar mijn punt is duidelijk.
En je hoeft het ook helemaal niet met mij mee eens te zijn uiteraard!!
Gelukkig niet, want het is een zeilersforum. En dit is geheel off topic.
Ik snap eigenlijk ook niet waarom ik toch weer reageer.

nb: ik heb in de jaren wel een paar projecten gedaan met rpi hoor. Uiteindelijk is de klant de koning.
Maar vrolijk wordt ik er nooit van. En dat is dan weer emotie.

Meekletsen is altijd leuk als je totaal geen sjoege hebt van hoe een IC met apparatuur omgaat. Leuk om toch weer even je puntje te maken, dat dan weer wel.

roozeboos schreef : Ik zou als ik jou was dan maar snel met hun contact opnemen de gegevens staan op hun site.

Het blijft sneu dat jullie blijven denken dat dit niet kan omdat bij jullie zelf de kennis ontbreekt om dit voor elkaar te krijgen.

De bewijzen dat dit wel kan worden gewoon genegeerd.
Ook de kennis hoe het hier is toegepast en of zij die kennis in huis hebben is ons allen onbekend, op de pi draait misschien alleen het beeldscherm en bij uitval draait het systeem misschien wel gewoon door.

Deze Game-PC bouwers hebben er bijvoorbeeld ook wel goed over nagedacht hoor:
maingear.com/LIV/

De volgende ziet er wel iets minder uit omdat een mooie strakke behuizing ontbreekt, dat zegt niets over de werking (die ik niet kan beoordelen) maar 99% kan daar al niet doorheen kijken, als het doosje niet mooi is kan het product ook niets zijn: www.bbc.com/news/technology-52251286
Hij deelt ook het project ook nog: github.com/Mascobot/pandemic-ventilator-2.0

In ieder geval heeft Raspberry maar alvast de productie opgeschroefd:
www.extremetech.com/extreme/30...rs-to-fight-covid-19

roozeboos schreef :
Roos, en toch dank ik je voor t reageren. Dit keer is mij volstrekt helder geworden welke beperkingen en problemen je ziet voor een RPi en tegelijkertijd ook welke voordelen een dedicated pcb heeft.

De betrouwbaarheidsproblemen die WadnWind heeft gevonden voor de SD kaarten, kan ik me ook zomaar voorstellen. Dan kun je honderd keer garantie hebben, als je er niet meer bij kunt, heb je daar niks aan.

Een reactie is hier zinloos. De TU Delft is een hoogstaand technisch instituut. Het zijn niet zo maar een 30 tal studenten die wat aan het knutselen zijn.

Dit gebeurd, zeker gezien het belang van het project, onder de begeleiding van diverse professoren en ingenieurs.

Uiteraard met een voor de taak toegesneden Linux software. En uiteraard ingericht voor ononderbroken werking.

Derhalve zijn alle opmerkingen en goed bedoelde adviezen, die hier gemaakt worden, niet van belang.

Bram

zou je ook korting krijgen op de behandeling met dat Framboos geval?

brambo schreef :
Klopt, die houden zich zeer waarschijnlijk netjes aan de sd-card richtlijnen die netjes gedocumenteerd zijn op raspberrypi.org. Voor wie het linkje gemist hebben, even teuglezen.

Blijkbaar is een bevinding zonder verdere info genoeg om ihet apparaat als onbetrouwbaar af te doen. Zou je wachten uit die hoek.

.

Jammer dat je geen technisch onderbouwde reactie geeft,Bram. Dan is het inderdaad zinloos.
De studenten zullen erg slim zijn (alhoewel, het zijn studenten, die het nog moeten leren, anders waren ze geen studenten) en de professoren nog veel slimmer. En 30, is ook maar een getal. Als je negen vrouwen tegelijk zwanger maakt heb je echt niet in 1 maand een baby. En ze hebben ook verschillende opleidingen zoals ik begreep.
Dat terzijde.

Maar, en ik sta open voor alle technisch inhoudelijke suggesties , Kan iemand me uitleggen waarom je een operating system nodig hebt voor het aansturen van een aantal pompjes en klepjes? En het weergeven van wat menuutjes op een kleur lcd?
Dat kun je niet, want die uitleg is er niet!

Bijvoorbeeld , de multiview heeft een behoorlijk mooi scherm met allerlei functies, dials en grafieken en al.. Wat ingangen , touchscreen etc, ook nog een RS485 bus voor het uitsturen van schakelmenu'tjes en van alles. Maar dus Geen operating system. Want dat is in de multiview niet nodig. Ook niet in de Roosmux, die met 8 serïele poorten draait.
niet nodig omdat de software zelf bepaalt wat er gebeurt. De gebruiker kan een knop drukken, maar dan nog is de gewenste actie al bekend. Het geheugen gebruik is van tevoren bekend en staat vast.

Het probleem met een operating system is dat in feite dezelfde controller ( ik ga even uit van 1 per systeem) meerdere functies tegelijk kan uitvoeren. Denkt de niet zo technische gebruiker, weet hij veel.
Maar dat kan helemaal niet. De controller kan maar 1 ding tegelijk. En worden de verschillende actieve draadjes heel snel achter mekaar uitgevoerd. Daarvoor moeten processen worden stilgelegd, geheugen moet worden gedeeld, een draadje mag niet teveel geheugen gebruiken, een draadje mag de controller niet voor zichzelf houden en de tijd tussen de draadjes moet functioneel worden verdeeld. De controller weet eigenlijk niet meer wat ie aan het doen is, afgezien dan van het aflopen van de draadjes. De programmeur heeft veel minder overzicht. Het programmeren verschuift meer naar het heel houden van de draadjes. En niet naar het slim en robuust programmeren van het programma zelf.
Vaal worden er ook veel draadjes gemaakt, want dat is zo lekker handig. Ieder knopje zijn eigen draadje....
Gaat het fout bij een van die punten, krijg je bijvoorbeeld dat een deel geheugen van een ander draadje wordt overschreven. Dat draadje heeft dan corrupte data, en in windows zie je dan het blauwe scherm. Of een draadje die toch de boel vasthoudt, nog erger.
NB: ik weet dat er slimme manieren zijn om het op te vangen, maar het gaat even om het globale plaatje.

Maar zie je het verschil tussen de multiview en een desktop pc met al dan niet linux? Het operating system is erg handig voor een desktop, want je kan alles mooi delen tussen verschillende apps en programma's. Een OS is dan echt nuttig en zelfs noodzakelijk.
Maar voor een dedicated apparaat zoals een be-ademer vergroot je alleen maar het risico van een crash.
en je wint er niks mee. Helemaal niks! En als je pech -uiteraard- hebt verlies je er alleen mee. Keep it simple stupid.

Vergeet ook niet dat de toepassing zelf , zoals het juist aansturen van de pompjes en ander spul en het inlezen van ingangen zowel voor de raspberry als embedded vanaf nul moet worden ontworpen. De raspberry met linux maar zonder programma doet niks nuttigs. Een embedded controller zonder programma doet helemaal niks.

Embedded begin je in feite met een schone lei. Je schrijft een paar files met C of C++code, en je kan heel simpel functie voor functie testen. Je test of de data die binnenkomt klopt en binnen de grenzen valt.. En met een beetje ervaring gaat dat erg snel.
Je kan ook een verdeling maken tussen de verschillende programmeurs als je dat wil.
Bij de raspberry is er zelfs nog een kans dat ze bijvoorbeeld node-red gebruiken, een soort overkoepelend programma, waarmee je simpel en snel kunt programmeren. Want dat gaat zo lekker snel, ik gebruik het ook op mijn lnux server .
Maar ohoh, als daar maar geen bugs in zitten.

Ik zit niet zomaar in de lucht te toeteren. Vanwege de (complexe) LAN interface in de roosmux 2020 was het erg handig om een operating system te gebruiken. Heeft me erg veel tijd gekost. En hoe meer je toevoegt hoe meer je in de problemen komt. Niet fijn.
Hij is ook nog niet klaar. . Ik zal daar wel niet slim genoeg voor zijn.


Nou nu begin ik op Peper te lijken, ophouden maar.

Maar goed, dus waarom een operating system. En waarom jezelf limiteren op de hardware van de pi. die in de basis maar een handjevol I-o heeft, voor dit project vast te weinig.
Voor een grote telcom heb ik een raspberry opsteekprint gemaakt, met daarop een grote FPGA. dan kun je in ieder geval wat meer. Maar uiteindelijk moet je ook dan weer via de header naar de controller, erg beperkend in performance.

brambo schreef : Dat gevoel ken ik wel ja....

brambo schreef : De één noemt het knutselen een ander met wat meer zelfspot noemt het prutsen, de universiteit noemt het bijvoorbeeld technologisch onderzoek.
Uiteindelijk heb je op elke Universiteit een heleboel geweldige jong volwassenen met een heleboel praktische en theoretische kennis, veelal op hele specialistische gebieden die in een team met en ook zeker zonder begeleiding tot hele mooie resultaten komen.
Ook ik maak dankbaar gebruik van deze "jongens"

Natuurlijk kun je een dedicated pcb ontwerpen die precies doet wat er gevraagd wordt. Vervolgens moet die dan in grote aantallen geproduceerd worden, wil je tenminste voor elkaar krijgen dat zoveel mogelijk partijen dat ontwerp gaan gebruiken.
Makkelijker is een een generiek apparaatje te nemen dat zich door en door bewezen heeft, daar een uitgeklede Linux-versie op te draaien die ontdaan is van alle processen die niet nodig zijn en je hebt je oplossing. De Pi is zo'n apparaatje. En hij is goedkoop, ook fijn als je grote hoeveelheden nodig hebt. Er zijn Pi's met de juiste software die permanent draaien zonder enige onderbreking. Niet zeuren over de voeding, want elk apparaat wat voor dit doel ingezet gaat worden heeft een stabiele voeding nodig.
Groot voordeel is dat het ontwikkelteam zich bijna louter op de software hoeft te richten, want de hardware is er al en is in ruime mate voorhanden.
De tijd dat we voor elke taak een ander apparaat nodig hadden ligt al ver achter ons. Een cpu kan het ook.

Zo langzamerhand beginnen de uitlatingen van sommigen hier die die niet wensen te begrijpen dat complexe ontwikkelingen nu eenmaal veel beter opgelost kunnen worden door een breed team pathetisch vormen aan te nemen.

...wel voorspelbaar, toggg??

TuuLeVi schreef :
Ja, maar net als de uitlatingen van de huidige president van de VS, die denkt dat hij de enige in de wereld is die de mensheid (amerikanen) kan redden, het behoorlijk irritant te worden. Zeker als een team prestatie als waar dit draadje over gaat weer volgescheten moet worden. Ik ben die wagens met stront wel zat.