Doel:€250.00
Donaties:€150.00

Per saldo:€-100.00

Steun ons nu!

Laatst bijgewerkt
op 08-12-2019
Algemeen

De stichting

Recente berichten

Knipperlichtschakeling door Klaas Zondervan
Vandaag om 16:16:18
Raadplaatje door BrightonBelle
Vandaag om 16:09:00
Mardec WIDO door eichddraig
Vandaag om 16:00:30
Piko NS1100, materieelbespreking door Klaas Zondervan
Vandaag om 15:54:12
Ostmühle, rangeerbaan in spoor 0 door Hendrik Jan
Vandaag om 15:54:07
Wensendraadje Nederlands 2020 door Luit
Vandaag om 15:42:12
Roco Geoline wissel digitaal gemaakt, werkt niet. door bmwpiet
Vandaag om 15:37:57
TCM Opnieuw beginnen met een modelbaan. door FHJ Seller
Vandaag om 15:21:39
Schwarzburg-Neuffen-Bahn door Ruud K
Vandaag om 15:17:58
Mijn eerste H0-modeltreinbaan in aanbouw door Wim Vink
Vandaag om 14:52:22
Roco NS 200/300 Sik, model 2019 door Bartje81
Vandaag om 14:46:29
Toon hier je nieuwe (model-) spooraanwinst(en)... door Reeks77
Vandaag om 14:34:42
De CanBus komt naar Kranenberg, Arduino's en de CanBus door bask185
Vandaag om 13:52:03
"Litter Bin" voor Brits spoor en Britse modelspoorprojecten door ChristiaanB
Vandaag om 12:57:50
Fleischmann modellgleis wissel in elkaar zetten door Joost O
Vandaag om 12:55:37
Roco 2019 door Sander Fondse
Vandaag om 12:55:23
Peco korte kruising SL-E393F, waar sluit je draden aan? door Klaas Zondervan
Vandaag om 12:33:38
Nedstaal; van sloop tot vrije vertaling H0 door Deetrein
Vandaag om 12:24:52
MB-module: Hielan Ware door Hendrik Jan
Vandaag om 11:54:36
Een klein stukje Scotland door Hendrik Jan
Vandaag om 11:47:07
WLAN maus + Z21 'P' error door Sven
Vandaag om 11:17:27
The R & J Colliery Ltd. 1:76 Brits. door St00mboy
Vandaag om 11:14:41
Update: baan in de tropen door Hans Grasmaijer
Vandaag om 11:12:35
Onlangs gespot - gefotografeerd, de foto's door Erik Mijd
Vandaag om 11:01:08
DDM-1 & DD-AR; de laatste loodjes. Fotodraadje. door Bob R.
Vandaag om 10:24:37
SGM; de laatste loodjes. Fotodraadje. door Bob R.
Vandaag om 09:13:19
Projekt 083-338 door Noordernet
Vandaag om 07:38:31
Geweatherde Challenger, O-schaal, MTH door Ronald Halma
Vandaag om 06:46:31
Mallnitzer Tauernbahnstrecke ÖBB N Spoor door Schachbrett
12 december 2019, 23:01:15
Midland Industriebaan, NS Tijdperk IV, HO. door NS264
12 december 2019, 22:51:59
  

Auteur Topic: De CanBus komt naar Kranenberg, Arduino's en de CanBus  (gelezen 7696 keer)

Robert E

  • Offline Offline
  • Berichten: 835
    • Micro controllers en modelspoor
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #60 Gepost op: 19 november 2019, 22:05:55 »
Citaat
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).

Citaat
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
« Laatst bewerkt op: 19 november 2019, 22:09:07 door Robert E »
MDRRC-II goedkope DIY centrale voor DCC en MM

meino

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #61 Gepost op: 22 november 2019, 20:04:26 »
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
« Laatst bewerkt op: 22 november 2019, 20:06:43 door meino »
A clean desk is a sign of an empty mind

Kranenberg

bask185

  • Offline Offline
  • Berichten: 245
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #62 Gepost op: 22 november 2019, 21:44:59 »
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

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4541
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #63 Gepost op: 25 november 2019, 10:19:02 »
Oei, ja, dat kan je aardig bezig houden :-\ Maar ik moest toch even gniffelen :angel:

Wel een klassiek geval van per ongeluk twee parameters aanpassen tijdens het storingzoeken :-\ Wel heel fijn/goed dat je het probleem gevonden hebt! (y)


Timo
Verzonden vanaf mijn desktop met Firefox

meino

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #64 Gepost op: 01 december 2019, 16:40:51 »
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

A clean desk is a sign of an empty mind

Kranenberg

meino

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #65 Gepost op: 01 december 2019, 18:10:33 »
Laten we eens naar de Arduino schets kijken die het benodigde werk verzet.

/*
  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.

//
//  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.

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.

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
« Laatst bewerkt op: 01 december 2019, 19:40:57 door meino »
A clean desk is a sign of an empty mind

Kranenberg

meino

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #66 Gepost op: 03 december 2019, 18:45:28 »
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.


« Laatst bewerkt op: 03 december 2019, 18:55:10 door meino »
A clean desk is a sign of an empty mind

Kranenberg

bask185

  • Offline Offline
  • Berichten: 245
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #67 Gepost op: 04 december 2019, 08:27:35 »
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

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #68 Gepost op: 04 december 2019, 10:30:40 »
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
« Laatst bewerkt op: 04 december 2019, 10:37:56 door meino. Reden: »
A clean desk is a sign of an empty mind

Kranenberg

bask185

  • Offline Offline
  • Berichten: 245
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #69 Gepost op: 04 december 2019, 11:33:46 »

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  (y)
Citaat
Overigens weet ik niet of jouw idee van signaal versterking gaat werken
Zullen we iig nooit weten, ga het toch niet uitproberen  :P. Differentiaal spanning ftw


meino

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #70 Gepost op: 04 december 2019, 11:40:16 »
OK, tijd voor de Arduino schets.

/*
  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.

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).

//
//  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.

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.

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
« Laatst bewerkt op: 04 december 2019, 11:46:29 door meino »
A clean desk is a sign of an empty mind

Kranenberg

bask185

  • Offline Offline
  • Berichten: 245
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #71 Gepost op: 04 december 2019, 13:26:32 »
CanBus *canBus;
Heeft het gebruik van een pointer is dit scenario nog een specifiek voordeel over het niet gebruiken van een pointer?

meino

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #72 Gepost op: 04 december 2019, 15:49:02 »
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
« Laatst bewerkt op: 04 december 2019, 15:51:03 door meino »
A clean desk is a sign of an empty mind

Kranenberg

Patrick Smout

  • Offline Offline
  • Berichten: 289
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #73 Gepost op: 04 december 2019, 22:29:19 »
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

  • Offline Offline
  • Berichten: 576
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #74 Gepost op: 06 december 2019, 13:32:39 »
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
A clean desk is a sign of an empty mind

Kranenberg