Hallo Zusammen, hat jemand einen Tipp bezüglich der Überwachung/Steuerung mit einem MiniRechner. Es gibt Raspberry P, BeagleBone, PCDuino, etc... Dieser soll Systemkritische Parameter aufzeichnen und gegebenenfalls eine Anlage ausschalten. Daher ist die Leistung nur zweitrangig. Die Größe dürfte jedoch eine Rolle spielen. Der Odroid U3 hat beispielsweise keine GPIO, nur per externen Modul. Daher würde für mich Raspberry PI2 B und BeagleBone in die nähere Auswahl kommen. Auch pcDuino 3 scheint interessant zu sein.
Ha. Ja. Dann mach doch einfach mal. Die Hardware muss zuverlaessig sein. Das Interface zur realen Welt muss zuverlaessig sein. Und die Software muss zuverlaessig sein.
Mike29 schrieb: > hat jemand einen Tipp bezüglich der Überwachung/Steuerung mit einem > MiniRechner. Es gibt Raspberry P, BeagleBone, PCDuino, etc... Dieser > soll Systemkritische Parameter aufzeichnen und gegebenenfalls eine > Anlage ausschalten. Schön, also eine Echzeitanwendung. Damit kannst du all den aufgezählten Quatsch nahezu komplett vergessen. Das wäre nur als Hardwaregrundlage geeignet, aber nicht mit dem OS, was da jeweils ab Werk drauf läuft. Das ist meist ein mehr oder weniger räudiges Linux, was sich bestenfalls notdürftig echtzeitfähig machen läßt, aber harten Echtzeitforderungen, wie sie für die Notauschaltung von Anlagen verpflichtend sind, nicht standhalten kann. > Daher ist die Leistung nur zweitrangig. Das stimmt. Mit wirklichen Echtzeitsystemen reicht oft ein Bruchteil der Leistung dieser Linux-gebremsten Scheiße, um die Anforderungen zu erfüllen. Allerdings ist das Programmieren dafür ein "klein wenig" anstrengender, man muß nämlich tatsächlich wissen, was man tut. C&P-"Programmieren" funktioniert auf solchen Plattformen nur sehr eingeschränkt...
Mike29 schrieb: > Dieser > soll Systemkritische Parameter aufzeichnen und wie kommt er an die ran? Per I2C, SPI, UART, RS485, USB, TCP/IP, Gedankenübertragung,...? > und gegebenenfalls eine > Anlage ausschalten. Und wie soll er das machen? Aus seinem Gehäuse kriechen und auf das Not-Aus hauen? Wie schnell muss das Teil reagieren? ns, µs, ms, s,...?
Nach der Aufgabenstellung bist du mit einem stinknormalen uC besser bedient. Vielleicht auch ein STM32 oder irgendein PIC (evtl. auch mit einem RTOS). Aber dafür ein Raspberry, dass mit einem Linux über zig Abstrahierungsebenen auf die Hardware zugreift? Eher nicht. Und einfacher ist es wahrscheinlich auch nicht.
c-hater schrieb: > Schön, also eine Echzeitanwendung. Damit kannst du all den aufgezählten > Quatsch nahezu komplett vergessen. Nahezu...ja. Der BeagleBone hat aber extra dafür noch 2 PRUs. Nils Friess schrieb: > Nach der Aufgabenstellung bist du mit einem stinknormalen uC besser > bedient. Je nach dem was für "systemkritische Parameter" das sind. Bei ein paar Sensorwerten stimme ich dir zu.
Die GPIO Schnittstellen eines Raspberry sind so lahm, da kannst du gleich jeden anderen PC nehmen und mit USB Adaptern arbeiten. Wobei ich den anderen Antworten zustimme, dass Linux und Windows für Echtzeitanwendungen (wenn es denn diese Anforderung gibt) denkbar schlecht geeignet sind. Nicht ohne Grund wird jeder normale Tischcomputer durch zahlreiche Mikrocontroller unterstützt, nämlich da, wo exaktes Timing nötig ist oder kurzzeitige Aussetzer nicht akzeptabel sind: Mäuse, Tastaturen, Soundchip, Batterie-Management, WLAN, Bluetooth ...
Was soll denn genau Überwacht/Gesteuert/Abgeschaltet werden? Wie kritisch ist es, was passiert im Fehlerfall (z.B. Personenschaden) und wie schnell muss die Steuerung/Abschaltung sein?
Es gibt noch eine Art Treiber-Karte, die dazwischengeschaltet werden soll. Es ging viel mehr darum einen kleinen Computer zu wählen, der bestimmte Paramter wie aufzeichnet, aber nicht im Millisekunden-Bereich sondern alle paar Minuten einen Wert. Eine Art Slow Control System
Stefan Us schrieb: > Wobei ich den anderen Antworten zustimme, dass Linux und Windows für > Echtzeitanwendungen (wenn es denn diese Anforderung gibt) denkbar > schlecht geeignet sind. Kommt drauf an. Es wurde nirgends erwähnt, welche Reaktionszeiten das Gerät einhalten muss. Wenn die unter 40 µs liegt, wird's dann tatsächlich auch mit einem Echtzeit-Kernel + gut gewählten Board nicht mehr hinhauen. Frank schrieb: > Nils Friess schrieb: >> Nach der Aufgabenstellung bist du mit einem stinknormalen uC besser >> bedient. > > Je nach dem was für "systemkritische Parameter" das sind. Bei ein paar > Sensorwerten stimme ich dir zu. Ich würd ganz allgemein sagen, daß das Überwachungssystem immer möglichst einfach aufgebaut sein sollte. Je geringer die Komplexität, desto weniger kann ausfallen. Blinky schrieb: > Was soll denn genau Überwacht/Gesteuert/Abgeschaltet werden? > Wie kritisch ist es, was passiert im Fehlerfall (z.B. Personenschaden) > und wie schnell muss die Steuerung/Abschaltung sein? Außerdem: Was soll bei einem Ausfall des Überwachungssystems passieren? Wenn der RasPi nicht mehr bootet, weil die SD-Karte korrupt ist, sollte das ja irgendwie bemerkt werden, sonst ist die Überwachung komplett nutzlos.
Vielleicht habe ich mich falsch ausgedrückt. Im Prinzip gibt es eine Art Treiberkarte, die alles steuert. Diese kann auf Sensoren reagieren etc.. Über den MikroComputer sollen nur die Werte der Treiberkarte gespeichert oder aufgezeichnet werden. Also wie ein normaler Computer, der über eine Software Werte aufzeichnet. Das man per Eingabefelder bestimmte maximalwerte eingibt und an die Treiberkarte übermittelt. Diese hat z.b. auch I²C Verbindung. Das Sysystem muss nicht schnell laufen und auch keine Anlagen direkt ausschalten. Deswegen auch die Bezeichnung Slow Control System!!!
Mach mal Butter bei die Fische und nenne endlich mal zahlen. Sampelrate? Wieviele Sensoren? Was für eine physikalische Schnittstelle? Was für Protokolle?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.