INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Brennersteuerung
15.12.2013, 12:17
Beitrag #33
RE: Brennersteuerung
Moin Joe,

1. Zum LCD nimm bitte die Lib im Anhang. Schmeiß alle anderen LCD-Libs nach ausserhalb des IDE-Verzeichnisses
2. Libs gehören immer in das Unterverzeichnis "libraries" und dort jeweils in ein eigenes Verzeichnis.
3. die Übersetzung geht nur auf WIndows IDE >= 1.5.2. Die Linux IDE macht das noch nicht.
4. "Wire.h" stellt die Kommunikation über I2C bereit, "LiquidCrystal_I2C.h" stellt eine Erweiterung der "LiquidCrystal.h" für I2C dar.
5. Die Pin-Angaben bei der Initialisierung des LCD mappen nur die Pins des eigentlichen LCD (große Platine auf dem das LCD drauf ist) auf die Eingänge des I2C Controllers (kleine Platine dahinter).
6. Du brrauchst nur 4 Leitungen vom LCD zum Arduino (5Volt, GND, SDA,SCL).
Zitat:Ist die lcd Ausgabe eine Einbahnstraße?
Aus meiner Sicht schon, wenn man ein Touch-Screen genommen hätte, weil
- mit Touch-Screen wäre die gesamte Menülogik einfacher zu realisieren (und längst fertig) und es wäre einfach netter anzusehen
- du würdest sämtliche Taster einsparen und hättest die Pins für andere Sachen frei
- Taster sind mechanische Teile, daher würde in Folge mit Sicherheit noch die Bounce-Lib mit eingearbeitet werden müssen um das Prellen der Taster abzufangen.
- in deinem aktuellen Code schaltest du die Relais über die Pins 20/21. Die sind aber schon vom I2C für das Display belegt!!!
- auf dem Touch-Screen ist noch ein SD-Kartenmodul drauf. Dort könnte etlches an Daten/Einstellungen gespeichert werden und man müsste dann nicht mit dem EEPROM zum halten der Daten/Einstellungen rummachen.
Überlege dir ob du nicht lieber auf den Touch-Screen umsteigen willst/solltest. ich könnte dir so ein Teil (zwar gebraucht, aber läuft) für 15 € vermachen.

Ansonsten weiß ich jetzt nicht wie man am besten weitermacht. Irgendwie arbeiten ja jetzt zwei Köpfe an einem Quellcode. Am besten ist, du schickst mir deinen bisherigen Code mit meinen Änderungen mal per eMail zu. Macht aber nur Sinn wenn du dich endgültig entscheidest ob du LCD + Taster oder Touch-Screen benutzen möchtest.

Grüße Ricardo


Angehängte Datei(en)
.zip  LiquidCrystal.zip (Größe: 80,63 KB / Downloads: 53)

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
15.12.2013, 20:54 (Dieser Beitrag wurde zuletzt bearbeitet: 15.12.2013 21:34 von JoeDorm.)
Beitrag #34
RE: Brennersteuerung
Hallo Ricardo,

vielen Dank für Deine Hilfe.
Das Zusammenführen von Quellcode würde ich gerne selbst machen.

Was mir am Besten helfen würde wäre Beispielquellcode, an meine Bedürfnisse möglichst nahe angepaßt.
Ich kann sowas gut verbauen und auch weiter anpassen falls nötig.

Im Moment möchte ich die Erfahrung mit dem Display mit den Tasten machen.
Ein TFT Touchsreen habe ich in der Pipeline, glaube aber, das der nicht vor Januar kommt.

Im Moment verfüge ich nur über ein 2x16 Display, das was bei dem Set dabei war, und 4 Tasten nebst Steckbrett.
Es liegt nahe, dann doch erstmal diese Variante zu benutzen.
Ein Menü auf 1 Ebene wäre mir da erstmal logisch.

Menüausgabe von oben nach unten, spielt sich komplett und immer in der 1. Zeile ab, und die Voreinstellungswerte dazu sollen editierbar sein in der Zeile 2. Die Zeile 2 ist im normalen Betrieb ansonsten immer eine Ausgabe verschiedener Werte als Status. Darf aber zum Editieren benutzt werden ::

Char* menuArray(
"RUN 0/1",
"kw",
"LambdaSoll",
"PellBrennwert",
"PellMesszeitMin",
"PellFüllzeitSek" );
Diese Werte soll man editieren können, und die Werte

Ich ging bisher davon aus, das mehrere Programme gleichzeitig ausgeführt werden könnten(Multitasking/Multiprozessing).
Fortlaufender Prozess RUN, der den normalen Bertieb darstellt läuft, wenn die zugehörige Variable auf 1, anstatt 0 steht.
Während dieser Prozess läuft, sollte man die obigen Werte editieren können, deren Änderungen direkt den RUN-Prozess beeinflussen.
Beispiel: Die RUN-Variable steht auf 1 und das Betriebsprogramm läuft ununterbrochen nach den Werten der EInstellungen. Alsdann möchte ich eine Änderung der Leistung machen. Zur Zeit sehe ich noch in der 1. Zeile RUN, und in der 2. Zeile ein paar Statuswerte, die bei jedem Loopdurchlauf des RUN aktualisiert werden. Die Änderungsmöglichkeit wird mit dem Drücken der linken Taste aktiviert. D.h. Die 1. Zeile zeigt jetzt den 1. EIntrag in dem Menü an, und in der 2. Zeile läuft weiterhin der Status.
Möchte ich, in diesem Fall den normalen RUN-Betrieb unterbrechen,(Anzeige steht ja auf "RUN 0/1", so drücke ich die rechte Taste und komme damit in den Editiermodus, der jetzt temporär die Zeile 2 benutzt. Dort wird der letzte Wert, in diesem Fall 1 angezeigt, und ist mit den Tasten UP DOWN verstellbar. Da der Wert keine Nachkommastellen hat, ist der Verstellwert 1. Bei mehr Nachkommastellen, z.B. 1, so wird bei UP 0.1 increminiert, bei DOWN decriminiert. Übernahme des Wertes mit RECHTS(Enter). Der Wert wird in die dazugehörige globale Variable des RUN-Prozess geschrieben. Dann wirkt die Verstellung eines Wertes. Bei kw muß man ein mal DOWN drücken, damit der Cursor auf kw steht, und dann die Teste RECHTS(Enter) gedrückt werden. Verstellung UP/DOWN. Abgeschlossen wird mit der rechten Taste. Der Wert wird der globalen Variable für den RUN-Prozess übergeben, und dann wird der Wert im EPROM abgelegt, damit er nach einem Reset oder Neustart zur Verfügung steht.
Das Ganze ist erstmal sehr minimalistisch, würde aber schon mit dieser Methode der Menüführung und Verarbeitung, die komplette Applikation schon ermöglichen.

Wenn man ein Display mit 4x20 hat, dann sollte sich die Menüführung so anpassen, das die ersten 3 Zeilen fürs Menü benutzt werden und die 4.Zeile wie bisher den Status bringt, oder die Editierzeile spielt.

So kann man wirklich damit schon was anfangen.
Mein neueres Verständnis erkennt aber, das es mit der parallelen Verarbeitung von RUN und Editieren, ein Problem geben könnte, da ich noch keine Beispiele sah, die dies unterstützen. Selbst die newDelay() ist nur ein Ersatz für delay(), wo die Rechner wärend der Wartezeit aber keinen anderen Prozess unterstützt.
Könntest Du mir zur Ablaufsteuerung diesbzgl, etwas erklären?

An Deinem Touchscreen bin ich interessiert.
Diese Lösung ist aber die Luxusvariante, die ich eigentlich erst zuletzt machen möchte.
Beachte bitte, das die Standard-LCD-Geschichte für mich auch ein Lernfaktor ist, auf den ich nur ungern verzichten würde. Denke, das der Menüteil da auch sehr interessant sein wird.

Gruß Joe
Nachträgliche Überlegung.
Ein mehrdimensionales Array wäre möglicherweise für den Ablauf besser.
5 Werte für einen Menüeintrag wären
(Menüeintrag,minWert,maxWert,Nachkommastellen,Pointer der globalen Variablen)

menuArray(
("RUN 0/1",0,1,0,&golbalRun),
("kw",2..0,23.0,1,&golbalKw),
("LambdaSoll",1.00,2.500,2,&golbalLambdaSoll),
("PellBrennwert",3.0,6.0,1,&golbalPellBrennwert),
("PellMesszeitMin",1,15,2,&golbalPellMesszeitMin),
("PellFüllzeitSek,0.5,5.5,1,&golbalPellFüllzeitSek) );

Unser Projekt Rolleyes http://global-science-circle.net http://global-science-circle.org http://global-science-circle.info UND http://radio-gsc1.info
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
15.12.2013, 23:48
Beitrag #35
RE: Brennersteuerung
Hallo Joe,

und wieder ein paar Worte von mir. Ist ja für uns alle ein Lernprozeß.
Zitat:Was mir am Besten helfen würde wäre Beispielquellcode, an meine Bedürfnisse möglichst nahe angepaßt.Ich kann sowas gut verbauen und auch weiter anpassen falls nötig.
So einen Beispielcode wird es ziemlich sicher für den Gesamtkomplex nicht geben.
Was man alternativ machen kann (und was auch üblich ist in der Programmierung) ist die Zerlegung des Gesamtkomplex in immer wiederkehrende kleine Teileinheiten. Ein gutes Beispiel ist hier meine Korrektur mit der setPegel- Funktion.
Diese Teileinheiten müsstest du dann benennen. Nach dem Motto "ich brauche einen Code der auf Pin 20 bei drücken eines Tasters an Pin 17 ein relais schaltet" ,oder so ähnlich eben.

Gut dass du jetzt mit ein paar Erläuterungen dein gewünschtes Menü deklariert hast. Jetzt kann man auch was zusammenbringen. Übrigens gibt es hier eine recht gute Menüklasse mit der man sowas erstellen kann: http://playground.arduino.cc/Code/Menu .

Zitat:Mein neueres Verständnis erkennt aber, das es mit der parallelen Verarbeitung von RUN und Editieren, ein Problem geben könnte, ...
Es gibt, egal in welcher Rechner-Architektur, sowieso keine parallele Abarbeitung von Befehlen im Sinne des Wortes "parallel" Es ist immer ein (wenn auch extrem schnelles) serielles Arbeiten.
Zitat:Selbst die newDelay() ist nur ein Ersatz für delay(), wo die Rechner wärend der Wartezeit aber keinen anderen Prozess unterstützt.
Das ist so nicht richtig. Delay() hält den Chip (ausser dem internen Timer) definitiv an. Hat der Timer den per Paramter übergebenen Wert hochgezählt wird der Prozessor wieder freigegeben.
Die newDelay() gibt über while die Möglichkeit mit Interrupts oder Schedulern andere Prozesse anzustoßen. Das liegt daran, dass die while -Bedingung ja immer wieder geprüft werden muss und dazu der Prozessor ja laufen muss.
Und genau hier liegen dann auch die Möglichkeiten um die im Editiermodus gesetzten Werte dann zu speicherm, aktiv zu setzen und den RUN-Modus mit den neuen Werten neu zu starten.
Zitat:An Deinem Touchscreen bin ich interessiert.
Diese Lösung ist aber die Luxusvariante, die ich eigentlich erst zuletzt machen möchte. Beachte bitte, das die Standard-LCD-Geschichte für mich auch ein Lernfaktor ist, auf den ich nur ungern verzichten würde. Denke, das der Menüteil da auch sehr interessant sein wird.
Der Punkt ist, dass das Menü auf dem Touch wesentlich unkomplizierter zu schreiben ist. Warum? Ganz einfach, die komplette Steuerung/Auswertung der Taster fällt einfach weg, ebenso wie das ganze Überschreiben vorheriger dargestellter Zeichen. Dies ist so weil beim Touch immer in Screens" gedacht wird. Siehe mein Beispiel hier: http://www.arduinoforum.de/arduino-Threa...uch-Screen
Für das LCD dürfte das locker doppelt so lang werden. Weiterhin muss man immer kontrollieren/wissen in welchem Menü man sich befindet und dies auch abfrage!? Das LCd wäre in 2 Tagen bei dir, wenn du magst.
Ist es nicht besser/schöner wenn man erstmal Ergebnisse hat und sich dann in Ruhe an die komplexeren Varianten macht?

Grüße Ricardo

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
16.12.2013, 02:32
Beitrag #36
RE: Brennersteuerung
Ok, Ricardo,
machen wir so.
Hast Du einen PayPal Account, zwecks Moneytransfer?
Gruß Joe

Unser Projekt Rolleyes http://global-science-circle.net http://global-science-circle.org http://global-science-circle.info UND http://radio-gsc1.info
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
16.12.2013, 13:18
Beitrag #37
RE: Brennersteuerung
Hallo Joe,

ganz cool bleiben. Ich schick dir den Touch-Screen erstmal zu. Geld machen wir dann nach der Jahreswende. Sollst dich ja auch erstmal überzeugen, dass das Teil läuft.
Noch eine Frage: Soll ich jetzt das Menü für dich auf Touch-Screen programmieren?

Grüße Ricardo

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
16.12.2013, 17:21
Beitrag #38
RE: Brennersteuerung
(16.12.2013 13:18)rkuehle schrieb:  Hallo Joe,

ganz cool bleiben. Ich schick dir den Touch-Screen erstmal zu. Geld machen wir dann nach der Jahreswende. Sollst dich ja auch erstmal überzeugen, dass das Teil läuft.
Noch eine Frage: Soll ich jetzt das Menü für dich auf Touch-Screen programmieren?

Grüße Ricardo

Vielen Dank erstmal.
ich nehm das Teil.
Ich brauche nur ein Beispiel zu dem Menü und Touchscreen.
Sollte ich alleine hinbekommen, oder?
Wenn nicht, frage ich gerne nach.

Frage: Unter Visual Basic kann ich mehrere Timer programmieren, wo ich Methoden dranhängen kann, die tatsächlich gleichzeitig abgearbeitet werden, wenn die Timerevents gleichzeitig den Programmcode abarbeiten.

Beim Tracen sieht es zwar nach einer seriellen Verarbeitung aus, aber in Realtime wenn 2 Timer zur gleichen Zeit den zugehörigen Code starten, und dieser gleich wäre, würden auch beide nahezu gleichzeitig fertig. So zumindest meine Erfahrungen.

Gibt das die Timerei unf Programmiersprache beim Arduino auch her?
Wenn ja, würde ich mein Programm etwas anders steuern, und Timer benutzen.

Gruß Joe

Unser Projekt Rolleyes http://global-science-circle.net http://global-science-circle.org http://global-science-circle.info UND http://radio-gsc1.info
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
16.12.2013, 17:53
Beitrag #39
RE: Brennersteuerung
Hallo Joe,

Zitat:Ich brauche nur ein Beispiel zu dem Menü und Touchscreen.
guckst du zB. hier: http://www.arduinoforum.de/arduino-Threa...ight=touch mein Code v. 21.11.2013 / 19:04 Uhr. Da sieht man wie menüs über 3 Ebenen aufgebaut werden und auch Aktionsbuttons im Menübereich "Medien" . Anstatt der dort hinterlegten delay-Aurufe kommen dann halt deine Funktionsaufrufe.
Zitat:Unter Visual Basic kann ich mehrere Timer programmieren, wo ich Methoden dranhängen kann, die tatsächlich gleichzeitig abgearbeitet werden
Das ist dann kein Multitasking, sondern "Multithreading". Wie (fast) immer liegt die Antwort schon in der Frage! "wo ich Methoden dranhängen kann, die tatsächlich gleichzeitig abgearbeitet werden" - Methoden sind (wie Eigenschaften und Vererbungsregeln) teile von Klassen/Objekttypen in der objektorientierten Programmierung. Leider kann der Sprachvorrat des Arduino das nicht liefern, da es eine rein prozedurale Sprache ist.
Zitat:Gibt das die Timerei unf Programmiersprache beim Arduino auch her?
Wenn ja, würde ich mein Programm etwas anders steuern, und Timer benutzen.
Aus oben genannten Gründen leider nicht. Aber die Timer bzw. Interrupts sind schon eine Möglichkeit zeitgesteuert (Timer) oder ereignisgesteuert (Interrupt) zu programmieren. Allerdings beachten: Interruptroutinen unterbrechen alle anderen Abläufe und dürfen selbst keine Variablen erwarten oder liefern! Weiterhin sind Interrupt nur als HW-Interrupts zu verstehen. Ein verständlicher text steht zB. hier:
http://fluuux.de/2013/04/interrupts-mit-...-benutzen/
Hier gibts eine gute Beschreibung wie man timer nutzen kann:
http://playground.arduino.cc/Code/time

Hope it helps!

Grüße Ricardo

Nüchtern betrachtet...ist besoffen besser Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
18.12.2013, 04:28
Beitrag #40
RE: Brennersteuerung
Danke Ricardo.

Hilfe super, Erklärung super.

Gruß Joe

Unser Projekt Rolleyes http://global-science-circle.net http://global-science-circle.org http://global-science-circle.info UND http://radio-gsc1.info
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste