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

[Robert E]

dus pak er een biertje bij

Wijntje ook goed ?

Goed te zien dat Meino verder gaat

Die int en byte, in gcc (wat onderhuids in Arduino zit) kun je denk ik beter gebruik maken van int16_t / uint16_t  en int8_t / uint8_t al die typen.
Maar wie ben ik ......

https://www.gnu.org/software/libc/manual/html_node/Integers.html

Maakt het net iets duidelijker (laat staan de mogelijke ellende als je van een 8 bits (Atmel AVR) geval naar een 32 bits (STM32F1 en hoger bijv) geval gaat).

OpenLCB en LCC, ik heb weer genoeg te lezen

Sluit ik me bij aan...

Alleen nog een bus variant dus ..... Zo is er nog deze

http://bidib.org/

Mvg

Robert

[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