Pret met Arduino

[RudyB]

Mooi werk, daar kan iedereen die twee kanten op wil rijden gebruik van maken.

Als ik het even snel bekijk dan wacht je nadat sensor2 laag is geworden tot hij weer hoog wordt en dat is dan einde trein? Dat werkt alleen als de sensor zo geplaatst is dat de ruimte tussen wagons niet gezien wordt. Voor een optische sensor kan dat lukken als sensor en ontvanger diagonaal over de rails staan. Betrouwbaarder zou zijn om de 4 regels code een paar posts hierboven te gebruiken, die reageert pas als de tijd na de laatste L>H  langer duurt dan een instelbare tijd, zeg 2 seconden.

[guy1846]

beste Rudy
ik heb hier een projectje van gemaakt dat zo kan nagebouwd worden, maar wel voor de 3rail gebruikers,met CS3+ met de rail onderbreking als feedback.  de interface is daar ook op gemaakt. met een galvanische scheiding tussen baan en micro controller.ontdaan van debounce.
je kan het zo publiceren, het werkt perfect. ik krijg het echter niet doorgestuurd.
als je me een mail stuurt zal ik het zo proberen.
mijn email   ......@gmail.com
gr
guy

On spam te voorkomen emailadres verwijderd. Beter even per Pb doen..

[bask185]

@Guy, als je code plaats tussen code tags dan wordt de boel wat leesbaarder voor anderen.
[ c o d e ] ( zonder de spaties )
// dit wordt dan code
[ / c o d e ]

Ik wil als je het niet erg vindt, je een paar tips meegeven om meer leesbare code te maken. Je code zoals hij is, is een klein beetje cryptisch. Het is nog wel te behappen maar het kan netter.
Je uitlijning klopt niet op bepaalde plaatsen en er staan aparte constructies in. Ik weet niet of het trouwens zo bedoeld is, ik vermoed van wel, maar sommige cases hebben geen break-statement.

Code: [Selecteer]

    void loop() {
       switch(state) {
    case 1: // idle
      if(digitalRead(SENSOR1_PIN) == LOW) transition = 12;
Dit kan je schrijven als:

Code: [Selecteer]

    void loop() {
        switch(state) {
        case 1: // sommige mensen doen dit, omdat de case een label is, een oud obsolete ding uit assembly.
            if(digitalRead(SENSOR1_PIN) == LOW) transition = 12;
// of als

    void loop() {
       switch(state) { // dit is iets meer standaard
          case 1: // idle
          if(digitalRead(SENSOR1_PIN) == LOW) transition = 12;
// of als
    void loop() {
       switch(state) { // dit is iets meer standaard
          case 1: // Ik ben zelf geen fan van inspringen na een : alleen na een {   maar ook dit wordt geaccepteerd
              if(digitalRead(SENSOR1_PIN) == LOW) transition = 12;

Een wit regel achter een break; kan ook geen kwaad.

Code: [Selecteer]

case 8: // blinking, gate closing
      if(digitalRead(SENSOR1_PIN) == LOW) transition = 89;
    break;
    case 9: // blinking,waiting last wagon
      if(digitalRead(SENSOR1_PIN) == HIGH) transition = 9,10;
 
    case 10: // blinking, gate opening
      if(angle == GATE_OPEN) transition = 10,11;
    break;

// dit is netter
    case 8: // blinking, gate closing
    if(digitalRead(SENSOR1_PIN) == LOW) transition = 89;
    break;

    case 9: // blinking,waiting last wagon
    if(digitalRead(SENSOR1_PIN) == HIGH) transition = 9,10;
    // het klopt dat hier geen break hoort te staan neem ik aan

    case 10: // blinking, gate opening
    if(angle == GATE_OPEN) transition = 10,11;
    break;
// wat ik dan zelf nog wel eens wil doen is, creatief uitlijnen en meer dingen per regel zetten
switch(state) {
    case 7:  if (millis() > time_to_close_gate)     transition = 78;    break;  // blinking, gate still open
    case 8:  if(digitalRead(SENSOR1_PIN) == LOW)    transition = 89;    break;  // blinking, gate closing
    case 9:  if(digitalRead(SENSOR1_PIN) == HIGH)   transition = 9,10;          // blinking,waiting last wagon
    case 10: if(angle == GATE_OPEN)                 transition = 10,11; break;  // blinking, gate opening
    case 11: if (millis() > time_to_open_gate)      transition = 11,1;          // hier hoort wel een break eigenlijk
}
Niet iedereen is het hier mee eens omdat het niet 'standaard' is, maar ik vind dat de boel wel leesbaarder wordt. Met deze stijl valt het ook veel eerder op, als er iets niet klopt zoals bijvoorbeeld een missende break; of het valt eerder op dat er een case is bewust zonder een break; 

Ik snap in grote lijnen wat je doet. Je hebt 1 switch-statement die de input en de flow regelt, en een tweede switch-statement die de output afhandelt. Ik begrijp alleen niet waarom je dan nog 2 switch-statements heb. Dit ruikt wel erg naar die Meally en Moor theorieën

Wat ik wilde zeggen er over:
Normaliter in state machines zijn nummertjes erg ongewenst. Ik snap dat je ze hier nodig dacht te hebben vanwege je gebruikte structuur. Maar je bent toch beter af met constantes met praktische namen. Bijvoorbeeld

Code: [Selecteer]

case 1: // idle
...
case 2: // blinking, gate still open
...
case 3: // blinking, gate closing
...
case 4: //blinking waiting last wagon
...
case 5: // blinking, gate opening
...
case 6: // gate open , but still blinking

// Beter is:
enum states {
    idle,
    gate_is_open,
    waiting_last_wagon,
    gate_opening,
    still_blinking,
}
...

case idle:
...
case gate_is_open:
...
case gate_closing:
...
case waiting_last_wagon:
...
case gate_opening:
...
case still_blinking:
Als je consequent met namen werkt ipv nummers, dan maken de daadwerkelijke waardes niet meer uit. Als je hebt

Code: [Selecteer]

byte state = idle;
...
case  idle:
dan maakt het geenzins uit of idle nu 0, 3 of 252 is. Dat maakt het ook makkelijker om states ergens midden in toe te voegen.

Als je netter omgaat met je code, dan wordt het werken met je code ook fijner voor jezelf. Als je veel case labels maakt met nummertjes dan kan je op  een bepaald door de bomen het bos niet meer zien. En als je uitlijning niet klopt, is het lastig te zien welke code achter welke if-statement valt.

Ik heb trouwens nog een vraagje aan iedereen trouwens. Ik heb deze syntax nog nooit waargenomen:

Code: [Selecteer]

transition = 9,10;
en
case 9:10,
Kan iemand mij uitleggen wat er hier precies gebeurt?

Bas

[guy1846]

Beste Bas
zoals je terecht opmerkt,ik heb er nog niet veel kaas van gegeten.ik heb al oefenend de file van Rudy uitgebreid. samen met de interface is het een projectje dat uitgebreid getest is en bij mij althans perfekt werkt.weet dat de interface (je) gemaakt is voor 3Rail (Marklin) met rail detektie en galvanisch gescheiden van de micro controller, de schakeling heeft geen last van debounce.
ik kijk de komende dagen met belangstelling uit naar je reacties.

[guy1846]

crossrail interface
De interface voor de verbinding met het arduino printje.
is bedoeld voor 3rail gebruikers.
100% veilig voor de micro controller dankzij de galvanische scheiding met opto coupler.
is uitvoerig getest.
kan met aparte kontaktrail verbonden worden, of met reeds aanwezige bezetmelder-aansluiting aan de kontaktrail zelf of een S88, of een mix van beiden.
kan uiteraard ook voor andere toepassing op de spoorbaan gebruikt worden.

[guy1846]

crossrail video

Code:[Selecteer]
[flash=640,480]https://www.youtube.com/v/QXV8STIhZhQ[flash]

[72sonett]

<a href="https://www.youtube.com/v/QXV8STIhZhQ" target="_blank" class="new_win">https://www.youtube.com/v/QXV8STIhZhQ</a>