BMB 00-modulebaan, Algemeen.

[bask185]

Als de adressen niet veranderen nadat je ze in code heb aangepast. Dat dan hoogstwaarschijnlijk de upload niet goed gelukt is.

Heb je vanuit de Arduino ide gewerkt of heb je andere text editor gebruikt?

Als de upload wel goed is gegaan, is misschien het XpressNet adres al in bezet Het geeft geen verklaring voor een niet veranderend IP adres.

Mvg,

Bas

[St00mboy]

Niet gehinderd door enige kennis van zaken heb ik - evenals bij de eerste WAM - de sketch vanuit de Arduino IDE geüpload, na eerst het IP-adres en het XNet adres in de sketch aangepast te hebben. Na het uploaden zie je het volgende in de serial monitor (=het zwarte deel):


Zoals je ziet werkt hij met een geheel ander IP- en XNet adres als rood omcirkeld in de sketch aangegeven.

Met deze WAM had ik in 2016 hetzelfde probleem. Forumlid Nico Teering zei er toen het volgende over:

Het IP-adres dat getoond wordt, wordt gelezen uit EEPROM en is niet het adres dat je hebt gezet middels IPAddress ip()
Ik kan uit de sketch niet goed wijs worden hoe en waarom dat gebeurt.
Dat IP-adres staat dus gewoon in EEPROM.
Ik zie wel dat er conditioneel eerst geschreven wordt in EEPROM. Dat is echter afhankelijk van wat er staat op adres 9 (EEXNet=9) in het EEPROM
Voeg daarom een regel toe om te checken wat daar staat. Als dat groter is dan 31 wordt er eerst geschreven.

Ik dacht toen dat het allemaal over dit stukje sketch ging, maar hij zegt dus dat hij het er niet uit kon opmaken:

Serial.println(EEPROM.read(EEXNet));   //VOEG DEZE REGEL TOE

  // EEPROM usage for storing the IP adresses
  if (digitalRead(ResetPin) == LOW || EEPROM.read(EEXNet) < 32) {

    XNetAddress = EEPROM.read(EEXNet);
  }
  else {
    EEPROM.write(EEXNet, XNetAddress);
    EEPROM.write(EEip, ip[0]);
    EEPROM.write(EEip + 1, ip[1]);
    EEPROM.write(EEip + 2, ip[2]);
    EEPROM.write(EEip + 3, ip[3]);
  }
  ip[0] = EEPROM.read(EEip);
  ip[1] = EEPROM.read(EEip + 1);
  ip[2] = EEPROM.read(EEip + 2);
  ip[3] = EEPROM.read(EEip + 3);

Het  toevoegen van de regel kwam van Nico, en die staat er nu in. De regel eronder staat er niet meer in. Ik weet niet of dat toevoegen zin heeft en of de 2e regel er ook nog bij moet. 
In de sketch staat ook nog o.a. dit vermeld:

bool FixIP = false;      // Indien true wordt  het IP adres bij het opstarten altijd teruggezet naar het default IP adres, zet op false als je met de webconfig wilt werken

maar verderop staat dit:

Serial.println(EEPROM.read(EEXNet));
  // EEPROM usage for storing the IP adresses
  if (digitalRead(ResetPin) == LOW || FixIP == true || EEPROM.read(EEXNet) == 255) {
    EEPROM.write(EEXNet, XNetAddress);
    EEPROM.write(EEip, ip[0]);
    EEPROM.write(EEip + 1, ip[1]);
    EEPROM.write(EEip + 2, ip[2]);
    EEPROM.write(EEip + 3, ip[3]);

Ik kan niet beoordelen of dat elkaar bijt.

Op internet blijken er wel meer van dit soort problemen met de W5100 te zijn. Ergens had iemand deze tekst aan zijn sketch toegevoegd:

// SS must be output and disable any device using SS
pinMode(53,OUTPUT);
digitalWrite(53,HIGH); //any device on the SS pin will be disabled

// disable w5100
// pinMode(10,OUTPUT);
// digitalWrite(10,HIGH); // disable W5100

// disable SD
pinMode(4,OUTPUT);
digitalWrite(4,HIGH); // disable SD

//Add code in function setup(), i'm success.
pinMode(11,INPUT);
pinMode(12,INPUT);
pinMode(13,INPUT);

Geen idee of dat iets op zou kunnen lossen.

Leen.

[bask185]

Leen,

Kan ik ergens de gehele sketch vinden?

En kleinigheidje. Als je code knipt en hier post kan je beter het code knopje links van de citaat knop gebruiken. Dan krijg je de[ c o d e ] tags en code is dan beter uitgelijnd en iets leesbaarder.

Dat verhaal over die SS pin van dat ethernet shield is simpel. Zowel de ethernet IC als de SD kaart module zitten opdezelfde SPI bus. De arduino kan naar 1 van deze dingen tegelijk schrijven of lezen. De arduino kan kiezen tussen de apparaten door de SS pin (Slave Select*)  omlaag te trekken. Als je de chip niet gebruikt moet de SS pin hoog zijn. Standaard is elke arduino pin gecongifureerd als INPUT tot jij er iets anders van maakt. Dit is noch HIGH noch LOW en kan bij precies dit soort dingen problemen geven. Om de chip goed uit te zetten moet de SS pin of een output pin zijn die HIGH is of het moet een INPUT_PULLUP zijn. Beide modi trekken de pin naar 5V.

Mvg,

Bas


* slave mogen we niet meer zeggen, daarom zeggen we nu CS voor Chip Select

[St00mboy]

Volgens mij staat de hele sketch van Dick hier op Github.

Leen.

[bask185]

Ik heb commentaar toegevoegd. Je moet of die fixIP op true zetten, of je moet pin A5 aan gnd koppelen of de EEPROM waarde op adres EEXNet moet 255 zijn.

Als een aan een van deze condities wordt voldaan, dan worden de default waardes in het EEPROM geladen en anders niet. En daaronder worden de IP waardes en Xnet adres onconditioneel uit het EEPROM gehaald.

Code: [Selecteer]

// hier staan default waardes vastgelegd
IPAddress ip(192, 168, 0, 11);
byte XNetAddress = 30; 

bool FixIP = false; // deze op true zetten lost het probleem op
// je kan ook A5 aan GND koppelen

// een van deze condities moet waar zijn, om het eeprom te vullen met de default waardes
  if (digitalRead(ResetPin) == LOW || FixIP == true || EEPROM.read(EEXNet) == 255) {
    EEPROM.write(EEXNet, XNetAddress);  // hier worden de default waardes in EEPROM opgeslagen
    EEPROM.write(EEip, ip[0]);
    EEPROM.write(EEip + 1, ip[1]);
    EEPROM.write(EEip + 2, ip[2]);
    EEPROM.write(EEip + 3, ip[3]);
  }

  XNetAddress = EEPROM.read(EEXNet); // hier worden waardes ALTIJD uit EEPROM gehaald
  ip[0] = EEPROM.read(EEip);
  ip[1] = EEPROM.read(EEip + 1);
  ip[2] = EEPROM.read(EEip + 2);
  ip[3] = EEPROM.read(EEip + 3);

Dat verhaal over EEXNet is als volgt. Bij een ongebruikte arduino staat het hele EEPROM vol met 255. Als dit programma voor het eerst draait dan kan het programma zien adhv deze waarde of dit de eerste keer is dat hij het programma uitvoert. Bij deze allereerste keer opstarten worden er dan default waardes in het EEPROM gestopt. Bij de 2e keer opstarten doet hij dit niet meer omdat hij een andere waarde dan 255 in het EEPROM stopt zodat een gebruiker zelf IP adres en Xnet adres kan aanpassen.

Ik hoop dat het zo duidelijk is? 

Mvg,

Bas

[St00mboy]

Nou ja, duidelijkER wel.  Dus zoals ik het nu begrijp moet hier "false" door "true" vervangen worden:

bool FixIP = false;      // Indien true wordt  het IP adres bij het opstarten altijd teruggezet naar het default IP adres, zet op false als je met de webconfig wilt werken

Leen.

[St00mboy]

WAM 11 werkte gisteravond wel weer goed, en dus kon ik hem testen met de wissels van de fiddle yard. Ik had daarvoor twee tablets en een foon ter beschikking. Op een tablet stond de oude Roco-app, op de andere de nieuwe en op de foon stonden ze allebei. Alle apparaten maken zoals gebruikelijk verbinding met de router, maar in de app werd tijdens het testen het IP-adres op 192.168.0.11 gezet, het adres van de WAM:


Dit was de testopstelling met een van de FY-bakken:


De tablet met de oude Roco-app hebben we ook in Stroe gebruikt en die werd het eerste aangesloten. Het schakelen van de wissels ging probleemloos. Daarna werd de tweede tablet met de nieuwe app gestart. Ook die werkte goed. Wat ik graag gezien had, was dat de stand van de wissels in beide tablets synchroon zouden lopen, dus als je met tablet 1 een wissel omzet, dat hij dan in de andere ook meegaat. Maar helaas is dat blijkbaar niet het geval bij de oude app, maar ook als je apparaat op de X-bus aansluiting aangesloten zit. Bij het schakelen van de wissels blijft het dus noodzakelijk om fysiek naar de stand van het wissel te kijken of er lampen of toeters op aan te sluiten. 
Wat mij betreft hebben we het doel bereikt dat het met een WAM mogelijk is om de draadloze verbinding met de Roco app te ontlasten, terwijl de wissels gewoon goed geschakeld kunnen worden.

Leen.

[bask185]

Maar helaas is dat blijkbaar niet het geval bij de oude app

Dus de nieuwe app hobbelt wel correct mee de stand van zaken? Van Apps weet ik niet zo veel, kan je vaak ook niet zo veel aan veranderen 

maar ook als je apparaat op de X-bus aansluiting aangesloten zit. Bij het schakelen van de wissels blijft het dus noodzakelijk om fysiek naar de stand van het wissel te kijken of er lampen of toeters op aan te sluiten.

Om die reden ben ik dus zelf fan van wisselstraten schakelen. Als je dan op een spoor klikt, dan weet je dat alle wissels goed staan, dus ook diegene aan de andere kant van de FY waar we kortsluitingen veroorzaken.

Ik heb mr Gahtow's library nu zo onder de knie dat de arduino nu via XpressNet op de hoogte is van alle gestelde wissels. Daar kan je gebruik van maken om bijvoorbeeld ledjes mee aan te sturen adhv van de wisselstand.

Mvg,

Bas

[St00mboy]

Als ik de nieuwe Roco app op mijn foon en tablet gebruikte, dan hobbelde het mee bij een rechtstreekse draadloze verbinding met de z21, maar via de X-bus hobbelt het niet mee, ook niet met de muizen. Ik heb echter twee oude tablets, die ik voor dit doel wil gebruiken en daar kan alleen de oude app maar op.

In de app kun je ook wisselstraten instellen. Ik heb er drie ingesteld.

Leen.

[St00mboy]

Ik heb "false" vervangen door "true" en nu is het IP- en XNet-adres wel aangepast. Ik krijg ook verbinding met de foon, maar het groene licht van de programmeermodus brandt i.p.v. het blauwe. De seriële monitor laat het volgende zien als ik met een lok probeer te rijden:


De lok rijdt echter niet, maar met de op het Roco kastje aangesloten Multimuis rijdt hij wel. Volgens mij zit alles m.u.v. de adressen en het woordje "true" hetzelfde aangesloten als op WAM 11 die het wel doet en ik gebruik ook dezelfde RJ11 kabel. Het MAC-adres, een eigen compositie, is 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xDA, zou dat misschien de oorzaak kunnen zijn? De regel van Nico heb ik uit de sketch gehaald.

Leen.

[St00mboy]

Ik denk dat ik de vaudt al gevonden heb. Achterop het RS485 boardje moeten twee contactjes als volgt gesoldeerd worden:


Zoals je ziet moet links 3A en rechts 2B verbonden zijn. Op mijn boardje zit dat precies andersom.
Ik heb zo'n gevoel dat het dan niet goed werrukt. 
Morgen maar even regelen, nu eerst wat groene energie .

Leen.

[St00mboy]

Vanwege de gemoedsrust toch naar maar even de solderinkjes op het boardje verplaatst en nu doettie het!  De lok rijdt heen en weer!
Dus morgen testen met twee WAM-verbindingen.
Die groene energie smaakt nu dubbel lekker!

Leen.

[St00mboy]

Nu we de WAM-verbindingen weer op de rails beginnen te krijgen vraag je je als lezer misschien af, waarom die nodig zijn. Welnu, met een flinke modulebaan kan het aantal beschikbare draadloze verbindingen via de z21 tegen de limiet lopen als we met veel deelnemers met een WLAN-muis of een foon draadloos onze treinen besturen. Roco zegt dat er max. 10 draadloze verbindingen mogelijk zijn, maar wij hebben in het verleden bij 7 à 8 verbindingen al problemen gehad, waarbij de treinen ineens onbestuurbaar werden. Via de kabel zijn 31 verbindingen mogelijk.
Nu we de wissels op de fiddle yard met een lekker overzichtelijke tablet besturen zou het in feite ook via een kabeltje kunnen, omdat je met deze tablet niet hoeft rond te lopen. Maar helaas zijn er geen tablets met een XpressNet verbinding en Roco heeft geen ander soortgelijk overzichtelijk paneel waarop je met je vinger het wissel kan bedienen. We kunnen wel de tablet via de Roco-app draadloos met de WAM verbinden die net als een Multimuis met een kabel verbonden is met de X-bus op de z21. Als dat lukt, en daar lijkt het nu wel op, dan betekent dat weer één extra verbinding voor een deelnemer om zijn lok draadloos te besturen. 

Leen.

[bask185]

In mijn handcontroller research kwam ik ook deze tegen.



Een draadloze Lenz Lh101 met een XpressNet ontvanger. Je kan het ontvanger kastje in je XpressNet bus prikken en dan kan je die handregelaar gebruiken. Het enige nadeel is dat dat ding €300 kost  .

Ik heb voor morgen een lijstje in code geklopt met alle voor gedefinieerde wisselstraten / routes op de FY.


Als alles meezit kan ik met 1 of 2 drukjes op m'n keypad alle mogelijke routes uitstippelen.

Saai code voorbeeldje

Code: [Selecteer]

whipeStreet();
street.address[0] = 11  STRAIGHT ;
street.address[1] = 13  CURVED ;
street.address[2] = 29  CURVED ;
street.address[3] = 27  STRAIGHT ;
street.address[4] = 17  CURVED ;
street.address[5] = 19  STRAIGHT ;
street.address[6] = 21  STRAIGHT ;
street.address[7] = 23  STRAIGHT ;
storeStreet(7) ;

whipeStreet();
street.address[0] = 11  CURVED ;
street.address[1] = 23 CURVED ;
storeStreet(8) ;

Ik heb ook ingebakken dat ik alle adressen met 4 kan ophogen omdat die z21s wel eens gekke dingen doen met wisseladressen als je dat niet bewust uitzet in d'n maintenance tool. Voor het geval dat...

Mvg,

Bas

[St00mboy]

Ik heb vandaag met twee WAMmen het omzetten van de wissels getest. Op elke WAM stond één tablet/foon. Bij het omzetten van een wissel op tablet 1 veranderde de stand van het wissel op tablet 2 nu wel mee, zowel met de nieuwe als met de oude Roco app. Ook als ik op tablet 1 de oude app gebruikte en op tablet 2 de nieuwe veranderde de stand van het omgezette wissel op het andere apparaat mee. Alleen op de WLAN-muis en op de Route Controller werkte dat niet, dus op de Multimuis waarschijnlijk ook niet. Ik heb hiermee mijn doel bereikt om de fiddle yard eventueel met meer dan één tablet te kunnen besturen via een X-bus verbinding. Het omzetten van wissels met de muizen is niet essentieel, maar kan indien nodig gewoon plaatsvinden.
Morgen komen Bas en Servé, die beiden ook ideeën hebben over hoe de wissels direct via de X-bus, dus zonder draadloze verbinding, aangestuurd kunnen worden. Ik ben heel benieuwd wat dat op gaat leveren en of de aansturing van de wissels nog beter kan dan met de tablets en de WAMmen. Overigens kunnen wisselstraten ook met de Roco-app in de tablet gezet worden. Ik heb er nu drie samengesteld, nl. twee om alle wissels per hoofdspoor op rechtuit te zetten en één om alle wissels na een heropstart te resetten. Maar het is mogelijk om meer rijpaden te definiëren, bijv. om de fiddle yard te verlaten. Het is mijn bedoeling om  de huidige testopstelling eerst door Bas en Servé te laten besnuffelen, zodat ze weten wat er nu al is.
Om de keerlusbeveiliging van Bas te kunnen testen heb ik alvast een keerlus opgezet:


Leen.