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?
Warum nicht die Aufgaben auf verschiedene µC verteilen? Dazwischen ein RS485 Bus. Das System soll sicher auch Fehler abfangen können oder?
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ß
Vor Jahren habe ich damit Versuche angestellt: http://vonkonow.com/wordpress/2012/01/software-for-home-automation/ Ist eine gute Vorlage für derartige Projekte.
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.
Wieso soll auf einer SPS kein Webserver und SQL laufen? Schau mal bei Beckhoff, alles Standard. Christian_RX7
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...
:
Bearbeitet durch Moderator
> 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.
Hi, mir ist noch nicht klar, weshalb er einen uC benötigt. Soll der Diesel genau auf 50Hz Generatorfrequenz geregelt werden?
@ 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.
Falk B. schrieb: > Das nennt man wohl Fortschritt . . . > Java & Co lassen grüßen! Für die falsche Anwendung ist selbst das beste Werkzeug nutzlos.
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 ;-)
:
Bearbeitet durch Moderator
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?
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
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.