Warum Arduino? Eine Vielzahl von Weichen-, Signal- und Fahrstromschalter wird überflüssig und der Ardiuno kann neu eingesteltle Fahrstraßen ablehnen, die in Konflikt mit bisher eingestellten Fahrstraßen stehen. So dient er einerseits der Übersicht auf dem Schaltpult und der Bequemlichkeit und andererseits der Sicherheit. Eine solche Steuerung entspricht zwar nicht den Usancen der Bundesbahn, aber die Hampstedter Verbindungsbahn ist schließlich eine private Gesellschaft unter der Regie der Stadt Hampstedt.

Es werden zwei Arduinos installiert - jeweils für den Bahnhof am Ende der Strecke
a) HAMPSTEDT-ALTSTADT (mit dem Arduino Mega) mit 16 Fahrstraßen, 10 Signal- und Fahrstromrelais und 12 Stellrelais für 6 Weichen, eine EKW und ein Formsignal
b) HAMPSTEDT-FISCHHAFEN (mit dem Arduino Uno) mit 4 Fahrstraßen, 4 Signal- und Fahrstromrelais und 5 Stellrelais für 4 Weichen

Für die Einstellung dieser Fahrstraßen genügen in Altstadt 8 und in Fischhafen 2 einfache 1 - 0 - 1 Schalter für den Input der Arduinos.

Die Programme für beide Arduinos haben die gleiche Struktur. In der Hauptschleife wird geprüft, ob sich der Status einer Fahrstaße geändert hat. Wenn nein, macht der Arduino eine kleine Pause und beginnt von vorn. Ist eine Fahrstraße ausgestellt worden, wird das Signal wieder auf Hp0 zurück gesetzt. Ist eine neue Fahrstraße eingestellt worden, so prüft das System, ob eine früher eingestellte Fahrstraße besteht, mit der es zu Konflikten kommen kann (Zusammenstoß oder Flankenfahrt). Ist dem so, wird die neue Fahrstraße nicht zugelassen, sondern ein warnender Piepston nervt.

Mehrer Fahrstraßen können nur dann eingestellt werden, wenn sich die Bewegungen nicht berühren. In "Fischhafen" ist das nur bei einer Konstellation der Fall, aber in Altstadt tangieren die 8 Rangierstraßen von Gleis 1 oder 2 zu Gleis 6 oder 7 und zurück keine Streckenfahrten aus Gleis 3 oder 8. Daher werden für die Zulässigkeitsprüfungen im Altstadt-Programm Fahrstraßensammelklassen gebildet, um das Prüfverfahren zu vereinfachen. Dem Arduino wäre es vermutlich egal, alle einander ausschließenden Fahrstraßen im Einzelfall abzuarbeiten, aber es würde den Programmcode nur unnötig aufblähen. Was nicht da ist, kann keeine Fehler verursachen.

Ist die Fahrstraße zulässig, wird das Signal auf Hp1, Hp2 und Sh1 gestellt, der Fahrstrom geschaltet und die Weichen werden gestellt. Beim Hampstedt-Programm wird außerdem auf einem 16 * 2 - Display die eingestellt Fahr- oder Rangierstraße angezeigt, obwohl man das auch an der Schalterstellugn sehen könnte. Aber etwas Luxus muss sein.


Inzwischen sind auch die Gehäuse für die Arduinos gekommen - zweimal das Gehäuse für den Arduino Mega. Der kleinere Arduino Uno (blaues Schild) passt wunderbar und passgenau hinein. Der Arduino Mega (weisses Schild) - für den das Gehäuse eigentlich gedacht war - würde auch hineinpassen, wenn er nicht mit einer Unterplatte geliefert worden wäre, die ich mich nicht zu entfernen traue. So musste man eben ein wenig tricksen. Gut, dass noch längere 2mm Schrauben vorhanden waren. Ansonsten sehr schöne Gehäuse. Man ist da doch etwas unbefangener beim anfassen der kleinen Zwerge.

Offenbar ist die Programmiersprache für die Arduinos eine Art C-Dialekt. So wirft man nebenbei auch in dieses Medium einen Blick. Anbei als erster Schritt das Listing für den Bereich "Fischhafen". Die Label der Fahrstraßen changeKF, changeKP, changeL und changeM münden alle vie in eine der drei Alternativen
* setback = alte Fahrstraße wird zurück gestellt
* beepy = neue Fahrstraße nicht zulässig
* worker = neue Fahrstraße wird eingerichtet.

Das Listing "Hampstedt-Altstadt" wird nach ähnlichem Schema aufgebaut sein - nur etwas umfangreicher.
http://www.horstbu.de/forum/Fischhafen.rtf

Hallo Horst,
ein interessantes Projekt. Mit dem Arduino kann man eben auch bei Analogbahnen eine Menge machen .

Zitat

---

Offenbar ist die Programmiersprache für die Arduinos eine Art C-Dialekt.

---

Es ist kein C-Dialekt, es ist ganz normales C, oder besser gesagt C++. Allerdings stellt die Arduino IDE schon 'unsichtbar' eine Programmbasis zur Verfügung, weshalb man nicht mit dem ganzen C Programm in Berührung kommt, und es gibt viele vordefinierte Funktionen die das Programmieren erleichtern.

Hast Du eigentlich früher in Basic programmiert? Sieht irgendwie so aus .

Allerdings scheint mir dein verlinktes Programm noch nicht so ganz lauffäig ... :
Oder liegt das am rtf-Format?

Moin Franz-Peter,
früher - lange ist es her - habe ich in Basic programmiert und in Z80-Assembler für den JOYCE (damals noch mit CPM-Betriebssystem und 8-bit) und unter DOS mit 80386-Assembler. Wie merkt man das? Zu lineare Strukturen? Damals so um 1985 wurde sogar Basic für kommerzielle Programme verwendet und ein simpler Büro-PC kostete stolze 15.000 DM.

Man kann bei dem Arduino-Programm sicher auch noch smoothen - die Loop-Abfrage für den Mega mit 16-mal Abfrage nach Statusänderung einer Fahrstraße ist jetzt ersteinbmal mit "brutal force" - da könnte ich mir eine elegantere "do - while" Schleife vorstellen mit 2 Zeiger in arrays. Im verlinkten Programm fand ich noch zwei kleine Tippfehler. Als *.ino-File gespeichert hat er es aber schon mal. Die Test dieser zweiten Version kommen am Wochenende, die erste lief mit LED asl Output einwandfrei. Erst einmal das Programm für den Mega fertig schreiben - fast schon eine Fleißaufgabe mit seinen 16 Fahrstraßen.

Ich hoffe, du bleíbst dran an diesem thread.

Hallo Horst,

da bleiben sicher noch mehr "dran" . Ich hatte so was auch schon mal angefangen: http://moba.noethlich.info/?page_id=333
Mein Schwerpunkt lag damals in der Flügelbewegung der Signale und dem Zusammenspiel von Haupt- und Sperrsignal ... und so ganz fertig geworden ist es bis heute nicht. Und wenn ich irgendwann mal weitermache, dann vielleicht doch eher mit optionaler Auswertung des Digital-Signals. Ich bin gespannt, wie Du die "Hardware" zusammenstellst - denn mit dem Programm für den Arduino allein ist es ja nicht getan.

Viele Grüße, Bodo

Hallo Bodo,
schön, dass sich für das Thema noch jemand mehr interessiert. Hier erst einmal das Listing für den "Hauptbahnhof" Hampstedt-Altstadt mit 6 überwachten Gleisen, 7 Signalen und 7 Weichen. Die Langversion ist http://www.horstbu.de/forum/Altstadtlong.rtf .

Die Kurzversion mit den Fahrstraßenvariablen als Array und der kurzen Loop-Funktion als for-Schleife hier http://www.horstbu.de/forum/Altstadtshort.rtf gefällt mir im Prinzip deutlich besser. Die "Sprungtabelle" ist noch das Hindernis. In Assembler wäre das ja sowas von simpel... und muss ja wohl auch irgendwie in C gehen. Ich denke da an eine "case"-Konstruktion. Die Variablen in den Fahrstraßen-Funktionen müssen dann natürlich im Array angesprochen werden und nicht direkt wie in der Langversion.

Mit dem Programm ist es in der Tat nicht getan. Die Input-Peripherie sind einfache 1-0-1 Schalter. So schließen sich zwei konkurrierende Fahrstraßen schon einmal gegenseitig einfach mechanisch aus und brauchen nicht auf Verträglichkeit geprüft werden. Es werden durch den Schalter einfach 5 Volt an den betreffenden Pin geleitet, wenn die Fahrstraße eingestellt werden soll oder eingestellt bleiben soll und die Loop-Funktion fragt den digitalen Pin-status ab (Null oder 1).

Auch die Output-Peripherie ist releativ konventionell. Der Output als High-Level geht über einen Transistor zu einem Relais. Ein Teil der Relais, der die Signallichter und den Fahrtstrom regelt, bleibt an, solange die Fahrstraße besteht und der Pin auf HIGH-Level ist. Das können höchstens 2 Pins für 2 Fahrstraßen sein; in der Regel ist es nur einer oder keiner, wenn keine Fahrstraße besteht. Die Relais für die Weichenstellung werden immer nur mit einem Impuls betätigt. Nach den Relais geht es weiter auf altbekannte analoge Art mit den Signal-LED und den magnetischen Weichenantrieben (Rocoline 10° oder dem Vissmann-Flügelsignal. Auch die Fahrstrom-Zuordnung im Bahnhofsbereich erfolgt über die Signal-Relais.

Die Bedienung der Zwischenstrecke zwischen Hampstedt-Altstadt (Arduino Mega überwacht) und Fischhafen (Arduino Uno überwacht) mit den Haltestellen Kölperort, Margaretenhöhe und Vrumpke erfolgt ganz konventionell mit ein paar Fahrstrom-Abschaltungen und Relais für die Lichtsignale F, G, H und J. Sicher könnte der Arduino auch diese Haltestellen überwachen, aber das würde ca. 11 m oder längere ange Datenleitungen bedingen. Diese Gegebenheiten kann man später immer noch austesten. Ich wäre ja froh, wenn wenigstens diese erste Stufe einwandfrei funktioniert.

Was noch nicht implementiert ist, ist die Anzeige auf dem LiquidCrystal Display mit 2 * 16 Zeichen. Das ist aber eigentlich nur ein gimmik, denn die Zugüberwachung funktioniert auch ohne es.

Hallo Horst,

Zitat

---

Ich hoffe, du bleíbst dran an diesem thread.

---

Du bleibst unter Beobachtung ....

Zitat

---

früher - lange ist es her - habe ich in Basic programmiert und in Z80-Assembler für den JOYCE (damals noch mit CPM-Betriebssystem und 8-bit) und unter DOS mit 80386-Assembler. Wie merkt man das?

---

Du arbeitest nur mit globalen Variablen und verwendest bei Unterprogrammen keine Parameterübergabe und keine lokalen Variablen. Das ist typisch für die alten Basic-Interpreter, die konnten das nicht anders. In 'C' ( und auch in anderen Sprachen) ist es absolut untypisch und eher verpönt so zu programmieren.
Bei 'ausgewachsenen' Programmiersprachen war das schon immer so, das man an Unterprogrammen Parameter übergeben konnte. Und auch Basic hat das inzwischen schon lange gelernt. Durch die Parameterübergabe an Funktionen kann man die wesentlich flexibler gestalten. Deine changefahr() Funktion braucht man dann z.B. nur 1x, egal wieviele Fahrstraßen Du hast. Bei den von der IDE bereitgestellten Funktionen machst Du das ja auch schon so, denn die nutzen das alle.

Dein Ansatz mit den Arrays geht schon in die richtige Richtung, nur solltest Du den konsequent umsetzen. D.h. alle fahrstraßenspezifischen Werte - z.B.auch die Eingangs und Ausgangspins - als Array definieren. Dann kannst Du auch alles in for-Schleifen erledigen.

int sprungtabelle (x)     // hier soll verteilt werden auf changefahrxx
 
 

Das ist ziemlich typische Assembler-Programmierung - in C mit Funktionspointern zwar auch möglich, aber nur selten notwendig.
Wenn Du deinen Array-Ansatz konsequent verfolgst, brauchst Du das nicht.

  goto loop ()
 
 

Das solltest Du auf keinen Fall tun, das führt zu üblen Laufzeitfehlern, insbesondere wenn man aus Unterprogrammen herausspringt. Da wird bei jeder Ausführung RAM verbraucht, der nie mehr freigegeben wird. Bis irgendwann das RAM voll ist, und das Programm abstürzt. Wird bei deinem Programm zwar rel. lang dauern, und es kann sein, dass Du es nie merkst, wenn Du immer früh genug aus- und einschaltest. Aber es ist eine ganz üble Fehlerquelle. Ist aber eigentlich in Assembler auch so, dass man nicht aus Unterprogrammen herausspringt, weil dann die Rücksprungadresse auf dem Stack bleibt - das ist in C nicht anders.
'goto' braucht man in C eigentlich nie. Es ist eher ein Anachronismus, dass das überhaupt noch geht.

Deine Speicherung der Programme als rtf ist übrigends sehr ungünstig, denn dadurch werden da Formatierungsinformationen eingefügt, die das Programm unübersetztbar machen. Die muss man immer erst wieder entfernen.

Ja - das mit den Arrays ist oiffenbar der bessere Weg. Die Idee ist ein zweidimensionales Array mit 16 * 7 Speicherstellen - in der "waagherechten" die 16 Fahrstrassen und in der "senkrechten" die Bytes für StatusSoll, StatusIst, signalpin, weichenpin1, 2 und 3 und Sicherheitsklasse. Dann können die 16 gleichartigen Routinen für Fahrstraßenänderung in eine zusammengefasst werden, weil durch eine Indexvariable festgelegt ist, welche Fahrstraße betroffen ist. Wenn dann das Display angeschlossen ist, können die zu zeigenden Texte ebenso in einem Array abgelegt werden.

Assembler-Programmierung hat natürlich manchmal etwas wie mit der Arbeit mit der Brechstange und bei Basic ist man immer versucht, dem Flussdiagramm zu folgen. Assembler-Programmierung ist offensichtlich auch bei den Arduino-Prozessoren möglich - sogar mit einer Menge Register. Aber sich da noch hinein zu friemeln? Wenn denn die Programm-Beispiele als *.rtf - file nicht gut verwendbar sind, dann setzte ich sie doch besser als *.ino - file.

Hallo Horst,

Ich halte es nicht für optimal die Variablen, d.h. die eigentlichen Fahrstraßen, im Code fest zu verdrahten. Ich würde einen SD-Karten - Leser anschließen und auf dieser in einer CSV-Tabelle die eigentlichen Fahrstraßen und ihre Schaltvorgänge hinterlegen. Der Arduino sucht dann bei Aufruf die passende Straße in der Datei und arbeitet die Daten dann ab. Eine Änderung oder Erweiterung beschränkt sich dann darauf die Tabelle am PC zu editieren. Wenn sich die Anzahl der Straßen in Grenzen hält, dann kannst Du auch den Dateiinhalt beim Start in komplett in ein Array kopieren. Das läuft dann geringfügig schneller, als die Daten sequentiell zu lesen.

mfg

D.

Ein zweidimensionales Array (16 * 7 Felder) scheint für die Datenstruktur der zu berücksichtigenden Gleislage ausreichend zu sein. Aufbohren könnte man an dieser Stelle dann immer noch. Mit 16 Fahrstraßen, 7 Weichen, 7 Signalen und einigen Fahrstromabschnitten ist die Sache ja relativ überschaubar. Mit diesem Array wird das Programm auch deutlich kürzer sein (eine Funktion statt 16 gleichartige). Jetzt geht es erst einmal um die korrekte Syntax.

Hallo Horst,

ich würde bei 1-dimensionlaen Arrays bleiben. Arrays haben ja immer da ihre Berechtigung, wo man über den Array-Index z.b in einer Laufvariable immer in der gleichen Weise auf die einzelnen Array-Elemente zugreifen kann. Das ist beim Laufindex über die Fahrstraßen der Fall.
Auf die unterschiedlchen Variablen - aktueller Zustand, alter Zustand. Pinnummer ... usw. - wirst Du aber immer individuell zugreifen, dass sind ganz unterschiedliche Dinge. Die in einer 2. Dimension als Array zu definieren bringt dir keinerlei Vorteile. Belässt Du es bei eindimensionalen Arrays kannst Du auch weiterhin die unterschiedlichen Variablennamen (z.B. statNew, statOld, inputPin, WeichenPin .... ) verwenden. Das erhöht die Übersichtlichkeit des Programms.
Gegebenenfalls brauchst Du da auch unterschiedliche Datentypen, das ginge dann in einer 2. Array-Dimension gar nicht.
Wo man drüber nachdenken könnte, alle Daten für eine Fahrstraße in einer Struktur zusammenzufassen, und dass dann als Array zu definieren. Das geht dann aber schon recht tief in die C-Programmierung....

Zitat

---

'goto' braucht man in C eigentlich nie. Es ist eher ein Anachronismus, dass das überhaupt noch geht.

---

[Klugscheissermodus]
goto hat in C sehrwohl seine Daseinsberechtigung. Manchmal wird der Code leserlicher wenn ein goto an richtiger Stelle verwendet wird. Im Linux Kernel und den Treibern z.B. werden bei knapp 20 Millionen Zeilen Code gute 14 Tausend gotos verwendet

In PIC Assembler sind "Computed Gotos" ein probates Mittel um sehr effizient Lookuptables aufzubauen
[/Klugscheissermodus]

http://www.horstbu.de/forum/altstadtthird.ino ist der jetzt recht kurze dritte Versuch. Allerdings sagt er mir bei dem Sprung nach dosomething () stets = "was not declared in this scope". Offenbar funktioniert die Einbindung neuer Funktionen mal und mal nicht - wie verklausuliert auch bei den FAQ auf der Arduino-Seite steht.

Es soll ja kein "schönes" Programm sein, sondern für seinen Zweck funktionieren. Was zu vereinfachen geht, sollte man natürlich vereinfachen. Da es aber isoliert auf dem Arduino läuft und mit dem Rest der Welt nicht in Kontakt kommt, stören doch auch die globalen Variablen weniger. Das Array enthält die fahrstraßenspezifischen Variablen in numerischer Ordnung der Fahrstraßen. Diese kompakte Form der Speicherung von 7 * 16 Variablen finde ich an sich sehr übersichtlich. Dann folgen ein paar allgemeine Variable.

Im "Setup" erfolgt ja bereits eine quasi feste Verdrahtung mit In- und Output. Input ist immer eine Schalterstellung und Output Strom über Signalpin und die drei Weichenpins. Insofern ist das Programm in seiner Arbeit sehr gleichförmig - eigentlich langweilig. Nur bei den Fahrstraßen 02 und 20 - im Array 1 und 7 - wird noch ein zusätzliches Relais angesprochen

"Loop" prüft auf Änderungen der Schalterstellungen. In einer for-Schleife werden alle 16 Möglichkeiten abgefragt, ob sich der Zustand änderte. Wenn nein, beginnt "loop" neu. Sonst bricht bei der zuerst festgestellten Änderung die Schleife ab und das Programm geht in den Änderungsmodus. Wenn der Bediener wie verrückt mit den Tasten spielt, mag das Programm durcheinander kommen. Das nehme ich erstmal in Kauf. Interrupts sind nicht vorgesehen, sondern eine zweite Änderung muss solange warten, bis die erste abgearbeitet ist.

Im Änderungsmodus (dosomething) wird zuerst der einfachere Fall behandelt, dass die Fahrstraße abgeschaltet ist. Das Signal geht auf Hp0 oder Sh0 und die Sicherheitsklasse wird freigegeben. Die Weichen bleiben wie sie sind, bis eine neue Fahrstrasse ihre Änderung anfordert. Soll dagegen eine neue Fahrstrasse eingestellt werden, folgt die Sicherheitsprüfung. Ist sie negativ, ertönt der Piepston solange, bis der Schalter zurück gestellt wird. Diese if-Stafette ist noch mit der längste Programmteil geworden.

Danach geht alles ganz fix. Signalpin und die drei Weichenpins sind vordefiniert uns so erfolgt zuerst der Stellimpuls für die Weichen und zuletzt das Einschalten von Dauerstrom für das Signal- und Fahrstromrelais, bis die Fahrstraße wieder manuell aufgelöst wird. Ein Mimik, dies durch den fahrenden Zug zu machen, muss nicht unbedingt sein. Irgendetwas will man ja auch selbst zu tun haben.

@ Bodo - Du hast die Relais bzw. Servos mit dem ULN2803A angesteuert? Welche Erfahrungen hast Du mit diesem Bauteil gemacht?

Hallo Horst,

Zitat

---

@ Bodo - Du hast die Relais bzw. Servos mit dem ULN2803A angesteuert? Welche Erfahrungen hast Du mit diesem Bauteil gemacht?

---

Ich bin zwar nicht der Bodo, setze diese Bausteine aber zur Relaisansteuerung ausschließlich ein. Ist sehr kompakt, und auch die Freilaufdiode ist schon integriert.

Ich habe deinen Sketch mal etwas überarbeitet. Er enthielt noch eine ganze Reihe Syntaxfehler - auch einige die der Compiler nicht als soche erkennt ( also eigentlich eher semantische Fehler ). Die Syntax von C ist doch etwas anders als bei Basic. Besonders muss man darauf achten, dass unter C die Zuweisung '=' und der Vergleich '==' unterschiedliche Syntax haben. Wenn man beim if versehentlich nur '=' einsetzt, ist das syntaktisch für den Compiler zwar ok, macht aber ganz was anderes als man beabsichtigt.
Auch dein 2-dimensionales Array funktioniert so nicht. Ich hab das wieder auf 1-dimensional geändert, weil das doch einfacher und übersichtlicher ist.
Der Aufruf von loop() am Ende von dosomething führt zu einem heimtückischen Fehler, das darf man so nicht machen. Du rufst dann rekursiv unbegrenzt immer wieder Unterprogramme auf, ohne zurückzukehren. Da läuft irgendwann der Stack über und der Sketch stürzt ab. Das wird bei dir zwar rel lange dauern und wahrscheinlich ist dann deine Eisenbahnspiel-Session schon vorbei und der Arduino wieder abgeschaltet, aber das ist nicht sicher.

Zitat

---

Was zu vereinfachen geht, sollte man natürlich vereinfachen. Da es aber isoliert auf dem Arduino läuft und mit dem Rest der Welt nicht in Kontakt kommt, stören doch auch die globalen Variablen weniger.

---

Das mit den globalen Variablen hat doch nichts mit dem isolierten Einsatz zu tun. Globale Variable sind ja auch nicht per se schlecht, kaum ein Programm wird ohne sie auskommen. Nur zur Übergabe an ein Unterprogramm sollte man sie wirklich nicht einsetzen, das geht mit Übergabeparametern viel einfacher - und vereinfachen soll man ja
An der Logik des Programms habe ich nichts verändert - ob die so ok ist, kannst nur Du feststellen. Schau es dir mal an, es ist noch kürzer geworden und lässt sich jetzt zumindest fehlerfrei übersetzen.

/* Hampstedt-Altstadt, Version 3
    Reihenfolge der 16 Fahrstrassen im Array
    01,02,03,08,10,16,17,20,26,27,30,61,62,71,72,80 */
 
byte oldfahrt[16]   = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} ;   // 0 - 16 Fahrstrassen IST
byte newfahrt[16]   = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} ;  // 1 - 16 Fahrstrassen SOLL
byte SignalP[16]  = {34, 34, 34, 34, 22, 24, 24, 26, 28, 28, 30, 36, 36, 38, 38, 32}; // 2 - Signalpin
byte WeichenP1[16] = {31, 27, 35, 45, 31, 33, 33, 27, 29, 29, 35, 39, 39, 37, 37, 45}; // 3 - Weichenpin1
byte WeichenP2[16] = {43, 41, 41, 47, 43, 39, 37, 41, 39, 37, 41, 33, 29, 33, 29, 47}; // 4 - Weichenpin2
byte WeichenP3[16] = {47, 43, 43, 47, 47, 47, 47, 43, 47, 47, 43, 47, 47, 47, 47, 47}; // 5 - Weichenpin3
byte SecurClass[16] = {1, 1, 3, 3, 1, 6, 6, 1, 6, 6, 3, 6, 6, 6, 6, 3};  // 6 - Sicherheitsklasse
byte infahrtpin[16] = {54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69};
//Setup -------------------------------------------------
void setup()
{
  for ( byte i = 0; i < 16; i++ ) {
    pinMode( infahrtpin[i], INPUT); // Fahrstrassenschalter
  }
  pinMode(22, OUTPUT);    // Relais an fuer Signal A Hp2
  pinMode(24, OUTPUT);    // Relais an fuer Signal A Sh1
  pinMode(26, OUTPUT);    // Relais an fuer Signal B Hp2
  pinMode(28, OUTPUT);    // Relais an fuer Signal B Sh2
  pinMode(30, OUTPUT);    // Relais an fuer Signal C Hp1
  pinMode(32, OUTPUT);    // Relais an Fahrstrom Signal D
  pinMode(34, OUTPUT);    // Relais an fuer Signal E Hp2
  pinMode(36, OUTPUT);    // Relais an fuer Signal 6 Sh1
  pinMode(38, OUTPUT);    // Relais an fuer Signal 7 Sh1
  pinMode(40, OUTPUT);    // Relais an fuer Fahrstrom 2 zu 1
  pinMode(23, OUTPUT);    // Impuls Signal D auf Hp2
  pinMode(25, OUTPUT);    // Impuls Signal D auf Hp0
  pinMode(27, OUTPUT);    // Impuls Weiche - 1g, 4r
  pinMode(29, OUTPUT);    // Impuls Weiche - 1r, 3g
  pinMode(31, OUTPUT);    // Impuls Weiche - 2g, 6r
  pinMode(33, OUTPUT);    // Impuls Weiche - 2r, 3r
  pinMode(35, OUTPUT);    // Impuls Weiche - 4g
  pinMode(37, OUTPUT);    // Impuls Weiche - 5g
  pinMode(39, OUTPUT);    // Impuls Weiche - 5r
  pinMode(41, OUTPUT);    // Impuls Weiche - 6g
  pinMode(43, OUTPUT);    // Impuls Weiche - 7g
  pinMode(45, OUTPUT);    // Impuls Weiche - 7r
  pinMode(47, OUTPUT);    // Dummy-Output, wenn nur 2 Weichenpins
}
// ------------------------------------------------------------
//  LOOP prueft, ob irgendeine Fahrstrasse geaendert wurde
void loop()
{
  byte i;
  for ( i = 0; i < 16; i ++)    // 16 Pins abfragen
  {
    oldfahrt[i] = digitalRead (infahrtpin[i]);
    if (oldfahrt[i] != newfahrt[i]) {                 // dann Änderung
      dosomething (i, SignalP[i], WeichenP1[i], WeichenP2[i], WeichenP3[i], SecurClass[i]);
      break; // Bei Änderung Schleife abbrechen
    }
  }
  if ( i == 16) delay(500);     // wenn ungeaendert, kurze Pause
}
// -------------------------------------------------------------
void dosomething (byte fahrstreet, byte signalpin, byte weichenpin1, byte weichenpin2, byte weichenpin3, byte securclass)
{
  bool error = false;  // Flag ob Fehler aufgetreten
  byte secur1  = 0;  // Sicherheits-Klassen
  byte secur3  = 0;
  byte secur6  = 0;
 
  if (oldfahrt[fahrstreet] > newfahrt[fahrstreet])     // dann Fahrstrasse zurücksetzen
  {
    newfahrt[fahrstreet] = 0;
    digitalWrite (signalpin, LOW);
    if (securclass == 1)
    {
      secur1 = 0;
    }
    if (securclass == 3)
    {
      secur3 = 0;
    }
    if (securclass == 6)
    {
      secur6 = 0;
    }
    if (fahrstreet == 1 || fahrstreet == 5) // Fahrstrasse 02 oder 20
    {
      digitalWrite (22, LOW);          // Fahrstromrelais # 2
    }
  }
  /* --------------------------------------------------------
     Ansonsten folgt Sicherheitsprüfung, da ja newby > oldie.
     Es gibt nur eine Fahrstraße bei Klasse 1, bei Klasse 3 kann auch
     eine andere mit Klasse 6 bestehen und bei Klasse 6 eine mit Klasse 3
  */
  if (securclass == 1)
  {
    if (secur1 == 1 || secur3 == 1 || secur6 == 1)
    {
      beepy ();
      error = true;
    }
  }
  if (securclass == 3)
  {
    if (secur1 == 1 || secur3 == 1 )
    {
      beepy ();
      error = true;
    }
  }
  if (securclass == 6)
  {
    if (secur1 == 1 || secur6 == 1)
    {
      beepy ();
      error = true;
    }
  }
  if ( !error ) {
    // Sicherheitsprüfung o.k. - jetzt Fahrstrasse einstellen
    if (securclass == 1)        // Securclass schärfen
    {
      secur1 = 1;
    }
    if (securclass == 3)
    {
      secur3 = 1;
    }
    if (securclass == 6)
    {
      secur6 = 1;
    }
    oldfahrt[fahrstreet] = 1;
    digitalWrite (weichenpin1, HIGH);
    delay (400);
    digitalWrite (weichenpin1, LOW);
    digitalWrite (weichenpin2, HIGH);
    delay (400);
    digitalWrite (weichenpin2, LOW);
    digitalWrite (weichenpin3, HIGH);
    delay (400);
    digitalWrite (weichenpin3, LOW);
    digitalWrite (signalpin, HIGH);    // zuletzt das Signal
    if (fahrstreet == 1 || fahrstreet == 5 ) // Fahrstrasse 02 oder 20
    {
      digitalWrite (22, HIGH);          // Fahrstromrelais # 2
    }
  }
}
// -------------------------------------------------------
void beepy ()
{
  delay (1000);
}
 
 

Hallo Horst,

Zitat

---

Hallo Horst,

Zitat

---

@ Bodo - Du hast die Relais bzw. Servos mit dem ULN2803A angesteuert? Welche Erfahrungen hast Du mit diesem Bauteil gemacht?

---

Ich bin zwar nicht der Bodo, setze diese Bausteine aber zur Relaisansteuerung ausschließlich ein. Ist sehr kompakt, und auch die Freilaufdiode ist schon integriert.

---

... genau - ist eigentlich einer _der_ Standardbausteine, wenn man etwas mehr Leistung benötigt, als der Prozessor hergibt. Ich benutze ihn z.B. auch zusammen mit den Schieberegistern. Der Vorteil gegenüber einzelnen Transistoren ist halt der benötigte Platz und man kann sehr leicht die Eingänge direkt gegenüber den Prozessorausgängen (bzw. den Arduin-Pins) anordnen.

Viele Grüße, Bodo

Ein freundliches Hallo - draußen scheint sogar mal die Sonne ....
Danke für die Straffung. Nun hat ja jede Sprache ihre Regeln und die sind eben wie sie sind. Aber manchmal ist man doch überrascht
* im Setup darf man for-Schleifen machen? In diesem Fall sehr praktisch
* bei "loop" zwei öffnende { und drei schließende? Hat das mit dem "break" zu tun?
°if (x==1,||x==3||x==6) ---So etwas ist erlaubt? Auch sehr praktisch

Ok. - wenn denn irgenwann der Stack überlüft, wollen wir das vermeiden. Wie aber merkt C, dass das Programm am Ende von "dosomething" aufhören soll und wieder bei loop anfangen soll, statt nach "beepy" zu gehen, wo der nächst Befehl im Listing stände? Nur durch die die Funktion schließende Klammer? Ich liebe Programme, denen man klar sagen kann, wo sie weitermachen sollen.

Und C scheint mir irgendwas bürokratisches zu haben. Bei der Sicherheitsprüfung akzeptiert er die beiden ersten beepy(), aber beim dritten meint er wieder "beepy() was not declared in this scope". Hoffe, das liegt an der fuzzy-Logik des Arduino-Programmes und nicht an C. Es ist jedenfalls nervig, keine Syntax-Verletzung festzustellen und er reagiert dennoch so.

Trotzdem - vielen Dank für Deine Überarbeitung und die guten Tipps.

Hallo Horst,

Zitat

---

* im Setup darf man for-Schleifen machen? In diesem Fall sehr praktisch

---

setup() ist eine normale Funktion wie alle anderen auch. Da ist syntaktisch auch alles erlaubt. Das Besondere daran ist nur, dass sie als erstes und nur 1x aufgerufen wird.

Zitat

---

* bei "loop" zwei öffnende { und drei schließende? Hat das mit dem "break" zu tun?

---

Nee, das sind auch drei öffnende. Eine hat sich nur beim Editieren am Ende der if-Zeile versteckt - sorry.

Zitat

---

°if (x==1,||x==3||x==6) ---So etwas ist erlaubt? Auch sehr praktisch

---

Wenn Du das Komma weglässt , ist es syntaktisch korrekt. Die 2 Striche '||' entsprechen dem OR in Basic. Setzt Du stattdessen '&&' ein, entspricht es dem AND bei Basic.

Zitat

---

Wie aber merkt C, dass das Programm am Ende von "dosomething" aufhören soll und wieder bei loop anfangen soll, statt nach "beepy" zu gehen, wo der nächst Befehl im Listing stände? Nur durch die die Funktion schließende Klammer? Ich liebe Programme, denen man klar sagen kann, wo sie weitermachen sollen.

---

Ja, die Klammer '{....}'macht's Jede Funktion ist ein Codeblock, der mit '{' beginnt, und mit der zugehörigen '}' endet. Läuft das Programm auf die schließende Klammer, weis der Compiler, dass es zurück zum Aufrufpunkt geht. Du kannst da aber auch ein 'return;' hinschreiben, wenn dir das besser gefällt .

Zitat

---

Bei der Sicherheitsprüfung akzeptiert er die beiden ersten beepy(), aber beim dritten meint er wieder "beepy() was not declared in this scope". Hoffe, das liegt an der fuzzy-Logik des Arduino-Programmes und nicht an C. Es ist jedenfalls nervig, keine Syntax-Verletzung festzustellen und er reagiert dennoch so.

---

Das ist bei mir nicht passiert. Was hast Du denn geändert?. Fehlermeldungen werden vom C-Compiler erzeugt, da hat die Arduino IDE eigentlich nichts mit zu tun. Allerdings ist die letzte Meldung, die Du unten in der IDE siehst, oftmals ein Folgefehler eines vorhergehenden Fehlers. Da muss man unten im Meldebereich hochscrollen, oder den größer machen.

Hallo Franz-Peter,
von 18 kBy auf 6 KBy - das macht die Sache doch sehr viel übersichtlicher. An deinem Entwurf habe ich nur geändert, dass secur1, secur3 und secur6 globale Variable wurden, da sie beim Aufruf von "dosomething" durchaus != 0 sein können und sollen.
http://www.horstbu.de/forum/hampold4.ino
"Er" bemängelt in den Zeilen 108, 114 und 120 jeweils --> "beepy " was not declared in this scope - und dann in Zeile 161, wo "beepy" beginnt, meint er, "a function-definition is not allowed before { token". Nur witzig, dass er mit der Funktion "dosomething" diese Probleme nicht hat.

Bei "loop wären Öffner doch nur vor "byte i" und nach der for-Deklaration nötig und schließende Klammern nach dem "break" und am Ende der Funktion. Oder schriebe man besser if (i ==16) { delay(500); } ?? Ich teste da noch einmal verschiedene Möglichleiten. Offenbar ist es auf dem Arduino unsportlich, andere Funktionen vor der "loop" zu placieren - aber dahinter ist es auch nicht recht.

Deswegen halte ich C eben für eine etwas bürokratische Sprache. In Assembler deklarierst du irgendwo ein "label" und kommst mit einem bedingten oder unbedigtem Aufruf dahin und wieder zurück oder kannst einfach dorthin jumpen und da weiternachen. Andererseits sind die "if"-Abfragen in C ja ausgesprochen komfortabel.

Zitat

---

An deinem Entwurf habe ich nur geändert, dass secur1, secur3 und secur6 globale Variable wurden, da sie beim Aufruf von "dosomething" durchaus != 0 sein können und sollen.

---

Deswegen hätte man sie nicht global machen müssen, aber das ist eine andere Geschichte, lassen wir das mal...
Du hast allerdings schon eine ganze Menge mehr geändert als nur die Variablen global zu machen. Dabei ist dir die {...} Zuordnung durcheinandergeraten. Deshalb kommen die Fehlermeldungen.
Noch ein Tip: Wenn Du im Editor den Cursor unmittelbar vor eine öffnende Klammer setzt, wird die zugehörige schließende Klammer markiert und umgekehrt beim Cursor vor einer schließenden wird die öffnende markiert. So kannst Du leicht prüfen, ob du irgendwo eine vergessen oder zuviel gemacht hast.

Zitat

---

Bei "loop wären Öffner doch nur vor "byte i" und nach der for-Deklaration nötig und schließende Klammern nach dem "break" und am Ende der Funktion. Oder schriebe man besser if (i ==16) { delay(500); } ??

---

Nein, das muss schon so sein wie ich das gemacht habe. Die {...} definieren Codeblöcke. Hinter einer if-Abfrage werden immer entweder alle Anweisungen im Codeblock ausgeführt, oder gar keine.
Du hast da zuviele entfernt, auch z.B. hier

  if (securclass == 1)
  {
    if (secur1 == 1 || secur3 == 1 || secur6 == 1)
      beepy();
    error = true;
  }
 
 

müssen die Klammern um beepy und error=true wieder hin.

Zitat

---

Deswegen halte ich C eben für eine etwas bürokratische Sprache. In Assembler deklarierst du irgendwo ein "label" und kommst mit einem bedingten oder unbedigtem Aufruf dahin und wieder zurück oder kannst einfach dorthin jumpen und da weiternachen.

---

Letztendlich ist jede Sprache 'bürokratisch' was die Einhaltung der Syntaxregeln angeht. Dass die höheren Programmiersprachen hier mehr Einschränkungen haben als Assembler ist durchaus Absicht. Es soll ja gerade die Entstehung von 'Spaghetti-Code' mit uneingeschränktem Hin- und Herspringen verhindert werden. Wobei 'C' hier noch sehr vieles erlaubt (was man aber nicht unbedingt machen sollte..). Andere Sprachen sind da noch wesentlich restriktiver.
Ich kann aus meiner beruflichen Erfahrung sagen, dass solcher schwer pflegbare 'Spaghetti-Code' sehr viel Geld kosten kann...

Edit:

Zitat

---

Ich teste da noch einmal verschiedene Möglichleiten.

---

Die geschweiften Klammern sind bei C ein essentielles Sprachelement für die Strukturierung und Funktion des Programms. Du solltest dich unbedingt mal in der Richtung schlau machen, wie die einzusetzen sind. 'Testen' ist da eine sehr schlechte Strategie. Nicht immer führt der falsche Einsatz zu einem Compilerfehler. Oft funktioniert das Programm dann einfach nicht so wie erwartet, und das sind dann schwer zu findende Fehler.

Hallo Horst,

ich wollte nur mal erwähnen, daß man AVRs auch mit Bascom programmieren kann. Vielleicht liegt Dir das besser als C.

Tschüß André

Hallo André, ja, könnte für ihn evtl. eine Alternative sein. Kann BASCOM auch mit dem Arduino Bootlader umgehen, oder ist man da ganz von der Arduino-Welt weg?

Nochmal zu C:

Zitat

---

Oder schriebe man besser if (i ==16) { delay(500); } ??

---

'C' ist eine formatfreie Sprache. D.h. Wie Du deine Zeichen auf die Zeilen verteilst, ist dem Compiler egal. Für ihn ist eine neue Zeile nicht mehr als ein Leerzeichen. ob man also

  if (i == 16)
  {
    delay(500);    // Pause nach Abfrage aller INPUT-Pins
  }
 
 

oder

 if (i ==16) { delay(500); }
 

schreibt, ist dem Compiler völlig egal. Das ist persönliche Geschmackssache. Eine gute Formatierung erhöht allerdings die Lesbarkeit des Programms erheblich.
Da in diesem Fall hinter dem if nur eine einzige Anweisung steht, sind die Klammern auch nicht nötig. Stören tun sie aber auch nicht, ein Codeblock darf auch aus einer einzigen Anweisung bestehen. Viele Programmierer schreiben sie da grundsätzlich hin.

Naja - was man kennt, beurteilt man wohlwollender. Einiges an "C" ist - freundlich gesagt - gewöhnungsbedürftig. Vermutlich gibt es deswegen so viele Programmiersprachen, weil zu viele Leute mit den vorhandenen unzufrieden waren. Letztlich sind die Strukturen einander ziemlich ähnlich - nur eben mit unterschiedlich eingängiger Syntax. Dieses Arduino-Programm "Hampold" ist ja ziemlich trivial. Nervig daher, dass man zehnmal mehr Zeit dafür zubringen muss, dem Verpeiler zu sagen, wo er eine neue Funktion zu berücksichtigen hat, als die Struktur des Programmes zu entwickeln.

Der Hinweis "The Arduino environment attempts to automatically generate prototypes for your functions, so that you can order them as you like in your sketch. This process, however, isn't perfect, and sometimes leads to obscure error messages." auf der Arduino-Webseite stimmt dann auch nicht fröhlicher. Es wird empfohlen, die Funktion vor ihrem Aufruf zu deklarieren - was aber auch nicht immer hinhat. Bleiben wir also am Ball. Inzwischen verfügt der Scetch in seiner 5. Version auch über die features, das 16*2-Display anzusprechen.

Das von André empfohlene BASCOM soll auch auf dem Arduino laufen. Kann man sich ja mal ansehen. Aber eigentlich erwarte ich mehr Transparenz und Stringenz von etwas so verbreitetem wie C. Das sind ja nicht alles leicht zu berichtigende Tippfehler.

Zitat

---

Einiges an "C" ist - freundlich gesagt - gewöhnungsbedürftig.

---

Da hast Du sicher nicht unrecht. C ist eine Sprache für Schreibfaule. Was bei anderen Sprachen Schlüsselwörter sind, sind bei C einfach nur Zeichen wie {,},|,||,&,&& ... Das macht die Sprache nicht gerade leicht lesbar, das ist richtig. C braucht deshalb sicher mehr Einarbeitungszeit als andere Sprachen. Dadurch kommt es zu so einer Aussage:

Zitat

---

Dieses Arduino-Programm "Hampold" ist ja ziemlich trivial. Nervig daher, dass man zehnmal mehr Zeit dafür zubringen muss, dem Verpeiler zu sagen, wo er eine neue Funktion zu berücksichtigen hat, als die Struktur des Programmes zu entwickeln.

---

Ein C-Programm kann man eben leider nicht mal 'so eben nebenbei' schreiben, wenn man die Syntax noch nicht wirklich 'intus' hat. Das ist bei mehr 'sprechenden' Sprachen wie auch Basic sicher einfacher. Vielleicht ist das auch eines der großen Probleme des Arduino, der sich ja an sich an Einsteiger richtet, mit C aber eine nicht gerade einsteigerfreundliche Programmiersprache verwendet.

Zitat

---

Der Hinweis "The Arduino environment attempts to automatically generate prototypes for your functions, so that you can order them as you like in your sketch. This process, however, isn't perfect, and sometimes leads to obscure error messages." auf der Arduino-Webseite stimmt dann auch nicht fröhlicher.

---

Naja, die IDE versucht es halt dem Anwender etwas einfacher zu machen. Wobei ich da noch nie Probleme hatte, wenn es die richtige Version der IDE war. Da gab's mal ein paar Versionen, die hatten erhebliche Probleme damit .

Zitat

---

Es wird empfohlen, die Funktion vor ihrem Aufruf zu deklarieren - was aber auch nicht immer hinhat.

---

Doch, das haut immer hin - wenn man es denn richtig macht . Der Compiler arbeitet in >99,999% der Fälle schon richtig, da sitzt das Problem eher vor dem Computer. Es sei denn, man nimmt die ganze Sprache C als ein Problem war ( was auch nicht wenige Programmierer tun...)

Jetzt mal Version 6 - mit noch ein paar ?? = hrrp://www.horstbu.de/forum/hampold6.ino Immerhin hat er die Befehle für das Display alle akzeptiert. Ob es tatsächlich hinhaut, wird man sehen.

Das Programm ist seit 2 Tagen fertig und mit völlig durchsichtigen Abläufen und Strukturen sowie den von "C" geliebten ; und {} in ausreichender Zahl. Dennoch gibt mir der Compiler kryptische Fehlermeldungen - vor allem beepy mag er garnicht. Wollte eigentlich heute mein Schaltpult beginnen, damit ich den Arduino zumindest mit dem 2*16-Display schon mal testen kann. In der Tat bedaure ich jetzt, den Z-80 Computer vor 20 Jahren weggeschmissen zu haben. Damit könnte man jetzt echt etwas anfangen. Die Tutorials im Netz über die Funktionen in "C" sind auch eher verdunkelnd statt genau und wegweisend. Funktionen vor "loop" ins Arduino-Programm zu setzen, ist wohl auch nicht das Wahre. Jetzt eben mit "Prototypen" im Setup.

BASCOM ist ja nun auch nicht umsonst. Für da Geld hätte ich auch einen BeagleBoneBlack besorgen können, der eine Art DOS versteht und wohl auch Linux kann.

Hallo Horst,
welche IDE-Version setzt Du eigentlich ein? Vielleicht ist es ja die 'Problemversion', wo das bei den Prototypes nicht funktioniert. Ich weis die Nr. nicht mehr genau, es war was mit 1.6.? . Ich glaube, ab der 1.6.7 ging es wieder (oder das war die letzte fehlerhafte?). Die aktuellen Versionen haben da jedenfalls keine Probleme. Und wenn, helfen dir die Prototypes im setup() auch nichts. Die sollten nicht innerhalb einer Funktion stehen, sondern da, wo auch die globalen Variablen definiert werden.

Ansonsten hast Du noch ein paar Tippfehler drin: '=' statt '==' und 'notone' schreibt sich 'noTone'. C unterscheidet Groß- und Kleinschreibung.