Anlage von egos

Das Nachschlagewerk von Arduino.cc kann ich nur empfehlen. Alle Methoden und Funktionen sind detailliert aufgelistet. Zudem ist seit über fünf Jahren eine Arduino Fan-Gemeinschaft mit solchen Fragestellungen unterwegs. Google findet auf Anhieb die Gruppe, die gleiche Probleme gelöst hatte. An den Gewerbeschulen in Singen werden Arduino-Projekte als Vorbereitung der Fachschulreife durchgeführt. Wenn die jungen Leute von heute solche Aufgaben lösen, ist es höchste Zeit, als alter Klaus sich in das Gebiet einzuarbeiten.

Also:

Der Zugriff wird via Serial.Read() hergestellt. Das klappt eigentlich auf Anhieb. Etwas mehr Aufwand entsteht, weil das eingelesenen Byte als Integer aufgefangen wird und bei der Anzeige auf dem Flüssigkristall in Character gewandelt sein muss. Aber es geht. Ich kann jetzt im Java-Programm der Modellbahnsteuerung einen Button klicken und der Arduino reagiert, sogar richtig. Es gibt keine Kollisionen zwischen Serial.Write() und Serial.Read(). Das wird offensichtlich von der Arduino-Software des Serial-Ports gelöst.

Auf der Seite der Moba muss eine Routine die Communication mit dem Arduino herstellen. Dort ist der serielle Port definiert. Eine Send-Methode schickt die Daten über den Port zum Eingang des Arduino, der hier periodisch nachschauen muss, ob Arbeit (Daten) anstehen.

Die Probleme sind weitgehend gelöst, jetzt müsste das Ganze nur noch etwas Sinnvolles tun.

Ich arbeite daran...

Gruss Oski

Zitat von sturzi

es handelt sich hier um eine full-duplex-Kommunikation.

Hoi Röbi

Danke für die Erklärung. Vor allem das Beispiel aus der Praxis ist sehr eindrücklich und nicht minder verständlich !

Gruss Oski

Heute bin ich wieder etwas weitergekommen. Die Kommunikation von Java zu Arduino funktioniert einwandfrei. Mindestens kann ich die Messung im Arduino starten mit einem Klick im Java-Programm. Ja, ja, ihr liest das schon richtig, mehr macht es noch nicht. Beim Schliessen des Eichprogramms gibt es immer noch Fehler, weil der Arduino rasend schnell arbeitet und vom Schliessbefehl überrascht wird. Es waren 2 Fehler: beide entstehen in verschiedenen Klassen des Java-Programms in "Zusammenarbeit" mit dem Arduino und der neuen Schnittstellen Version JSerialComm von GitHub. Das Problem entsteht, wenn ich die Eichung für den Arduino überraschend verlassen möchte und gerade ein Schreib- oder Lese-Befehl aktiv ist. Nun, einen der beiden Fehler konnte ich ausräumen, am andern werde ich noch üben müssen. In der Richtung von Arduino zum Java Programm ist noch nichts getestet, da kämpfe ich mit der Übertragung von Byte[]. Vielleicht sollt ich meinen Mentor besuchen, aber der hat vielleicht anderes zu tun?

Gruss Oski

Hoi Röbi

Danke für dein Angebot. Ich komme gerne, du hast eine Mail.

Gruss Oski

Zitat von egos

Heute bin ich wieder etwas weitergekommen. Die Kommunikation von Java zu Arduino funktioniert einwandfrei. Mindestens kann ich die Messung im Arduino starten mit einem Klick im Java-Programm. Ja, ja, ihr liest das schon richtig, mehr macht es noch nicht.

Gestern war ich wie abgemacht bei sturzi , meinem Mentor. Wie es sich herausgestellte, war es sehr gut, dass die Kommunikation von Java zum Arduino nichts tut . Denn diese Kommunikationsrichtung braucht es gar nicht. Röbi hat mit seinem Fachwissen sofort ein Konzept vorgeschlagen, wie es umgesetzt werden kann. In der kurzen Zeit bis am Freitagnachmittag, waren alle wesentlichen Programmschritte geklärt. Nun muss das Ganze noch zusammengesetzt werden. Der Code des Arduino ist bereits implementiert und läuft fehlerfrei. Nun macht das Java-Programm noch nichts. Aber das kommt bald, Röbi arbeitet daran

In der Zwischenzeit erweitere ich den Code des Arduino von zwei auf vier Lichtschranken, damit die Eichfahrten optimiert werden können. Mal sehen, ob ich das alleine schaffe.

Gruss Oski

Danke Roger und Barni

Aber Röbi ist auch "Inschenjör", sogar von der richtigen Fachrichtung. Wenn er mich nicht animieren könnte, wäre ich längst versauert. Aber mit seiner Hilfe macht das noch lange Spass!

Gruss Oski

Wir sind offensichtlich beim Fernrohrproblem angekommen, und das geht so:

Wenn du einen Löwen fangen willst und ihn deshalb durch das Fernrohr betrachtest, wird das gefährliche Tier saumässig gross, der Schreck geht in die Hosen. Willst du ihn trotzdem einfangen, kannst du nun aber das Fernrohr umdrehen. So wird aus der Raubkatze ein niedliches Kätzchen, das man sogar ohne Handschuhe packen kann.

So wird je nach Blickrichtung ein Problem gross oder eben auch klein. Diese "Richtigstellung" von Röbi war wirklich nicht nötig, wenn man nicht auch sagt, in welche Richtung man blickt. Sehr froh bin ich aber, dass wir beide das Mittagessen geniessen konnten und dies ohne Korrekturen.

Ich nehme von meinen Schwärmereien jedenfalls nichts zurück und freue mich auf den nächsten Besuch bei Röbi.

Herzliche Grüsse

Oski

Der von Röbi gelieferte Arduino Sketch ist auf 4 Beams erweitert und wird fehlerfrei kompiliert. Ob es dann auch fehlerfrei läuft, ist noch nicht erwiesen.

Zitat von sturzi

Jetzt ist auch der Java-Teil fertig und an Oski ausgeliefert

Gestern erhielt ich von Röbi den Teil im Java-Programm, der die Daten aus dem Arduino Speed-O-Meter auffangen soll.

Nach etwa drei Stunden Arbeit waren seine Angaben in meinem Programm eingebaut und alle Fehler sind verschwunden. Das geänderte Programm funktionierte auf Anhieb .

Nun kann ich die Erweiterung auf vier Lichtschranken testen und verbessern (ja, ist wichtig und nötig).

Nachher müssen die Resultate in eine Textdatei abgespeichert werden, pro Lok entsteht eine Datei.

Röbi, ich bedanke mich nochmals herzlich für diese super Unterstützung! Das hätte ich alleine nie hingekriegt.

Gruss Oski

Die Erweiterung auf 4 Lichtschranken ist eingebaut. Das Messprogramm des Speed-O-Meters läuft immer noch. Meine Zusatzzeilen laufen auch fehlerfrei, machen aber noch nicht das, was sie sollten. Immerhin wird die Messstrecke von 4 Beams korrekt auf 3 Beams verkürzt, wenn die Messdauer 11 Sekunden überschreitet. Auf 2 Beams verkürzen geht aber noch nicht, es bleibt bei 3 Beams und ändert nicht mehr. Das finde ich schon noch. Es sind etwas viele Tests und ich verheddere mich immer wieder in der Logik der Abläufe. Da das Ganze nicht auf der Anlage montiert ist...

... muss ich die Lok-Fahrt simulieren. Dabei ist das LCD-Shield mit der laufenden Zeitanzeige immens nützlich.

Mittlerweile kann ich auch den Serial-Monitor einsetzen und Zwischenresultate mit dem Befehl Serial.print() direkt auf dem Bildschirm anzeigen. Das geht aber nur, wenn die Digital-Pins 0 und 1 frei geblieben sind (wie das Röbi eindrücklich verlangte). Mit dem Serial-Monitor kann man an beliebigen Stellen im Programm Daten anzeigen. So sieht man auch, an welcher Stelle in den If-Tests oder in den Switch-Abschnitten die Berechnung gerade durchläuft. Damit die Sache "von Auge" kontrollierbar bleibt, setze ich noch delay(500) Befehle hinzu, damit das Programm eine halbe Sekunde warten muss. So kann man sehr einfach verfolgen von wo welche Daten kommen. Alle diese print() und delay() Geschichten müssen natürlich wieder weg, sonst ist die Messung massiv verfälscht. Ich hoffe, bis morgen Abend läuft die Sache vollständig.

Am meisten beschäftigt hatte mich die Tatsache, dass die leuchtende grüne LED an der Lichtschranke weder "true" noch "HIGH" noch "Ein" bedeutet, sondern genau das Gegenteil. Am Shield liegt die Spannung "0 Volt" am Pin, wenn die Schranke aktiv ist. So war der Aufbau der Logik an einigen Stellen genau falsch. Aber das ist jetzt gelöst.

Gruss Oski

Hoi Röbi

Zitat von sturzi

Wenn du dabei an ein Relais denkst,

Ich denke natürlich nicht an ein Relais. Aus meiner beruflicher Umgebung sind meine Gedanken klar: Wenn etwas "da" ist, dann ist es "nicht Null". Aber vielleicht habe ich in der Mengenlehre zu wenig gut aufgepasst.

Zitat von sturzi

Ansonsten weisst du ja, wie du mich erreichst.

Ja, für deine Unterstützung bin ich sehr dankbar. Du bist also noch nicht sicher, dass ich nicht um Hilfe rufen muss. Aber zuerst versuche ich es selber.

Gruss Oski