De CanBus komt naar Kranenberg, Arduino's en de CanBus

[meino]

Heb je nog voortgang gemaakt met je baan?

Ik heb even een tussendoortje gedaan, zie https://forum.beneluxspoor.net/index.php?topic=77057.229, een brandweerkazerne.

Maar de meeste tijd de afgelopen week is besteed aan een irritant probleem. Namelijk dat de CanBus zo nu en dan blokkeerde, tenminste daar leek het op. Ik had al uitgezocht dat het waarschijnlijk de DCC_Controller was die stopte. Het probleem was dat het probleem met logging via de seriele monitor niet te traceren was want dan gebeurde het nooit (dat had me toen al aan het denken moeten zetten). Maar na veel knutselen en in bouwen van recovery werkte het redelijk. Van de week, naar aanleiding van de discussies, had ik de bibliotheek omgegooid, met een virtuele class en nog wat interne reorganisaties. Helaas werkte het voor geen meter, de DCC_Controller blokkeerde nu al na 5-10 minuten en soms kwam hij niet op. Dus logging actief maken en kijken wat er gebeurd. Jammer was dat het probleem dan nooit optrad. ?
Dus de logging weer afgezet, en bingo het hing weer. Zaken verandert (ik verdacht dat in de heap, die is slechts 2k groot op een UNO, storage overschreven werd), mallocs en new verandert tot assignments op de stack. Helaas het bleef instabiel. Weer getracht met logging het probleem te tackelen. Maar weer als de logging actief was, geen problemen.
Kortom ik stond op het punt om weer terug te keren naar de oorspronkelijk code. Maar gisteravond toch nog een keer iets veranderen eerst met logging actief, uploaden en draaien.Dat was stabiel, dus logging weer uitgezet en weer testen, he dat is ook stabiel.
Maar toen viel het kwartje. Normaal als ik geupload heb en de logging is niet actief, dan trek ik gelijk de USB kabel los tussen de laptop en de Arduino, dat had ik nu niet gedaan. Dus de kabel los getrokken, en ja binnen 10 minuten blokkeerde de DCC_Controller, USB kabel terug, en hij ging weer lopen. Ok hoe staat het met de 5V voeding? (Ja Timo ik weet wat je nu gaat zeggen, de spullen om naar 12V te gaan zijn in huis maar nog niet aangesloten). Wat bleek de 5V voeding voor de DCC_Controller had ik op de Vin pin aangesloten en niet op een 5V pin. Dus deze Arduino kreeg te weinig spanning om stabiel te zijn en dat was de oorzaak van alle problemen.
Het was niet leuk de afgelopen week, maar ik ben wel blij dat ik nu weet wat de oorzaak was, niets is vervelender dan een probleem waarvan je hoopt dat het opgelost is, maar waar je geen verklaring voor hebt kunnen vinden.

Het is nu weer tijd voor leukere dingen .

Groet Meino

[bask185]

Ik voel je pijn...Ik krijg m'n bluetooth module niet in AT modus desondanks ik alles goed doe.... nu loopt mn DCC centrale vertraging op

[Timo]

Oei, ja, dat kan je aardig bezig houden Maar ik moest toch even gniffelen

Wel een klassiek geval van per ongeluk twee parameters aanpassen tijdens het storingzoeken Wel heel fijn/goed dat je het probleem gevonden hebt!


Timo

[meino]

Het is weer tijd om weer eens verder te gaan met het oorspronkelijke doel van dit draadje, n.l. het gebruik van de Canbus en de verschillende systemen die daarmee verbonden zijn.
Even terug naar het schema:

Ik wil nu de diverse systemen bespreken en ik begin met de DCC Interface.



Dit systeem vertaalt de commando's die de DCC centrale verstuurd naar berichten die op de Canbus gezet worden. Op dit moment worden alleen DCC accessory (voor wissels en seinen) overgezet.
Dus dit systeem heeft naast het TMC2515 kaartje (voor de Canbus) ook een interface voor het DCC gebeuren nodig. Die interface is gebouwd op een stukje stripboard met een Optocoupler.



Het gebruikte schema heb ik ooit van het Internet geplukt.

Dat werkt goed, en door de optocoupler geen risico van opgeblazen inputs (of erger) op de Arduino.

Het complete aansluitschema ziet er dan als volgt uit.


Wordt vervolgd.

Groet Meino

[meino]

Laten we eens naar de Arduino schets kijken die het benodigde werk verzet.

Code: [Selecteer]

/*
  A program to convert DCC commands to Canbus messages

  Copyright (C) Meino, all rights reserved

  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License
  as published by the Free Software Foundation, version 2
  of the License.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

*/

#include <DCC_Decoder.h>
#include <CanBus.h>

//
//  Other pin's used
//
#define DCCPIN     2

//
// Definitions for the DCC interface
//
#define K_DCC_INTERRUPT   0

//
//  The CanBus
//
CanBus *canBus;

We beginnen met een paar zaken zoals de bibliotheken die we gebruiken en de interrupt pin die voor DCC gebruikt wordt.
De bibliotheken die we gebruiken zijn DCC_Decoder (https://github.com/MynaBay/DCC_Decoder), arduino-mcp2515-master (https://github.com/autowp/arduino-mcp2515/archive/master.zip en de KB_CanBus.

Code: [Selecteer]

//
//  DCC Accessory packet handler
//
void DCC_PacketHandler(int address, bool activate, byte data)
{
  //
  //  Convert NMRA packet address to a useable address
  //
  //  This calculation seems to be a little weird. However it has to do with
  //  the way NMRA has implemented these things. Accessory decoders have an
  //  basic address and a sub address.
  //  F.I. decoder address 1 means first decoder (address 1) sub address 0.
  //  Decoder address 2 means first decoder (address 1) sub address 1.
  //  Decoder address 5 means second decoder (address 2), sub address 0, etc.
  //  So the basic decoder address is not a C like index but a counter like in
  //  Cobol, it doesn't start with 0.
  //

  //
  //  Start with the base address
  //
  address -= 1;
  address *= 4;

  //
  //  Add de sub address
  //
  address += 1;
  address += (data & 0x06) >> 1;

  //
  //  Do we perform a normal(-) or a switch(/) operation?
  //  For a normal operation enable is true, for a switch operation
  //  enable is false.
  //
  bool enable = (data & 0x01) ? 1 : 0;
  // This bit actual specifies which of the two coils need
  // to be activated. (or deactivated if activate is false, which is not used
  // by this code)

  DCC_ACC_MSG buf;
  buf.address = address;
  if (enable)
  {
    buf.direction = 0;
  }
  else
  {
    buf.direction = 1;
  }

  //
  //  Send the received accessory command
  //
  canBus->sendMsg(DCC_ACC, sizeof(DCC_ACC_MSG), &buf);
}

Dit is een routine die aangeroepen wordt door de DCC_Decoder bibliotheek wanneer er een compleet wissel/sein (accessory) commando is binnengekomen. Deze routine zal de binnengekomen commando analiseren en omzetten naar een Canbus bericht en dat bericht dan op de zendqueue van de Canbus interface zetten.

Code: [Selecteer]

void setup()
{
  //
  //  Setup and start the CanBus communication
  //
  static const int nrOfBuffers = 7;
  static const int waitTime = 4;
  canBus = new CanBus(DCC_INTERFACE_ID,
                        new Mcp2515(10, waitTime, nrOfBuffers),
                        nullptr); // Only a sender, 250msg/sec, 10 sendbuffers
  canBus->begin();

  //
  //  Setup the DCC packet handler
  //
  DCC.SetBasicAccessoryDecoderPacketHandler(DCC_PacketHandler, true);
  DCC.SetupDecoder(0x00, 0x00, K_DCC_INTERRUPT); 
}

In de setup-routine creeren we de interface naar de Canbus ,alleen een zender en met de mogelijkheid om meer boodschappen per sec. te kunnen verzenden dan standaard mogelijk is. Verder initialiseren we de DCC_Decoder bibliotheek, melden de packethandler aan, en vertellen wat de interrupt pin is.

Code: [Selecteer]

void loop()
{
  //
  //  Check for DCC packets
  //
  DCC.loop();

  //
  //  Activate the CanBus
  //
  canBus->heartBeat(); 
}

In de loop-routine hoeven we nu niet veel meer te doen dan de DCC_Decoder bibliotheek en de Canbus aan de gang te houden zodat binnenkomende DCC berichten aan de packethandler aangeboden kunnen worden en dat de  berichten die op de zendqueue van de Canbus interface staan verzonden worden.

Tot zover de DCC-Interface.

Groet Meino

[meino]

Het volgende systeem is de S88-Interface.



Dit systeem is verantwoordelijk voor het ontvangen en afhandelen van OCC_DT bericht. Gebruikmakend van het adres van de bezetmelder wordt een bezetmelding in het S88 schuifregiaster gezet.

De koppeling tussen de S88 Interface en mijn centrale (MDRRC-II) vind plaats d.m.v. een Cat-5 netwerkkabel. Dat betekend dat de aansluiting voor de kabel op de S88-Interface een RJ45 connector is. De pinlayout hiervan is als volgt.

Ook op de MDRRC-II is dit de pin layout, dus de cat5 kabel moet wel een een-op-een kabel zijn.

Het aansluitschema is dan als volgt.

Zoals te zien is worden niet alle pinnen gebruikt. Omdat de Canbus sytemen hun eigen voeding hebben, wordt bijv. de 12V/5V aanwezig op de S88 aansluiting niet gebruikt. Een andere mogelijkheid is het feit dat meerder S88 systemen aan elkaar verbonden kunnen worden. Dit omdat in het originele S88 ontwerp ieder systeem maar een schuifregister met 16bits hebben. Heb je meer dan 16 detectors, dan moet je meerdere koppelen. Dat probleem heb ik met een Arduino niet, ik kan in de schets het schuifregister zo groot maken als ik zelf wil, dus de mogelijkheid om meerdere S88-interfaces aan elkaar te koppelen ondersteun ik niet (meer).

Wordt vervolgd.

[bask185]

Maak je eigenlijk zelf je terugmeld modules?

Ik ben nu zelf bezig om de terugmelding van 1 van onze clubbanen te ontwerpen. Ik kwam al gauw tot de ontdekking dat de S-88 bus een niet al te beste bus is. Bovendien zijn die standaard terugmeld modules rete duur.

Als ik die s88 bus aanleg moest ik eerst vanaf een CS3 2 meter naar links bekabelen om vervolgens 20+ meter een kabel in de andere kant te trekken. Zelfs met patchkabels zie ik dat somber in. Ik gebruik iig arduino's om de prijs te drukken. Toen kwam ik nog met het idee om elke arduino als een 'node' in stellen waarbij elke node de s88 bus uitleest en zelf de bus naar de volgende klokt om zo het signaal te 'boosten'.

Dit idee kreeg ik laatst toen ik met werk een excursie/workshop had bij Beckhoff. Zij hebben de ethercat bus ontwikkeld, de beste veldbus ooit. Bij deze bus wordt doet een master een lange golf informatie op de bus zetten en elke slave leest dit signaal in bit voor bit en klokt de bits zelf weer uit naar de volgende. Daarbij kan een slave zelf de data bits zetten of uitlezen on the fly.

Maar toen dacht ik dat het nog simpeler kan. Ik wil nu elke arduino iets van 32 bezetmelders geven en met de rs485 bus wil ik informatie doorsluizen naar de arduino die 5cm voor de Cs3 ligt. Die kan dan via de S88 bus alle bezetmelder informatie in de Cs3 stoppen.

Vind je het niet fijner om je arduino's zelf te terugmelding laten doen? Ik weet niet wat voor terugmeld modules je precies gebruikt?

[meino]

Ik heb een aantal verschillende typen detectors in gebruik. Ik ben lid geworden van https://www.merg.org.uk/ voor de kits. In dit geval ging het om de DTC8/DTC2 en PMP7 detectors. Verder heb ik twee z.g. Ali lichtsluisjes gebruikt. Dat zijn gemodificeerde infrarood benadering detectors. Deze detectors hangen allemaal aan diverse arduino's die hun staat via de Canbus door geven aan de S88 Interface. Dit zijn de Bezetmelder controllers, waar ik het later nog over zal hebben. Over de schets voor de S88 Interface, die had oorspronkelijk de mogelijkheid om meerdere van deze S88 arduino's in een daisy chain te hangen, waarbij de S88 arduino's ook de detectors zou bewaken. Dat concept heb ik verlaten en vervangen door het huidige concept waarbij de verantwoordelijkheid voor de Detector bewaking afgesplitst is naar aparte arduino's.

Overigens weet ik niet of jouw idee van signaal versterking gaat werken, de signalen die je zou moeten versterken zijn de CLOCK en de PS signalen. die zijn best tijdskritisch. Ik denk dat 1 tussenstap nog wel zal gaan, maar ik denk dat meerdere stappen een probleem wordt. Maar omdat ik nu in de S88 Interface meer dan 16 bits kan nabootsen, hoef ik geen daisy chain te maken en beperk ik de S88 connectie tot 1 korte Cat5 netwerk kabel.

Groet Meino

[bask185]

Ah ik vat em. Ik dacht eerst dat je een wat langere s88 bus met echte S88 terugmeldmodules in gebruik heb. Maar als ik het nu wel goed snap, loopt de blauwe s88 bus op het schema slechts tussen 1 arduino en de centrale? En dan heb je meerdere arduino's die spoor bezet statussen doorgeven aan de interface arduino via de can bus? Dan denken we toch hezelfde 

Overigens weet ik niet of jouw idee van signaal versterking gaat werken

Zullen we iig nooit weten, ga het toch niet uitproberen  . Differentiaal spanning ftw

[meino]

OK, tijd voor de Arduino schets.

Code: [Selecteer]

/*
  A program to accept occupancy detector status from the Canbus
  and set the proper bit in the S88 shift register

  Copyright (C) Meino de Graaf, all rights reserved

  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License
  as published by the Free Software Foundation, version 2
  of the License.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  email: meino@innerside.demon.nl
*/
#include <CanBus.h>

//
//  Pin layout is for the Arduino Uno
//

// Connections for S88 bus:
//
// s88 pin 1 Data - Arduino pin 8 = Data_Out to Oommand Station, or pin 7 (Data in) from the next Arduino in the chain
// s88 pin 2 GND  - Arduino GND
// s88 pin 3 Clock - Arduino pin 2, interrupt 0
// s88 pin 4 PS - Arduino pin 3, interrupt 1
// S88 pin 5 Reset (not used)
// s88 pin 6 V+ - Arduino 5V (not used)
//

// Connections for S88N (RJ45)
//
// RJ45 pin 1 12V/5V   (not used)
// RJ45 pin 2 DATA  - Arduino pin 8 Data_Out to Oommand Station, or pin 7 Data In from the next Arduino in the chain
// RJ45 pin 3 GND   - Arduino GND
// RJ45 pin 4 CLOCK - Arduino pin 2, interrupt 0
// RJ45 pin 5 GND   - Arduino GND
// RJ45 pin 6 PS    - Arduino pin 3, interrupt 1
// RJ45 pin 7 RESET    (not used)
// RJ45 pin 8 RAILDATA (not used)
//


#define S88_DATAOUT_PIN     8
#define S88_DATAIN_PIN      7
#define S88_CLOCK_PIN       2
#define S88_PS_PIN          3

#define S88_CLOCK_INTERRUPT 0
#define S88_PS_INTERRUPT    1

const int nrOfOccDetectors = 6 * 16;

volatile byte pendingStates[nrOfOccDetectors];
volatile byte dataRegister[nrOfOccDetectors];

volatile long clockTicks = 0;

CanBus *canBus;
Hier zijn een aantal zaken gedefinieerd die in de schets gebruikt worden. De KB_canbus bibliotheek (CanBus.h), pin definities voor de gebruikte pinnen en verder twee byte arrays die de (pseudo) schuifregisters vormen. De grootte van deze (pseudo) schuifregisters is variabel en moet tenminste zo groot zijn als wat gedefinieerd is in de DCC centrale.
In de bytearray pendingStates wordt de staat van een specifieke detector bijgehouden (0 is vrij, 1 is bezet). De bytearray dataRegister bevat een copie van pendingStates, en levert de informatie voor de S88. De werking is vrij simpel, op het moment dat het PS signaal binnen komt, wordt de inhoud van pendigStates gecopieerd naar dataRegister en wordt de clock index terug gezet op 0. Bij iedere activering van het CLOCK signaal, word de DATA pin gezet aan de hand van de inhoud van de byte uit dataRegister waar de clock index naar verwijst, gevolgd door een ophoging van de clock index naar de volgende byte.

Code: [Selecteer]

void PS_Int()
{
  //
  //  Load the detector states in the data register
  //
  memcpy(dataRegister,pendingStates,nrOfOccDetectors);

  clockTicks = 0;     //  reset index in the dataRegister
}

//
//  Set the state of the next detector on the output pin
//
void clock_Int()
{
  digitalWrite(S88_DATAOUT_PIN, dataRegister[clockTicks]);
  //
  //  If we are chained to additional detectors, reads a bit from the chain and
  //  store it in the current, just written, position
  //

  //
  //  Delay makes reading output signal from next Arduino in chain more reliable.
  //
  //delayMicroseconds(2);
  //dataRegister[clockTicks]=digitalRead(S88_DATAIN_PIN);
 
  clockTicks = (++clockTicks) % nrOfOccDetectors; // Goto next bit in dataRegister
}

Dat wordt gedaan door deze twee interupt routines, die gekoppeld zijn aan pin 2 en 3 (op een Arduino UNO).

Code: [Selecteer]

//
//  A function that executes whenever a message is received from the Canbus
//  It's purpose is to analyze the received event Occupancy detector and
//  update the proper element in the semaphore table or turnout table.
//
void occDtReceiver(unsigned char aMsgLen, OCC_DT_MSG *msgData)
{
  if (msgData->address < nrOfOccDetectors)
  { 
    pendingStates[msgData->address] = msgData->state;
  }
}

De pendingStates byte array wordt gevoed door de berichten die van de Bezetmelder controllers (en wissel controllers) versturen. Dat geveurd in de bovenstaande interrupt routine. Het is de verantwoordelijkheid van de Bezetmelder controller om te weten welk bit/byte in de arrays te zetten. Dus de Bezetmelder controllers hebben kennis van de bezetmelder adressen in de S88 registers, zoals dat door de Centrale en het treinbesturings programma gebruikt wordt.

Code: [Selecteer]

void setup()
{
  //
  //  Intialize the dataRegister
  //
  memset(pendingStates,0,nrOfOccDetectors);
  memset(dataRegister,0,nrOfOccDetectors);

  //
  //  Setup the input/output pins and the interrupts for the S88 communication
  //
 
  //pinMode(S88_CLOCK_PIN, INPUT_PULLUP);
  //pinMode(S88_PS_PIN, INPUT_PULLUP);
 
  pinMode(S88_DATAIN_PIN, INPUT_PULLUP);
  pinMode(S88_DATAOUT_PIN, OUTPUT);
  digitalWrite(S88_DATAOUT_PIN, LOW);
 
  attachInterrupt(S88_CLOCK_INTERRUPT, clock_Int, RISING);
  attachInterrupt(S88_PS_INTERRUPT, PS_Int, RISING);

  //
  //  Setup and start the CanBus communication
  //
  canBus = new CanBus(S88_INTERFACE_ID, nullptr, new Mcp2515(10)); // Only a receiver
  canBus->setMsgReceiver(OCC_DT, occDtReceiver);
  canBus->begin();
}

De setup routine waarin het een en ander wordt klaargezet.

Code: [Selecteer]

void loop()
{
  //
  //  Are there messages on the CanBus?
  //
  canBus->heartBeat();
}

In de loop functie wordt alleen de Canbus aan de gang gehouden. De S88 bus draait volledig op de interrupts die binnenkomen via de PS en CLOCK signalen.

Tot zover de S88 Interface.

Groet Meino

[bask185]

Code: [Selecteer]

CanBus *canBus;


Heeft het gebruik van een pointer is dit scenario nog een specifiek voordeel over het niet gebruiken van een pointer?

[meino]

Dat hangt er vanaf. Daar heb ik met Timo ook al een uitgebreide discussie over gehad. Laten we het houden op een persoonlijke voorkeur om objecten zoveel mogelijk d.m.v. van pointers te refereren. Pointers kunnen als parameters aan methods door gegeven worden, de physieke objecten niet. Die voorkeur heb ik van Java overgehouden, daar heb ik veel meer ervaring in dan C++ en daar is alles "By Reference", lees pointers. Daardoor hoef ik me in de code niet af te vragen of ik een -> of een . moet gebruiken.

Groet Meino

[Patrick Smout]

Even ter zijde maar bij EtherCat is het de 32 bit crc foutcontrole in het frame die ervoor zorgt dat een verdwaalde clockpuls geen onaangename gevolgen heeft. Een S88 bus heeft geen foutcontrole en daar wringt het schoentje. Als elke s88 melder een 4 of 8 bit Crc achter de data zou plakken en dus 20 of 24 bit zou doorschuiven dan zou dit een prima foutongevoelige bus zijn. De andere oplossingen maken allen gebruik van foutcontrole en zo hoort het ook.

Mvg

Patrck

[meino]

Laten we weer eens verder gaan. Het volgende systeem waar ik het over wil hebben is de Bezetmelder Controller. Dit systeem houdt een of meerdere bezetmelders in de gaten en geeft hun status (vrij of bezet) door aan de S88 Interface. Maar voor ik daarmee begin wil ik eerst het eens hebben over de bezetmelders zelf.
Ik heb momenteel drie verschillende typen in gebruik.

• DTC8/DTC2 Dit is een stroomdetector die werkt met een resonantie kring. Deze heeft een aantal voordelen. De detector schakeling is galvanisch gescheiden van de rijstroom en er ontstaat geen spanningsverlies op de DCC spanning. De detector wordt apart gevoed via een eigen voeding (5V-12V). Dit betekend ook dat de de bezetmelder slechts via een railstaaf wordt aangesloten op de detectiesectie.
  Het signaal is digitaal, dus bij bezet is de pin 0V maar bij niet bezet wordt de bezetmelderpin op 5V gehouden. Hij is erg gevoelig, een losse wagon met asjes met weerstandlak wordt altijd gedetecteerd. Verder geen last van spikes (spookmeldingen) en bij het verlaten van de sectie wordt de bezetmelding nog ongeveer een seconde vast gehouden voordat de melder naar vrij gaat. Zie verder https://www.merg.org.uk/merg_resources/dcc.php
  
• PMP7 Ook een kit van de MERG. Dit is een stroomdetector gebaseerd op een diode schakeling. De schakeling wordt gevoed via de DCC rijstroom, dat betekend dat voor de bezetmelder sectie beide railstaven onderbroken moeten worden en via de schakeling gevoed worden. Verder hebben deze soms last van spookmeldingen, het lijkt op bounce in een mechanische schakeling, dus dat moet ik in de software uitfilteren. Volgens de documentatie zou ook deze melder de bezetmelding wat langer moeten vasthouden, maar dat is afhankelijk van weerstandjes in de schakeling en de voedingspanning en daardoor heb ik niet goed kunnen bepalen hoe lang deze periode is.
• Ali lichtsluis  Dit is een gemodificeerde Arduino benaderingsensor die werkt met een infrarood straler en ontvanger. De modificatie bestaat er uit dat deze losgemaakt worden van het kaartje en op de baan tegen over elkaar geplaatst worden. Voordeel is, dat er geen onderbrekingen in de rails worden aangebracht. Dus geen koppeling met de rijstroom. Nadeel is dat ze gevoelig zijn voor omgevings licht, waardoor ze eigenlijk alleen bruikbaar zijn in tunnels of andere verduisterde plekken (schaduwstations) op de baan. Een ander nadeel is dat ze direct reageren op het onderbreken van het licht, dus ook op de gaten die tussen de wagons aanwezig zijn. Door een slimme plaatsing (schuin) kan dat verminderd worden. Ook moet je goed opletten als er meerdere rijbanen parallel lopen dat de lichtsluisjes elkaar niet onderling zien.

Het is duidelijk dat iedere bezetmelder schakeling zijn eigen aansturing nodig heeft.
Bij de DTC8/DTC2 moet de pin in INPUT staan en bezet is LOW, verder geen extra voorzieningen om spookmeldingen/spikes op te vangen.
Voor de PMP7 moet de pin in INPUT_PULLUP staan en bezet is ook LOW. Echter voor deze bezetmelder moet de software korte veranderingen uitfilteren.
Voor de lichtsluis moet de pin ook in INPUT_PULLUP staan, maar de waarde voor bezet is nu HIGH (de lichtstraal wordt onderbroken, dus de benadering sensor triggered niet). Verder omdat deze melder direct uit slaat (tussen wagons) moet er een wachtijd ingebouwd zijn als de melder van bezet naar vrij gaat.

Daarom heb ik een kleine bibliotheek gemaakt waarin ieder type bezetmelder door zijn eigen klasse vertegenwoordigd is.

Wordt vervolgd

Groet Meino

[meino]

Ik heb dus voor het gemak een kleine bibliotheek gemaakt voor die klassen die met de verschillende detectors kunnen omgaan.
Ik zal dat bespreken aan de hand van de het KB-Bezetmelder.h bestandje. Als iemand de code wil hebben, stuur me een PB dan stuur ik wel een zip bestandje met de bibliotheek.

Code: [Selecteer]

//
//  Type definition for the call back routine which will handle a state change
//
typedef void (*stateHandler_t)(byte s88Bank, byte s88Id, bool occupiedState);

Omdat ik de definities van de detector klassen zo schoon mogelijk wilde houden. bevat deze geen specifieke (Canbus) code hoe een bezetmelding afgehandeld wordt. De stateHandler is en externe interrupt routine die je bij het detector object registreerd en door hem wordt aangeroepen als het detector object dat nodig vindt. Deze typedef definieert het prototype van deze routine. In mijn geval is het deze routine die de bezetmelder staat omzet naar een Canbus bericht en dat verstuurd.

Code: [Selecteer]

class Detector
{
protected:
    short pin;              // Digital pin in use by Detector
    int  occupiedValue;     // Value of the digitalRead() when the detector
                            // is occupied
    int  occupiedPinMode;   // value set by pinMode() during attach
   
    bool occupied;          // true is occupied, false is free
   
    char *description;      // Just a description, used for debugging
    byte s88Bank;           // The S88 bank (containg 16 detectors)
    byte s88Id;             // The number of the detector in the S88 bank
   
    //
    //  A number of timer values (in mS) used while switching from
    //  free to occupied or switching from occupied to free
    //
    short waitTimeOn;
    short waitTimeOff;
    long pendingTime;
    bool pendingState;
   
    long timeOfLastMessageSend; // Last time the state handler was invoked

    stateHandler_t stateHandler; // An external interrupt routine that handles
                                 // a state switch of the detector

    //
    //  Default functionality, common for most of the detector classes.
    //
   
    //
    //  Initial setup of the class.
    //
    void init(char *aDescription, short aPin, byte aS88Bank, byte aS88Id);
   
    //
    //  The basic standard heartbeat method, reponsible for monitoring the
    //  detector and invoking the state handler when a state changed.
    //
    void doHeartBeat();
   
    //
    //  The basic attach functionality, responsible for setting up the
    //  digital pin in use by a detector.
    //
    void doAttach();
   
public:
    //
    //  Register the external state handler, respomsible for the proper handling
    //  of a detector state change.
    //
    void registerStateHandler(stateHandler_t aStateHandler);

    virtual void heartBeat() = 0;
    virtual void attach() = 0;
};

Dit is de abstracte base class waarvan alle detector klassen afgeleid zijn. Hij bevat zoveel mogelijk de standaard functionaliteit. Zoals init(..), doAttach(..) en doHeartBeat(..). De init(..) initialiseerd de gemeenschappelijke eigenschappen van de base class, doAttach(..) activeerd de pin waar de detector aanhangt en doHeartBeat(..) verzorgt de standaard monitoring van de pin.
De registerStateHandler(..) registreerd in het object wat de interrupt routine is die door doHeartBeat(..) aangeroepen wordt als de staat van de bezetmelder wijzig, doHeartBeat(..) roept deze routine ook verder nog iedere seconde opnieuw aan, als herinnering van de huidige staat van een bezetmelder.
De twee virtuele methods attach(..) en heartBeat(..) moeten physiek door de afgeleide klassen worden geimplementeerd. Op dit moment roepen ze in de afgeleide klassen alleen de doAttach en doHeartBeat aan, maar het biedt de mogelijkheid on afwijkende strategien te implementeren.
Dit is een abstracte klas omdat hij geen constructor bevat, en kan dus niet zelfstandig geconstrueerd worden, dat kan alleen maar door de afgeleide klassen, die zetten n.l. nog een paar andere eigenschappen die nodig zijn voor de correcte werking.

Code: [Selecteer]

//
// A Class that handles the MERG DTC8/DTC2 detector. See www.merg.org.uk
//
// it uses the following settings:
//  PinMode INPUT
//  pinValue for occupancy LOW
//  waitTimeOn 0
//  waitTimeOff 0
//
class DTC8 : public Detector
{
public:
    DTC8(char *aDescription, short aPin, byte aS88Bank, byte aS88Id);
   
    void heartBeat();
    void attach();
};

//
// A Class that handles the MERG PMP7 (Piocket money project) detector.
// See www.merg.org.uk
//
// it uses the following settings:
//  PinMode INPUT_PULLUP
//  pinValue for occupancy LOW
//  waitTimeOn 15mS       to counteract bounce behavior
//  waitTimeOff 15ms      to counteract bounce behavior
//
class PMP7 : public Detector
{
public:
    PMP7(char *aDescription, short aPin, byte aS88Bank, byte aS88Id);
       
    void heartBeat();
    void attach();
};

//
// A Class that handles a modified Arduino infrared sensor detector.
//
// it uses the following settings:
//  PinMode INPUT_PULLUP
//  pinValue for occupancy HIGH
//  waitTimeOn 5mS       
//  waitTimeOff 2000ms    to counteract short interrupts caused by the wagons
//
class LS : public Detector
{
public:
    LS(char *aDescription, short aPin, byte aS88Bank, byte aS88Id);
   
    void heartBeat();
    void attach();
};
Dit zijn de definities voor de drie afgeleide klassen die ik gebruik voor de physieke detectors. Iedere klas zet nog vier andere eigenschappen die toegespitst zijn op de specifieke physieke detector, Zie het commentaar in de kode.

Groet Meino