Hallo zusammen.
Ich habe mir als Hobby-Projekt vorgenommen, ein eigenes
Kraft-Wärme-Kopplungs-Aggregat zu bauen, welches von einer
embedded-Lösung gesteuert und geregelt wird.
Es handelt sich um einen Dieselmotor, der einen Generator antreiben soll
und die Abwärme vom Dieselmotor (wassergekühlt) der Werkstattheizung
eingespeist werden soll: Blockheizkraftwerk.
Folgendes soll möglich sein:
- Momentanwerte wie Vorlauf-/Rücklauftemperatur auf einem Webinterface
darstellen (Webserver auf dem Embedded-System)
- Wertspeicherung von z.B. Einschaltdauer/Temperaturverläufen in einer
DB
- Autarke Start- und Stopprozeduren auf dem Webinterface "BHKW
starten/stoppen"
- Drehzahlregelung des Dieselmotors mittels Schrittmotor (Gestänge an
die Einspritzanlage)
Überschlagen sollten etwa 8 Analogsensoren (Temperaturen (NTC/PTC))
und 4 Digitalsensoren benötigt werden. Desweiteren Ausgänge für die
Steuerung einer Schrittmotortreiberstufe, der Pumpen in den beiden
Kühlkreisläufen.
Nun die Frage:
Welches System würde sich hierfür eignen? So ein Raspberry Pi wäre
ideal, wenn man damit auch echtzeitfähig wäre. Er hätte die
Webservergeschichte, GPIOs und Möglichkeiten an Bord, die Sensorik
auszuwerten.
Allerdings: er ist eben nicht echtzeitfähig, um z.B. die Drehzahl des
Motors über z.B. einen Hallsensor am Schwungrad zu ermitteln
Habt ihr Ideen, wie man das Ganze am besten mit einem bestehenden System
wie einem Raspberry Pi o.ä. aufbauen könnte?
Eine SPS wäre vermutlich nicht möglich, da sie solche Dinge wie
Webserver/mySQL nicht mitbringen würde.
Danke u. Gruß
Stefan Pöllitz schrieb:> Allerdings: er ist eben nicht echtzeitfähig, um z.B. die Drehzahl des> Motors über z.B. einen Hallsensor am Schwungrad zu ermitteln
Warum nicht? Wieviel Umdrehungen macht denn dein Motor so im Schnitt?
Wenn es nur darum geht, zeitkritisch einen Hallsensor auszuwerten, würde
ich dafür einen Attiny verweden und die Daten über UART ausgeben. Das
Progrämmchen ist ja schnell geschrieben und das ist nur ein
Minimalaufwand. Für den Rest hört sich ein PI gut an. An der einen
Messung sollte das nicht scheitern. Ich würds sogar mit dem PI mal
testen, ein Versuch ist es ja wert.
Finn
Ok Danke.
Das heißt, ihr würdet die zeitkritischen Sachen über einen AVR machen,
der die Daten dann zum Raspberry schickt?!
D.h. alles was Steuerung betrifft: AVR, was Webinterface betrifft
RaspPi?
Gruß
Stefan Pöllitz schrieb:> alles was Steuerung betrifft: AVR, was Webinterface betrifft RaspPi?
Ja, das wäre ja auch Quatsch ein Webserver auf nem AVR laufen zu lassen,
wenn es den Apache/Nginx/... auf dem PI daneben steht...
Stefan Pöllitz schrieb:> D.h. alles was Steuerung betrifft: AVR, was Webinterface betrifft> RaspPi?
Ja, das ist die Lösung nach dem derzeitigen Stand der Technik, auch wenn
das heisst, dass die wesentlichen Aufgaben von einem Winz-Controller
bearbeitet werden, das Human Interface dagegen von einem System mit der
mehrhundertfachen Rechenleistung - aber so ist das mit dem Internet der
Dinge eben. Ein "moderner" Kühlschrank braucht auch etwa 1% der
Rechenleistung zum Kühlen und 99% für die Präsenz im Internet.
Georg
Georg schrieb:> Ja, das ist die Lösung nach dem derzeitigen Stand der Technik, auch wenn> das heisst, dass die wesentlichen Aufgaben von einem Winz-Controller> bearbeitet werden, das Human Interface dagegen von einem System mit der> mehrhundertfachen Rechenleistung ...
Ist das auf einem Arbeitsplatz-PC anders, der nicht gerade mit
virtuellen Welten und Beleuchtungsberechnung für Elementardreiecke warm
gehalten wird.
Stefan Pöllitz schrieb:> Ich habe mir als Hobby-Projekt vorgenommen, ein eigenes> Kraft-Wärme-Kopplungs-Aggregat zu bauen, welches von einer> embedded-Lösung gesteuert und geregelt wird.
Schön und nützlich. Wenn auch nicht wirklich eine neue Idee...
> - Momentanwerte wie Vorlauf-/Rücklauftemperatur auf einem Webinterface> darstellen (Webserver auf dem Embedded-System)> - Wertspeicherung von z.B. Einschaltdauer/Temperaturverläufen in einer> DB> - Autarke Start- und Stopprozeduren auf dem Webinterface "BHKW> starten/stoppen"
Vollkommener Bullshit. Absolut nachrangiges Eye-candy Zeug. So einen
überwiegend sowieso vollkommen nutzlosen Schrott kann man später
irgendwann mal an eine funktionierende Lösung des eigentlichen Problems
andocken.
Mein Tipp: realisiere erstmal den Projektkern. Die ganzen nutzlosen
Gimmicks solltest du dabei nur insofern im Auge behalten, dass du bei
der Realisisierung der eigentlichen Sache Schnittstellen vorsiehst, an
dem dieser ganze Polter sich später leicht andocken läßt.
Auch immer bedenken was Echtzeitfähig eigentlich bedeutet.
Falls dein Programm welches steuert nicht Echtzeitfähig programmiert ist
klappt das auch nicht.
Echtzeitfähig bedeutet als erstes dein Programm läuft so ab das du in
einer bekannten zeit eine Antwort bekommst.
z.B.
Falls du nun eine Schleife im Programm hast welche Daten verarbeitet wo
die Anzahl der Daten variabel ist und durch viele Daten die Antwort des
Programms nicht mehr in der bekannten Zeit beendet werden kann muss dein
Programm die Anlage abschalten, eine Meldung absetzen oder sich sonstwie
kontrolliert verhalten.
Stefan Pöllitz schrieb:> So ein Raspberry Pi wäre ideal, wenn man damit auch echtzeitfähig wäre.
Ja, ich finde das auch gruselig: da hat man einen 32 Bit uC mit 600MHz
und der kann nicht mal so eine schnarchlangsame Drehzahl (max 100Hz,
beim Diesel nur 50) eines Verbrennungotors einlesen. Eigentlich schlimm,
dass man dann noch einen AVR mit 8MHz extra dafür braucht...
> ihr würdet die zeitkritischen Sachen
Das Problem ist eher die Zuverlässigkeit. So ein Raspi vertütelt sich
etwa ein mal im Jahr. Mal ist die SD-Karte kaputt. Mal reagiert er nicht
mehr auf WLAN...
Für Logging und Webserver ist das gut genug. Von einer Steuerung dagegen
erwartet man, dass sie 20 Jahre vollkommen unauffällig funktioniert.
Komisch, wenn ich mit meinem 40tonner und 650PS bei Edeka einkaufen will
bekomme ich keinen Parkplatz. Das man dafür extra einen Smart braucht.
@Lothar
Das entspricht Deinem Äpfel / Birnen Vergleich.
Ansich eine super Idee für die Werkstatt. Du solltest dabei aber
bedenken welche Wassertemperatur für die Heizleistung notwendig ist. Was
für einen Dieselmotor möchtest du für die Anwendung benutzen? Wenn du
länger was von dem haben möchtest, sollte der möglichst nicht unter
60-80°C Wassertemperatur laufen. Und hier ist der Knackpunkt: Ziehst du
ihm zuviel Wärme ab, wird er gar nicht mehr warm und du bekommst nur
kaltes Wasser an deiner Heizung. Ich würde mir ein paar Gedanken hierzu
machen, falls du das nicht schon gemacht hast.
Nenene schrieb:> @Lothar> Das entspricht Deinem Äpfel / Birnen Vergleich.
Mit einem gerüttelt Maß an Resignation durchaus...
Aber warum sollte ein 600MHz Bolide nicht grundsätzlich auch 50Hz
auswerten können? Irgendwer hat den doch so ineffizient programmiert
dass nicht mal das mehr möglich ist. Und soooo arg viel und "spezielle"
Ressourcen braucht es für diese Auswertung nun auch wieder nicht.
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite
>> So ein Raspberry Pi wäre ideal, wenn man damit auch echtzeitfähig wäre.>Ja, ich finde das auch gruselig: da hat man einen 32 Bit uC mit 600MHz>und der kann nicht mal so eine schnarchlangsame Drehzahl (max 100Hz,>beim Diesel nur 50) eines Verbrennungotors einlesen. Eigentlich schlimm,>dass man dann noch einen AVR mit 8MHz extra dafür braucht...
Das nennt man wohl Fortschritt . . .
Java & Co lassen grüßen!
Lothar M. schrieb:> Aber warum sollte ein 600MHz Bolide nicht grundsätzlich auch 50Hz> auswerten können? Irgendwer hat den doch so ineffizient programmiert> dass nicht mal das mehr möglich ist.
Nicht echtzeitfähig bedeutet nicht ineffizient, eher im Gegenteil.
Braucht man Echtzeitfähigkeit, dann muss man eben ein RTOS verwenden
oder den PI ohne OS laufen lassen.
Gibt es für den Raspberry kein RT-Linux?
Wenn nicht, könnte man einen ausgedienten normalen PC mit RT-Linux
bestücken - oder gar ein LinuxCNC umbauen (dank HAL sehr schön
handhabbar).
Die sauberste Lösung wäre mMn so etwas wie NuttX - http://www.nuttx.org
: echtzeitfähig, sehr schlank, läuft bspw. auf AVRs, Cortexen usw, und
bringt eine Unzahl an Modulen, u.a. Webserver, Terminal etc. mit. Wer
mag, kann da auch direkt ein Display anflanschen.
Und: kostet auch nix ;-)
Also eigentlich ist doch "Drehzahlsteuerung des Motors am Gaszug" die
einzige Aufgabe, für die ein Echtzeit-Sysem gebraucht wird. Das macht
jeder ATtiny mit Hang zur Langeweile. Und für das Ganze Web-Geraffel
kann man ja dann anfangen, wenn die Kernfunktion läuft. Dafür ist ein
Raspberry Pi doch wunderbar.
@ Lothar, Falk, Chris:
Ich verstehe euch jetzt wirklich nicht so ganz. Man muss nicht für jeden
Furz mehrere µC nehmen, aber hier bietet es sich doch geradezu an.
Auf dem PI läuft das ganze unnötige Smartphone Interface Geraffel und
die Auswertung, was gerne auch mal Memory Leaks haben kann oder wegen
einer defekten SD Karte mal spinnt, und der µC kümmert sich um die
Regelung des Kernsystems und läuft zuverlässig über viele Jahre.
Saubere Trennung zwischen Präsentation Layer und Kernfunktion. Ansonsten
muss man doch bei jeder Erweiterung des Webblödsinns damit rechnen, dass
die Regelung selbst im Falle eines fatalen SW Fehlers in Mitleidenschaft
gezogen wird.
Der Andere schrieb:> @ Lothar, Falk, Chris:> Ich verstehe euch jetzt wirklich nicht so ganz.
Ich versuche das mal zu erläutern :-)
> Man muss nicht für jeden> Furz mehrere µC nehmen, aber hier bietet es sich doch geradezu an.> Auf dem PI läuft das ganze unnötige Smartphone Interface Geraffel und> die Auswertung, was gerne auch mal Memory Leaks haben kann oder wegen> einer defekten SD Karte mal spinnt, und der µC kümmert sich um die> Regelung des Kernsystems und läuft zuverlässig über viele Jahre.
Genau deshalb sehe ich das kritisch. Warum sollte man sich ein Monster
wie Raspberry/Linux antun, nur um einen Webserver zu implementieren?
Und: natürlich steigt die Ausfallwahrscheinlichkeit eines Systems mit
der Anzahl der Komponenten. Für solch eine Anwendung reicht im Prinzip
ein STM32F0-Discovery (oder auch ein AtMega) - ganz ohne SD-Karte usw.
Fällt der (einzige) µC aus, dann ist das Ergebnis dasselbe wie bei
Deiner Lösung. Fällt er nicht aus, erspart man sich den zusätzlichen
"Unsicherheitsfaktor" Raspberry + Anbindung + Linux.
Dazu spart man sich die Arbeit der Schnittstellenimplementierung
zwischen MC und Raspberry mit Checksummen usw.
In NuttX bspw. gibt es saubere Schnittstellen, um Daten zwischen
abgeschotteten Prozessen auszutauschen.
Auch mechanisch (Steckverbindungen!) ist das verwenden mehrerer
Komponenten die schlechtere Lösung.
> Saubere Trennung zwischen Präsentation Layer und Kernfunktion. Ansonsten> muss man doch bei jeder Erweiterung des Webblödsinns damit rechnen, dass> die Regelung selbst im Falle eines fatalen SW Fehlers in Mitleidenschaft> gezogen wird.
Das kann man auch auf einem Chip softwaremäßig problemlos trennen - man
muss es nur tun. Ein (hier POSIX-konformes) Echtzeitbetriebssystem
bietet sich dafür an. Unter NuttX bspw. kann man das problemlos auf
verschiedene Prozesse aufteilen, die alle sauber getrennt sind.
Zusammengefasst: weniger Aufwand (nur ein Zielsystem), weniger
Energiebedarf, weniger Platzbedarf, geringere Ausfallwahrscheinlichkeit
> Warum sollte man sich ein Monster> wie Raspberry/Linux antun, nur um einen Webserver zu implementieren?
Ist ja nicht nur der Webserver. Man braucht auch irgendeine Art von
Datenbank, zeitgesteuertes Backup, Fernwartung vom Smartphone... Und bis
alles so wirklich rund läuft, muss man es 10 mal umbauen.
Z.B. Du hast die Idee, Heizung nach Wettervorhersage zu regeln. Auf so
einem Monster bastelst du dir einer 1/2 Stunde cronjob, rrdtool, init.d
und Weboberfläche zusammen. Wenn es nichts bringt, versuchst du es mit
der nächsten Strategie.
Wenn du aber 100 Anlagen verkaufst, und für 100 Anlagen Support machst -
auf keinen Fall irgendwas mit SD-Karte und undurchschaubarem
Betriebssystem.
Noch einer schrieb:>> Warum sollte man sich ein Monster>> wie Raspberry/Linux antun, nur um einen Webserver zu implementieren?>> Ist ja nicht nur der Webserver. Man braucht auch irgendeine Art von> Datenbank, zeitgesteuertes Backup, Fernwartung vom Smartphone... Und bis> alles so wirklich rund läuft, muss man es 10 mal umbauen.>> Z.B. Du hast die Idee, Heizung nach Wettervorhersage zu regeln. Auf so> einem Monster bastelst du dir einer 1/2 Stunde cronjob, rrdtool, init.d> und Weboberfläche zusammen. Wenn es nichts bringt, versuchst du es mit> der nächsten Strategie.
Ja, das stimmt natürlich. Ich komme eher aus dem Bereich der
Industriesteuerungen (Prozesschemie) - das färbt auf die Denkweise ab
;-)
Es ist immer die Frage, wie verspielt das Ganze sein soll. Ob man für
ein paar Werte wirklich eine MySQL-Datenbank benötigt, muss natürlich
jeder selbst entscheiden. Fernwartung per Smartphone sollte sich über
den Webserver selbst erledigen lassen.
Und mit der Lösung hat man eben noch nicht die Daten selbst zuverlässig
im Raspberry. Das Interface inkl. Fehlererkennung etc. müsste man
zusätzlich schreiben.
> Wenn du aber 100 Anlagen verkaufst, und für 100 Anlagen Support machst -> auf keinen Fall irgendwas mit SD-Karte und undurchschaubarem> Betriebssystem.
Ja, das sollte man tunlichst vermeiden.
Weil es gerade so gut passt:
Beitrag "RAspberry PI 2 zerstört?"
Bei vielen Komponenten kann eben auch viel kaputt gehen.
Die Frage an den OP ist: wie (ausfall-)sicher muss das Ganze sein?
Wie alt ist denn der Diesel? Wenn das schon ein etwas modernerer ist,
kann man über OBD II abfragen und mit einem MC dann regeln.
Reginald L. schrieb:> sollte der möglichst nicht unter> 60-80°C Wassertemperatur laufen.
Das sollte man über den Thermostat des Kühlkreislaufs in den Griff
bekommen. Bei den typischen 87°C öffnet der Thermostat und ab da kann
man dann die Heizleistung in den Wasserkreislauf schicken. Interessant
ist die Frage des Abgaswärmetauschers, der ein hübsches Stück
Schweissarbeit werden kann.
Chris ich kann deiner Argumentation folgen, sehe as aber für ein
Bastlerprodukt dann anders. Softwareseitig (als Bastler!) beide Systeme
auf einem Rechner zu trennen, so daß das eine das andere nicht mitreißen
kann ist nicht so einfach. Zumindest nicht, sobald du ein Betriebssystem
drauf hast, das dir die Programmierung des Webservers, die Archivierung
etc. einfach macht.
Und du wirst halt sehr viel schneller sein auf einem Raspi eine
Speicherung der Daten plus Analyse, plus leistungsfähiger Web Server
hinzukriegen, als wenn du auf einem AT Mega erst mal anfängst dir einen
TCP/IP Stack
zusammenzusuchen, oder dich gar in ein für dich neues RTOS einarbeiten
musst.
Du kommst halt beruflich aus der Ecke und hast alles was du brauchst
schon parat. :-)
Und ich verstehe schon den eigentlichen Irrsinn, dass ein 600 MHz
Bolide, der sich als Web-Server auch zu 99% langweilt nicht noch in der
Lage sein soll eine Drehzahl von 50U/s zu messen und 5 mal pro Sekunde
einen neuen Stellwert für einen PI(D) Regler auszurechnen.
:-)
Stefan Pöllitz schrieb:> Es handelt sich um einen Dieselmotor, der einen Generator antreiben soll> und die Abwärme vom Dieselmotor (wassergekühlt) der Werkstattheizung> eingespeist werden soll: Blockheizkraftwerk.
Ach, dass er als Generator arbeiten soll, habe ich glatt überlesen. Bei
entsprechender Last des Motors erzeugt der dann natürlich, je nach
benötigter Heizleistung, genügend Abwärme.
Matthias S. schrieb:> Interessant> ist die Frage des Abgaswärmetauschers, der ein hübsches Stück> Schweissarbeit werden kann.
Sowas wird aber selbstgeschweißt nicht lange halten.
@ Der Andere (Gast)
>Ich verstehe euch jetzt wirklich nicht so ganz.
Sowas kommt vor ;-)
> Man muss nicht für jeden>Furz mehrere µC nehmen,
Eben!
> aber hier bietet es sich doch geradezu an.
FALSCH! Es ist NÖTIG, eben weil man den Raspberry Pi in Normalausführung
(incl. Linux) eben nur mit SEHR VIEL Aufwand soweit echtzeitfähig
bekommt, wie es ein kleiner AVR ohne Linux problemlos kann.
Man müßte wahrscheinlich ein Kernelmodukl schreiben, das mit hoher
Priorität an einem Timer hängt. Vielleicht geht es auch ohne
Kernelmodul, keine Ahung.
>Auf dem PI läuft das ganze unnötige Smartphone Interface Geraffel und>die Auswertung, was gerne auch mal Memory Leaks haben kann oder wegen>einer defekten SD Karte mal spinnt, und der µC kümmert sich um die>Regelung des Kernsystems und läuft zuverlässig über viele Jahre.>Saubere Trennung zwischen Präsentation Layer und Kernfunktion.
Ja, aber die muss nicht zwingend in Hardware erfolgen.
>Ansonsten>muss man doch bei jeder Erweiterung des Webblödsinns damit rechnen, dass>die Regelung selbst im Falle eines fatalen SW Fehlers in Mitleidenschaft>gezogen wird.
Auch das spricht für die getrennte Hardwarelösung, ist aber dennoch ein
Armutszeugnis für einen 600MHz Boliden.
