Rabauke123
Urgestein
Wenn das mit der "Verlängerungen" passen würde wärs ein Traum- endlich Lüftersteuerung mit Display in der Frontklappe meines Gehäuses!
Lüftersteuerung, Open Source Projekt
- Ersteller RS-ELEC
- Erstellt am
Wie wärs später denn mit ner Sammelbestellung der Teile? Wenn da viele bestellen sollte das denke ich ganz gut günstig werden - evtl. könnt man dann in einem nen paar Platinen bei entsprechendem Absatz irgendwo ätzen lassen...
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
Wenn wir eine fertige Version 1.0 haben, dann werde ich (bei entsprechendem Interesse) einen Schwung Platinen professionell ätzen lassen. Bei größeren Mengen ist das auch nicht so teuer.
Wer dann eine Platine über mich bezieht, dem kann ich die SMD Chips gegen einen kleinen Obolus auch schon drauf löten und die Firmware drauf machen. Ein entsprechenden Programmer hat sicher auch kaum jemand. Update geht dann nach einmaligen Bespielen per USB.
Die Steuerung wird eh aus mehreren Platinen bestehen. Eine Große, eine kleine die parallel hinter die Blende kommt (da ist dann das Display und Taster drauf) und eine kleine mit zusätzlichen Anschlüssen, weil ich nicht alle nebeneinander bekomme, Dazu ist der 5,25" Schacht zu klein... Die kommt dann im hinteren Viertel über die Hauptplatine.
Die Platine mit dem LCD kann man dann entweder direkt an die Hauptplatine Löten, oder aber mit einem Flachbandkabel absetzen.
Bis 50cm sollte das kein Problem sein.
Mfg Bimbo385
Wer dann eine Platine über mich bezieht, dem kann ich die SMD Chips gegen einen kleinen Obolus auch schon drauf löten und die Firmware drauf machen. Ein entsprechenden Programmer hat sicher auch kaum jemand. Update geht dann nach einmaligen Bespielen per USB.
Die Steuerung wird eh aus mehreren Platinen bestehen. Eine Große, eine kleine die parallel hinter die Blende kommt (da ist dann das Display und Taster drauf) und eine kleine mit zusätzlichen Anschlüssen, weil ich nicht alle nebeneinander bekomme, Dazu ist der 5,25" Schacht zu klein... Die kommt dann im hinteren Viertel über die Hauptplatine.
Die Platine mit dem LCD kann man dann entweder direkt an die Hauptplatine Löten, oder aber mit einem Flachbandkabel absetzen.
Bis 50cm sollte das kein Problem sein.
Mfg Bimbo385
Hallo,
würdest du wenn es soweit ist, das eagle Schematicfile online stellen oder mir schicken?
Eine Verbreitung meinerseits ist natürlich ausgeschlossen.
Würde es dann gerne komplett in SMD Routen, denn wenn jemand den 32er ATxmega bestücken kann, er auch mindestens 1206er SMD löten.
mfg René
würdest du wenn es soweit ist, das eagle Schematicfile online stellen oder mir schicken?
Eine Verbreitung meinerseits ist natürlich ausgeschlossen.
Würde es dann gerne komplett in SMD Routen, denn wenn jemand den 32er ATxmega bestücken kann, er auch mindestens 1206er SMD löten.
mfg René
Zuletzt bearbeitet:
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
Sooo, auch wenn ich am Donnerstag meine erste Klausur schreibe, habe ich heute mal 3-5 Stunden mit der tollen Steuerung verbracht. Mal was zur Ablenkung.
Ich hab die Pumpenregelung fertig implementiert. Also man kann jetzt eine Spannung von 5,2-9,9V vorgeben (in 0,1V Schritten), die die Pumpe dann bekommt. Da die Kennlinie des Reglers aber oben abflacht hat man bei 9,9V tatsächlich ca. 10,1V, ansonsten stimmt es aber im restlichen Spannungsbereich.
Auch der DFM wird jetzt ausgelesen. Ich mittle den Durchflusswert über 5s mit 10 Werten, da der GMR DFM ziemlich schwankende Werte ausgibt. Liegt definitiv am Sensor. Aber mit der Mittelung geht es ziemlich gut. Ich hab jetzt im Testkreislauf bei 5,2V Pumpenspannung 127L/h. Der Messbereich geht übrigens von fast 0 bis 500L/h, das sollte reichen, denke ich.
Außerdem hab ich einen fixen Bootloader gebastelt, damit ihr später auch ohne Programmiergerät Firmwareupdates machen könnt.
Die Speicherung der Einstellungswerte im EEPROM des Xmegas läuft auch. War halt viel Schreibarbeit
Es geht weiter vorwärts, um die Regeleigenschaften der Lüfterkanäle zu testen, könnte ich übrigens gut ein weitgehend funktionierendes GUI gebrauchen ;-) wie stehts denn da so?
Vor allem die Vorgabe der Min und Max werte sowie Die Lüfterspeziefischen Einstellungen müssten dafür gehen. Die langen Befehle jedesmal per Fuß ins Terminalprogramm eintippen, ist doch ziemlich aufwendig.
Was firmwareseitig noch fehlt sind:
die Alarm Modi,
die Berechnung der RPM-Werte der Lüfter,
die digitalen DS18S20 Tempsensoren,
vernünftige Display Ansteuerung,
Ansteuerung der LED-Ausgänge,
Peep Signal,
Also eigentlich nichts weltbewegendes mehr.
Wenn es jetzt keine bösen Überraschungen mehr gibt, dann denke ich, dass ich im Februar eine Version 0.1.0 raus bringen kann. Heißt dann mit fertigem Layout für den 5,25" Einschub und funktionsfähig.
Mfg Bimbo385
Ich hab die Pumpenregelung fertig implementiert. Also man kann jetzt eine Spannung von 5,2-9,9V vorgeben (in 0,1V Schritten), die die Pumpe dann bekommt. Da die Kennlinie des Reglers aber oben abflacht hat man bei 9,9V tatsächlich ca. 10,1V, ansonsten stimmt es aber im restlichen Spannungsbereich.
Auch der DFM wird jetzt ausgelesen. Ich mittle den Durchflusswert über 5s mit 10 Werten, da der GMR DFM ziemlich schwankende Werte ausgibt. Liegt definitiv am Sensor. Aber mit der Mittelung geht es ziemlich gut. Ich hab jetzt im Testkreislauf bei 5,2V Pumpenspannung 127L/h. Der Messbereich geht übrigens von fast 0 bis 500L/h, das sollte reichen, denke ich.
Außerdem hab ich einen fixen Bootloader gebastelt, damit ihr später auch ohne Programmiergerät Firmwareupdates machen könnt.
Die Speicherung der Einstellungswerte im EEPROM des Xmegas läuft auch. War halt viel Schreibarbeit
Es geht weiter vorwärts, um die Regeleigenschaften der Lüfterkanäle zu testen, könnte ich übrigens gut ein weitgehend funktionierendes GUI gebrauchen ;-) wie stehts denn da so?
Vor allem die Vorgabe der Min und Max werte sowie Die Lüfterspeziefischen Einstellungen müssten dafür gehen. Die langen Befehle jedesmal per Fuß ins Terminalprogramm eintippen, ist doch ziemlich aufwendig.
Was firmwareseitig noch fehlt sind:
die Alarm Modi,
die Berechnung der RPM-Werte der Lüfter,
die digitalen DS18S20 Tempsensoren,
vernünftige Display Ansteuerung,
Ansteuerung der LED-Ausgänge,
Peep Signal,
Also eigentlich nichts weltbewegendes mehr.
Wenn es jetzt keine bösen Überraschungen mehr gibt, dann denke ich, dass ich im Februar eine Version 0.1.0 raus bringen kann. Heißt dann mit fertigem Layout für den 5,25" Einschub und funktionsfähig.
Mfg Bimbo385
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
Ne ich denke einen 2. DFM brauche ich nicht testen. Die Frage ist ja, ob die Auswertung des Signals gut funktioniert und das tut es.
Einen Test von einem anderen DFM wird es dann sicher später von jemandem geben, der die Steuerung mit diesem einsetzen will. Wenn es da Probleme wegen flackernden Werten gibt, dann kann ich mit einem Firmwareupdate nachhelfen.
Ich denke als Nächstes würde ich mich dann um die Displayroutine kümmern. Dazu hätte ich gerne VIELE Vorschläge!
Also wir haben ja ein 3x16 Display. Ich kann also Vorschläge nach folgendem Schema gebrauchen:
NNNN ist hierbei der Platzhalter für das 4-Stellige Namenskürzel einer Temperatur. Es kann im Prinzip alles was die Steuerung weis angezeigt werden. Das sind außerdem noch:
Durchfluss,
Uhrzeit,
RPM der Lüfter(XXXXRPM),
CPU Takt und Auslastung,
GPU Auslastung,
Ram Auslastung(XXX%),
Pumpenspannung(X,XV),
Firmware Version(X.X.X),
LED Ausgänge,
Beliebige Texte,
Auch kann ich Kommastellen runden und nicht anzeigen. Falls ihr noch etwas vermisst, Fragen! Zur Formatierung bin ich für Vorschläge offen!
Ich möchte mehrere Screens hintereinander machen und die nach z.B. 5s wechseln lassen. Mit einem Taster kann man das dann auch anhalten und weiterlaufen lassen.
Bitte darauf achten, dass nur 16 Zeichen nebeneinander und 3 Zeilen untereinander passen. Außerdem immer an die maximal mögliche Größe eines Werts denken. Für ein RPM-Wert müssen halt immer 4 Stellen vorgesehen werden. Auch wenn der Lüfter meistens nur mit 600RPM läuft.
Ich hoffe auf viele Vorschläge, macht euch bitte die Mühe, schließlich kommt es euch ja auch zu Gute!
Mfg Bimbo385
Einen Test von einem anderen DFM wird es dann sicher später von jemandem geben, der die Steuerung mit diesem einsetzen will. Wenn es da Probleme wegen flackernden Werten gibt, dann kann ich mit einem Firmwareupdate nachhelfen.
Ich denke als Nächstes würde ich mich dann um die Displayroutine kümmern. Dazu hätte ich gerne VIELE Vorschläge!
Also wir haben ja ein 3x16 Display. Ich kann also Vorschläge nach folgendem Schema gebrauchen:
Code:
| NNNN: XX,X°C |
| NNNN: XX,X°C |
| NNNN: XX,X°C |NNNN ist hierbei der Platzhalter für das 4-Stellige Namenskürzel einer Temperatur. Es kann im Prinzip alles was die Steuerung weis angezeigt werden. Das sind außerdem noch:
Durchfluss,
Uhrzeit,
RPM der Lüfter(XXXXRPM),
CPU Takt und Auslastung,
GPU Auslastung,
Ram Auslastung(XXX%),
Pumpenspannung(X,XV),
Firmware Version(X.X.X),
LED Ausgänge,
Beliebige Texte,
Auch kann ich Kommastellen runden und nicht anzeigen. Falls ihr noch etwas vermisst, Fragen! Zur Formatierung bin ich für Vorschläge offen!
Ich möchte mehrere Screens hintereinander machen und die nach z.B. 5s wechseln lassen. Mit einem Taster kann man das dann auch anhalten und weiterlaufen lassen.
Bitte darauf achten, dass nur 16 Zeichen nebeneinander und 3 Zeilen untereinander passen. Außerdem immer an die maximal mögliche Größe eines Werts denken. Für ein RPM-Wert müssen halt immer 4 Stellen vorgesehen werden. Auch wenn der Lüfter meistens nur mit 600RPM läuft.
Ich hoffe auf viele Vorschläge, macht euch bitte die Mühe, schließlich kommt es euch ja auch zu Gute!
Mfg Bimbo385
Zuletzt bearbeitet:
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
So Leute es gibt gute Nachrichten!
Ich hatte ja geschrieben, dass das mit der Pumpenspannung fertig ist. Nun gefiel mir die bisher eingesetzte Schaltregler Variante von Anfang an nicht so richtig. Ist teuer, verursacht Störungen auf den Betriebsspannungen. Der Regelbereich ist von 5,2-10V auch ziemlich bescheiden.
Da hab ich gestern nicht so richtig mit einschlafen können und hab mir die Idee einer Längsregelung noch einmal durch den Kopf gehen lassen.
Ok der große Nachteil ist, dass halt die überflüssige Energie verbraten wird, also brauchen wir einen Kühlkörper.
Diese Problem hätte man theoretisch beim Schaltregler nicht. Praktisch geht der aber bei 10V quasi in die Sättigung und wird deshalb auch nicht zu knapp warm.
Kurz und knapp ich hab's auf einem Steckbrett aufgebaut und es funktioniert wunderbar!
Ich hab den gleichen FET wie für die Lüfterendstufen genommen und die sonstigen Bauteile sind nur Widerstände ein billiger OPV und ein paar Kondensatoren. Kostet alles zusammen nicht mal 1€. Nur der Kühlkörper kommt halt noch dazu.
Die Ausgangsspannung geht jetzt auch bis fast 12V. Je nach dem was angeschlossen wird. Mit der Laing DDC+ hab ich max. 11,8-11,9V. Wobei man auch beachten muss, dass ein PC Netzteil auch so +/-0.2V Toleranz hat. Runter geht die Spannung bis 0V.
Die Verlustleistung des FET ist mit einem etwas größerem Kühlkörper auch problemlos zu beherrschen. Momentan läuft die Laing DDC+ bei 9.86V (ist ungefähr Worst Case für die Verlustleistung) und den Kühlkörper kann man noch problemlos anfassen (der FET hält bis zu 175°C aus).
Für eine Dual oder gar Trippel Laing sollte man dann allerdings schon einen größeren Kühlkörper nehmen (oder WaKü ;-). Geht aber prinzipiell auch.
Natürlich ist es einfach nur eine analoge, geregelte Ausgangsspannung und ihr könnt quasi alles anschließen, was ihr für richtig haltet. Bis 15W (bei 12V) ist das kein Problem.
Somit werde ich jetzt den Schaltplan ändern und die Längsregelung in dem ersten Prototyp vorsehen. Ist billiger, besser was die Ausgangsspannung betrifft und wird nur etwas wärmer.
Es sei denn ihr beschimpft mich jetzt, etwas mehr Verlustleistung, WIE KANNST DU NUR!!!!!!!!!
Mfg Bimbo385
PS: Ja ich brauche was um mich von Morgen abzulenken...
Ich hatte ja geschrieben, dass das mit der Pumpenspannung fertig ist. Nun gefiel mir die bisher eingesetzte Schaltregler Variante von Anfang an nicht so richtig. Ist teuer, verursacht Störungen auf den Betriebsspannungen. Der Regelbereich ist von 5,2-10V auch ziemlich bescheiden.
Da hab ich gestern nicht so richtig mit einschlafen können und hab mir die Idee einer Längsregelung noch einmal durch den Kopf gehen lassen.
Ok der große Nachteil ist, dass halt die überflüssige Energie verbraten wird, also brauchen wir einen Kühlkörper.
Diese Problem hätte man theoretisch beim Schaltregler nicht. Praktisch geht der aber bei 10V quasi in die Sättigung und wird deshalb auch nicht zu knapp warm.
Kurz und knapp ich hab's auf einem Steckbrett aufgebaut und es funktioniert wunderbar!
Ich hab den gleichen FET wie für die Lüfterendstufen genommen und die sonstigen Bauteile sind nur Widerstände ein billiger OPV und ein paar Kondensatoren. Kostet alles zusammen nicht mal 1€. Nur der Kühlkörper kommt halt noch dazu.
Die Ausgangsspannung geht jetzt auch bis fast 12V. Je nach dem was angeschlossen wird. Mit der Laing DDC+ hab ich max. 11,8-11,9V. Wobei man auch beachten muss, dass ein PC Netzteil auch so +/-0.2V Toleranz hat. Runter geht die Spannung bis 0V.
Die Verlustleistung des FET ist mit einem etwas größerem Kühlkörper auch problemlos zu beherrschen. Momentan läuft die Laing DDC+ bei 9.86V (ist ungefähr Worst Case für die Verlustleistung) und den Kühlkörper kann man noch problemlos anfassen (der FET hält bis zu 175°C aus).
Für eine Dual oder gar Trippel Laing sollte man dann allerdings schon einen größeren Kühlkörper nehmen (oder WaKü ;-). Geht aber prinzipiell auch.
Natürlich ist es einfach nur eine analoge, geregelte Ausgangsspannung und ihr könnt quasi alles anschließen, was ihr für richtig haltet. Bis 15W (bei 12V) ist das kein Problem.
Somit werde ich jetzt den Schaltplan ändern und die Längsregelung in dem ersten Prototyp vorsehen. Ist billiger, besser was die Ausgangsspannung betrifft und wird nur etwas wärmer.
Es sei denn ihr beschimpft mich jetzt, etwas mehr Verlustleistung, WIE KANNST DU NUR!!!!!!!!!
Mfg Bimbo385
PS: Ja ich brauche was um mich von Morgen abzulenken...
Hoffe Deine Klausur war erfolgreich 
Hab mal ganz kurz ein paar Ideen für das display die mir durch den Kopf geschossen sind niedergeschrieben...
Ich denk nochmal in ruhe drüber nach wenn ich ein wenig Zeit hab, bis dahin:
....Die Bindestriche sind nur eine Orientierungshilfe und erscheinen natürlich nicht auf dem Display...
Sind nur grobe Ideen, dürft gerne meckern, ändern etc. :P
Man sieht sich,
P.I.Z.
Ich denk nochmal in ruhe drüber nach wenn ich ein wenig Zeit hab, bis dahin:
....Die Bindestriche sind nur eine Orientierungshilfe und erscheinen natürlich nicht auf dem Display...
Code:
Lüfter&Pumpe:
----UPM--FAN---- <-möglich währe hier auch -FAN1-FAN2-FAN3-
-XXXX-XXXX-XXXX- <-Umdrehungen der drei Lüfter Ausgänge, evtl. mit Trennzeichen "/" oder "-" etc.)
--DFM:-XXX-L/H-- <-Durchfluss in Liter pro Stunde
Temp Übersicht:
-CPU:-XX°C-XXX%- <-Auslastung-CPU(%)
-GPU:-XX°C-XXX%- <-Auslastung-GPU(%)
-H²O:-XX°C------
CPU Info:
-NNNNNNNNNNNNNN- <-Name der CPU(sollte doch gehen oder?)
-XXXXMHz--XX,XV- <-CPU Voltage (falls das geht) sonst eventuell die Auslastung?
--Temp:-XX,X°C--
GPU Info:
-NNNNNNNNNNNNNN- Das gleiche halt für die Grafikkarte auch, falls es geht...
-XXXXMHZ--XX,XV- (eventuell statt Spannung, eine 2. oder auch 3. Takt-Anzeige für Memory und Shader Clock)
--Temp:-XX,X°C--
Alternative:
-NNNNNNNNNNNNNN-
-XXXX/XXXX/XXXX- <-Core/Shader/Mem Takt
--Temp:-XX,X°C--
Alg. Info:
-NNNNNNNNNNNNNN- <-Name der Steuerung(fehlt eh noch :P)
-Version--X.X.X-
--by--NNNNNNNN-- <-mhmm wer da wohl hinkommt, man weis es nicht ^^Man sieht sich,
P.I.Z.
Zuletzt bearbeitet:
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
Sieht so weit schon mal nach einer Idee aus.
Die Namen der CPU und Grafikkarte sieht das aktuelle Protokoll noch nicht vor. Das geht vorerst noch nicht. Auch hab ich momentan nur den CPU-Takt vorgesehen.
Erstmal Danke P.I.Z., aber bitte noch mehr Vorschläge!
Mfg Bimbo385
PS: Die ersten beiden Prüfungen sind erstmal gut gelaufen. Montag Mathe...
Die Namen der CPU und Grafikkarte sieht das aktuelle Protokoll noch nicht vor. Das geht vorerst noch nicht. Auch hab ich momentan nur den CPU-Takt vorgesehen.
Erstmal Danke P.I.Z., aber bitte noch mehr Vorschläge!
Mfg Bimbo385
PS: Die ersten beiden Prüfungen sind erstmal gut gelaufen. Montag Mathe...
Wie schauts denn mit dem GUI aus? Evtl. könnte ich was in Java basteln - ist nur die Frage inwiefern dein Code da ne Unterstützung für bietet.
Hasenscharte
Enthusiast
BItte kein Java...
Und was spricht gegen Java?
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
Jep C#. Das gibts auch als kostenlose Express Version.
Damit hab ich mir den Quellcode auch schon angesehen. Geht wunderbar.
Wir verteilen die aktuellen Versionen momentan untereinander per Dropbox Freigabe. Funktioniert ganz gut. Sprech mal Nebman an, der hat bis jetzt alleine am GUI gewerkelt. Aber ich denke etwas Unterstützung ist vielleicht nicht verkehrt.
Jetzt in Java komplett neu anzufangen wäre aus meiner Sicht Quatsch.
Mfg Bimbo385
Damit hab ich mir den Quellcode auch schon angesehen. Geht wunderbar.
Wir verteilen die aktuellen Versionen momentan untereinander per Dropbox Freigabe. Funktioniert ganz gut. Sprech mal Nebman an, der hat bis jetzt alleine am GUI gewerkelt. Aber ich denke etwas Unterstützung ist vielleicht nicht verkehrt.
Jetzt in Java komplett neu anzufangen wäre aus meiner Sicht Quatsch.
Mfg Bimbo385
Wenn er unbedingt will...warum nicht? Sozusagen als parallel GUI 
Währ schon praktisch weil man dann eine Plattformunabhängige GUI hätte. Priorität sollte aber ganz klar auf der C# GUI von nebman liegen da diese einfach schon viel weiter ist!
Währ schon praktisch weil man dann eine Plattformunabhängige GUI hätte. Priorität sollte aber ganz klar auf der C# GUI von nebman liegen da diese einfach schon viel weiter ist!
Zuletzt bearbeitet:
Da der Befehlssatz ja gut dokumentiert ist (ein großes Danke an Bimbo) kann er es ja parallel dazu entwickeln.
@Hexcode: Wenn du willst kannst du dir gerne den aktuellen Stand des GUIs reinziehen, schick mir deine Dropbox-Mailaddy und ich füg dich hinzu. Wenn du Java kannst, bin ich mir sicher wirst du C# auch schon kennengelernt haben.
@Bimbo
Ich habe die GUI jetzt mal an den Befehlssatz v2 angepasst, damit der Refresh richtig abläuft. Die Felder auf der Lüfter-Seite sind zwar schon da aber einstweilen noch ohne Funktion.
Da die meisten Werte der Steuerung ja im EEPROM abgelegt sind, werden diese ja nicht aus dem Settings-File geladen sondern aus der Steuerung. Hast du sichergestellt, dass es immer brauchbare Standard-Werte gibt? Du könntest übrigens auch noch einen Befehl implementieren mit dem man den EEPROM löschen bzw. zurücksetzen kann...
@Hexcode: Wenn du willst kannst du dir gerne den aktuellen Stand des GUIs reinziehen, schick mir deine Dropbox-Mailaddy und ich füg dich hinzu. Wenn du Java kannst, bin ich mir sicher wirst du C# auch schon kennengelernt haben.
@Bimbo
Ich habe die GUI jetzt mal an den Befehlssatz v2 angepasst, damit der Refresh richtig abläuft. Die Felder auf der Lüfter-Seite sind zwar schon da aber einstweilen noch ohne Funktion.
Da die meisten Werte der Steuerung ja im EEPROM abgelegt sind, werden diese ja nicht aus dem Settings-File geladen sondern aus der Steuerung. Hast du sichergestellt, dass es immer brauchbare Standard-Werte gibt? Du könntest übrigens auch noch einen Befehl implementieren mit dem man den EEPROM löschen bzw. zurücksetzen kann...
Mit Java könnte man aber in Verbindung mit nem Tomcat-Server und Vaadin oder nem anderen Framework auch nen recht nettes online GUI hinbekommen, so dass man dann auch per Browser drauf zugreifen kann.
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
GUI schaue ich mir demnächst mal an. Momentan ist der Prototyp mit dem Xplained etwas "zerlegt" aufgrund der neuen Endstufe für die Pumpe...
Mit den gespeicherten Werten funktioniert das wie folgt:
Mit dem Bootloader schreibst du zunächst die Firmware und anschließend ein EEPROM File, was gültige (und einigermaßen Sinnvolle) Startwerte enthält. Somit hat man brauchbare Startwerte. Wenn man was am EEPROM versaut kann man einfach das EEPROM File über den Bootloader nochmal schreiben und alles ist wieder wie neu.
Das EEPROM File gibt es natürlich zusammen mit der Firmware von mir.
Schön das es mit dem GUI weiter geht. Ich würde mich ja für eine Zusammenarbeit von Hexcode und nebman aussprechen. Aber ich denke das macht ihr schon ;-)
Ich schau jetzt gerade mal nach dem Layout für die Version 0.1.0. Die ja dann in den 5,25" Schacht soll.
Mfg Bimbo385
Mit den gespeicherten Werten funktioniert das wie folgt:
Mit dem Bootloader schreibst du zunächst die Firmware und anschließend ein EEPROM File, was gültige (und einigermaßen Sinnvolle) Startwerte enthält. Somit hat man brauchbare Startwerte. Wenn man was am EEPROM versaut kann man einfach das EEPROM File über den Bootloader nochmal schreiben und alles ist wieder wie neu.
Das EEPROM File gibt es natürlich zusammen mit der Firmware von mir.
Schön das es mit dem GUI weiter geht. Ich würde mich ja für eine Zusammenarbeit von Hexcode und nebman aussprechen. Aber ich denke das macht ihr schon ;-)
Ich schau jetzt gerade mal nach dem Layout für die Version 0.1.0. Die ja dann in den 5,25" Schacht soll.
Mfg Bimbo385
Wie gesagt ich kann kein C# und auf Grund meiner Abschlussprüfungen und IHK-Prüfungen im Mai auch nicht mehr die Zeit da noch ne Sprache zu lernen 
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
Ist ja nicht so schlimm. Aber du musst zugeben, dass es jetzt wenig Sinn macht das was nebman geschafft hat wegzuschmeißen.
Es steht dir natürlich frei ein GUI in Java zu schreiben. Wenn es gut funktioniert haben wir halt 2 Versionen. Ich würde es zumindest ausprobieren.
Aber besser wäre natürlich das jetzige GUI zu unterstützen, damit wir erstmal ein voll funktionsfähiges haben.
Mfg Bimbo385
Es steht dir natürlich frei ein GUI in Java zu schreiben. Wenn es gut funktioniert haben wir halt 2 Versionen. Ich würde es zumindest ausprobieren.
Aber besser wäre natürlich das jetzige GUI zu unterstützen, damit wir erstmal ein voll funktionsfähiges haben.
Mfg Bimbo385
So, hab mal weitergebastelt und den Lüfter-Reiter vervollständigt. Was mir hier protokollmäßig allerdings abgeht ist a) die Beschreibung zur Lüfteranlaufzeit (aber da braucht man denke ich nicht viel erklären) sowie b) die Möglichkeit zu definieren ob die Automatik greift oder der manuelle PWM Wert zum Einsatz kommt... oder wäre hier PWM 0 = Automatik?
Theoretisch sollte es jetzt schon funktionieren, das Auslesen der gesetzten (Standard-)Werte und eigentlich auch das Speichern. Aber du weißt ja, ohne Hardware kann ich für nichts garantieren!
Theoretisch sollte es jetzt schon funktionieren, das Auslesen der gesetzten (Standard-)Werte und eigentlich auch das Speichern. Aber du weißt ja, ohne Hardware kann ich für nichts garantieren!
RS-ELEC
Enthusiast
Thread Starter
- Mitglied seit
- 29.06.2006
- Beiträge
- 3.435
Ich schau mal ob ich das neue GUI heute getestet bekomme.
Ich gerade ne neue Version der Befehlsliste V0.0.3 rüber geschoben. Hat sich allerdings nicht viel verändert. Ne Erklärung zur Anlaufzeit ist drinnen. Hatte ich bloß vergessen.
Ansonsten hab ich das AO und das M/A Bit in das Byte von Imp_Umd verschoben. In dem Status Byte hat sich das nicht gut gemacht. Da das sich ja ständig ändern kann. PWM = 0 (ich vermute du meinst Manuell (57)) heißt, dass im Manuell Modus der Lüfter aus ist.
Kurz eine ausführliche Erklärung dazu:
AO steht für Allow Off. Wenn dieses Bit (für den jeweiligen Kanal) gesetzt ist, dann darf der Automatische Modus den Lüfter auch ausschalten. Das heißt, wenn alle dem Kanal zugeordneten Temperaturen unter dem Minimum Wert liegen, geht der Lüfter aus und erst wenn ein wieder ein entsprechender Kühlbedarf vorhanden ist gehen die Lüfter wieder an.
Dann natürlich mit dem Anlaufimpuls, mit der Länge der Anlaufzeit. Ist AO für den entsprechenden Kanal nicht gesetzt, dann dreht der Lüfter im Automatik Modus immer mit mindestens F_min.
M/A ist die Umschaltung zwischen Automatik und Manuell. Wird dieses Bit 1 gesetzt, dann ist die Automatische Regelung aktiv und der Kanal regelt nach den zugeordneten Temperaturen. Ist dieses Bit 0, dann hat der Lüfter immer den Wert von Manuell (57). AO hat jetzt keine Bedeutung mehr. Lediglich die Anlaufautomatik gibt beim Einschalten einmal für die Anlaufzeit Vollgas.
Noch was zu den jeweiligen Min und Max Temperaturen. Wenn ein Sensor keinen Einfluss auf den Kanal haben soll, dann ist seine minimale Temperatur auf 250 (= 125°C) und seine maximale Temperatur auf 254 (= 127°C) zu stellen! Weil der Algorithmus wertet immer alle Temperaturen aus. Bei solchen Werten fällt der Sensor dann natürlich raus. Am besten du machst bei der Min/Max Temperatur Auswahl einen Dropdown Eintrag mit Off oder ein Häkchen davor. Dass bei Aktivierung die Werte entsprechend setzt.
Was sagt dein GUI eigentlich momentan, wenn AIDA nicht im Hintergrund läuft? Geht das?
Viel Erfolg und bei Fragen Fragen!
Mfg Bimbo385
Ich gerade ne neue Version der Befehlsliste V0.0.3 rüber geschoben. Hat sich allerdings nicht viel verändert. Ne Erklärung zur Anlaufzeit ist drinnen. Hatte ich bloß vergessen.
Ansonsten hab ich das AO und das M/A Bit in das Byte von Imp_Umd verschoben. In dem Status Byte hat sich das nicht gut gemacht. Da das sich ja ständig ändern kann. PWM = 0 (ich vermute du meinst Manuell (57)) heißt, dass im Manuell Modus der Lüfter aus ist.
Kurz eine ausführliche Erklärung dazu:
AO steht für Allow Off. Wenn dieses Bit (für den jeweiligen Kanal) gesetzt ist, dann darf der Automatische Modus den Lüfter auch ausschalten. Das heißt, wenn alle dem Kanal zugeordneten Temperaturen unter dem Minimum Wert liegen, geht der Lüfter aus und erst wenn ein wieder ein entsprechender Kühlbedarf vorhanden ist gehen die Lüfter wieder an.
Dann natürlich mit dem Anlaufimpuls, mit der Länge der Anlaufzeit. Ist AO für den entsprechenden Kanal nicht gesetzt, dann dreht der Lüfter im Automatik Modus immer mit mindestens F_min.
M/A ist die Umschaltung zwischen Automatik und Manuell. Wird dieses Bit 1 gesetzt, dann ist die Automatische Regelung aktiv und der Kanal regelt nach den zugeordneten Temperaturen. Ist dieses Bit 0, dann hat der Lüfter immer den Wert von Manuell (57). AO hat jetzt keine Bedeutung mehr. Lediglich die Anlaufautomatik gibt beim Einschalten einmal für die Anlaufzeit Vollgas.
Noch was zu den jeweiligen Min und Max Temperaturen. Wenn ein Sensor keinen Einfluss auf den Kanal haben soll, dann ist seine minimale Temperatur auf 250 (= 125°C) und seine maximale Temperatur auf 254 (= 127°C) zu stellen! Weil der Algorithmus wertet immer alle Temperaturen aus. Bei solchen Werten fällt der Sensor dann natürlich raus. Am besten du machst bei der Min/Max Temperatur Auswahl einen Dropdown Eintrag mit Off oder ein Häkchen davor. Dass bei Aktivierung die Werte entsprechend setzt.
Was sagt dein GUI eigentlich momentan, wenn AIDA nicht im Hintergrund läuft? Geht das?
Viel Erfolg und bei Fragen Fragen!
Mfg Bimbo385
Zuletzt bearbeitet: