Doel:€250.00
Donaties:€128.00

Per saldo:€-122.00

Steun ons nu!

Laatst bijgewerkt
op 16-04-2024

Vacature: secretaris bestuur
Algemeen

De stichting

Recente berichten

Keerlusmodule Digikeijs DR5013 gaat na willekeurig aantal rondes op kortsluiting door San-Markos
Vandaag om 22:53:29
Nederland jaren 50 op basis van mijn roots door defender
Vandaag om 22:52:55
Kleine Baan in H0 (≤ 0.5m²) door Jack Black (NS1220)
Vandaag om 22:38:39
Traintastic - modelbaan besturingssoftware (gratis en open source) door bask185
Vandaag om 22:27:47
Hengelo in 1981-1982, maar dan anders: Kassenberg in N door raymond erdtsieck
Vandaag om 22:23:17
Laag-Baarlo door Benelux795
Vandaag om 22:22:31
Haandrecht materieel door gdh
Vandaag om 22:03:53
Een stukje Odsherreds Jernbane (OHJ) door gdh
Vandaag om 21:51:42
US diorama in H0 door Wim Vink
Vandaag om 21:38:59
EifelBurgenBahn door Reinout van Rees
Vandaag om 21:19:22
IC-trein naar Berlijn in model, welke rijtuigen? door Michiel 80
Vandaag om 20:49:29
Toon hier je nieuwe (model-) spooraanwinst(en)... door johanw
Vandaag om 20:31:36
Einde Koemo ballast ??? door Ronald Halma
Vandaag om 20:17:56
La Fabrique (1:87, 0,16m2) door tothebeach
Vandaag om 20:02:10
Cranicher Altbahn door Arjen52
Vandaag om 19:47:50
BMB 00-Modulebaan, BMB-Rijdagen en BMB-Deelname aan Beurzen & Evenementen door Hans van de Burgt
Vandaag om 19:41:34
Decals voor een Roco 64892 DSG Speisewagen door grossraumwagen
Vandaag om 19:37:41
Van Biervliet/B Models 2019, nieuws van de fabrikant door Sicco Dierdorp
Vandaag om 18:55:04
Aachenau West door MichielB
Vandaag om 18:48:39
Jeugdsentiment (show je oude treintjes) door thonis
Vandaag om 18:36:00
Openen Lima Hondekop door Mispoes
Vandaag om 17:59:32
Ronald en Wanda's "Southern Comfort" swamp layout! door Ben
Vandaag om 17:53:38
LS Models 2024 door Daan!
Vandaag om 16:34:44
Piko 2200 (52686)+ uhlenbrock 76420(?) door Ben
Vandaag om 16:14:12
Mallnitzer Tauernbahnstrecke ÖBB N Spoor door Schachbrett
Vandaag om 15:56:35
Onlangs gespot - gefotografeerd, de foto's door dh3201
Vandaag om 15:30:48
ACME 2024 met NS ICNG! door Daan!
Vandaag om 14:09:36
"Nederlandse" modellen door ArjanB
Vandaag om 14:07:20
Stationsplein Baden Baden door Dion
Vandaag om 10:52:24
Oude metalen trafo's gebruiken....... door Klaas Zondervan
Vandaag om 10:02:44
  

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

meino

  • Offline Offline
  • Berichten: 2098
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #120 Gepost op: 07 mei 2020, 22:24:13 »
Ok nadat we elkaar de les gelezen hebben ;D is het weer tijd om verder te gaan. Zoals beloofd is, zou ik ook het systeem dat het bel geluid produceert nog proberen uit te leggen.

Ik had een tijdje geleden een Arduino Nano en een versterkerkaartje (PAM8403) aangeschaft, dat voor een ander projectje. Maar die kon ik hier ook mooi voor gebruiken. De meeste voorbeelden die ik op het internet kon vinden werken echter met geluidsfragmenten die op een SD kaartje staan en maken gebruik van een bibliotheek die dat regelt, dat wilde ik nou net niet. Mijn idee was om de wav-data als byte array in het geheugen op te slaan.

Gelukkig kwam ik de volgende site tegen http://wiki.openmusiclabs.com/wiki/PWMDAC. Waar uitgebreid beschreven wordt hoe je een geluidsbron gekoppeld aan een analoge pin, weer kunt afspelen op 2 PWM pinnen via een ISR voor timer1. Dat was precies wat ik zocht. De beschrijving is inclusief een RC netwerkje (R 3,9K, C 47nF) dat nodig is tussen de Arduino en de versterker. Dus dat in elkaar gezet samen met een 5cm luidsprekertje, gesloopt uit een reclame ding van een grote bierbrouwerij.

dat ziet er nu als volgt uit.



De versterkerkaart is via het RC netwerkje aangesloten op pin 9 van de NANO, pin 10 gebruik ik niet omdat ik wav bestandjes van 16kHz en 8 bit gebruik. De Arduino schets van deze openmusiclabs site heb ik gemodificeerd (alles er uitgesloopt wat ik niet gebruik) voor mijn toepassing.

dat leverde uiteindelijk dus de volgende Arduino schets op.
AKI_Bel
#include <avr/pgmspace.h>

const PROGMEM byte wav_0[3936] = {
  0x80, 0x82,
...........
  0x78, 128
};

const PROGMEM byte wav_1[3934] = {
  0x79, 0x76,
..........
  0x79, 128
};

const PROGMEM byte wav_2[3932] = {
  0x82, 0x87,
..........
  0x79, 128
};

const PROGMEM byte wav_3[3934] = {
  0x80, 0x85,
.........
  0x73, 128
};

const PROGMEM byte wav_4[3946] = {
  0x7f, 0x8a,
..........
  0x75, 128
};

const PROGMEM byte wav_5[3955] = {
  0x6e, 0x60,
.........
  0x81, 128
};

//
// options table at http://wiki.openmusiclabs.com/wiki/PWMDAC
//
// Timer1 PWM.  9b, Phase Correct, 15.6kHz, single pin
// The WAV samples are 8it, 16kHz,
//
#define PWM_FREQ 0x01FF   // pwm frequency - see table, 0x01FF is 15.6kHz
#define PWM_MODE 0        // Fast (1) or Phase Correct (0)
#define PWM_QTY 1         // number of pwms, either 1 or 2
#define PWM_SHIFT 1       // 15.6kHz and 1 pin gives 9bit resolution, so shift the sample 1 bit left

#define WAV_VOLUME 20
#define BEL_PIN 2

void setup()
{
  cli();  // turnoff interrupts

  // setup PWM
  TCCR1A = 0;
  TCCR1B = 0;
  TCCR1A = (((PWM_QTY - 1) << 5) | 0x80 | (PWM_MODE << 1)); //
  TCCR1B = ((PWM_MODE << 3) | 0x11); // ck/1
  TIMSK1 = 0x20; // interrupt on capture interrupt
  ICR1H = (PWM_FREQ >> 8);
  ICR1L = (PWM_FREQ & 0xff);
  DDRB |= ((PWM_QTY << 1) | 0x02); // turn on outputs

  sei(); // turn on interrupts

  // Setup the bell activation pin
  pinMode(BEL_PIN, INPUT);
}

//
//  When the bell has to ring, set this on
//
volatile bool bellRinging = false;

void loop() {
  if (digitalRead(BEL_PIN) == HIGH)
  {
    bellRinging = true;
  }
  else
  {
    bellRinging = false;
  }
}

//
// Some state data for the ISR
// Some state data for getNextSoundSample with their initial values.
//
int debugCnt = 0;
unsigned int wavValue = 128; // start at the zero point of the sound
int wavByteIndex = 0;

int wavTableSize = 3935;
byte *wavTable = wav_0;

ISR(TIMER1_CAPT_vect)
{
  //
  //  If at the begin of the sound sample, the sound toggle is of,
  //  return immediate, so no bell is ringing
  //
  if ((wavByteIndex == 0) && (!bellRinging))
  {
    wavTableSize = 3935;
    wavTable = wav_0;
    return;
  }

  // output high byte on OC1A
  OCR1AH = wavValue >> 8; // takes top 8 bits
  OCR1AL = wavValue;      // takes bottom 8 bits

  wavValue = (getNextSoundSample() * WAV_VOLUME) / 100;
}

unsigned int getNextSoundSample()
{
  unsigned int sample = (pgm_read_byte_near(wavTable + wavByteIndex)) << PWM_SHIFT;

  if (++wavByteIndex >= wavTableSize)
  {
    //
    // Restart the table
    //
    wavByteIndex = 0;
    switch (random(0, 6))
    {
      case 0:
        wavTableSize = 3935;
        wavTable = wav_0;
        break;

      case 1:
        wavTableSize = 3933;
        wavTable = wav_1;
        break;

      case 2:
        wavTableSize = 3931;
        wavTable = wav_2;
        break;

      case 3:
        wavTableSize = 3933;
        wavTable = wav_3;
        break;

      case 4:
        wavTableSize = 3945;
        wavTable = wav_4;
        break;

      case 5:
        wavTableSize = 3954;
        wavTable = wav_5;
        break;

      default:
        wavTableSize = 3935;
        wavTable = wav_0;
        break;
    }
  }

  return sample;
}

Dit is puur C code, niks OO en eerlijk gejat onder het motto "Beter goed gestolen dan slecht gecomponeerd".  Overigens heb ik op de site van openmusiclabs nergens iets kunnen vinden over licencies, dus ga ik er van uit dat dit voorbeeld vrijelijk gebruikt kan worden :angel:

De grootste horde die ik moest nemen was, hoe krijg ik de byte arrays in het programma geheugen en niet op de stack (want die is maar 2kb groot). Het benoemen van de arrays tot const werkte niet. Gelukkig bleek er een andere qualifier te zijn, PROGMEM met bijbehorende include file, die de compiler vertelt dat deze data niet op de stack moet, maar in de instructieruimte geplaatst moet worden (die is op de NANO 30kb). Helaas liep ik daarna in een mooie RTFM situatie, wat me twee dagen puzzelen opleverde waarbij het geheel wel een puike hoeveelheid herrie opleverde, maar niet het geluid dat ik verwachte. Nadat ik met wat andere voorbeelden, zoals Tone en sinus generaties wel keurige toontjes produceerde, toch maar eens naar de include file en op internet gekeken. Toen bleek dat de array data niet direct benaderbaar is, maar dat daar speciale functies voor gebruikt moeten worden. Na aanpassing kreeg ik keurig het bel geluid.

In eerste instantie speelde ik steeds het zelfde wav bestandje af. Dat klonk aardig maar ook erg monotoon, als je het echte ding hoort, dan zit er toch variatie tussen de verschillende belslagen. Dus heb ik meerdere verschillende belslagen omgezet tot een wav bestand en dat opgenomen. Ik heb nu 6 verschillende byte arrays in de schets, die ik daarna in een willekeurige volgorde afspeel. Dit gebeurt zolang pin 2 hoog gehouden wordt. Is die laag, dan is dit systeem stil. Deze pin is verbonden met een pin op het AKI systeem, die daarmee de bel kan laten horen wanneer de AKI de overweg sluit.

De belslagen heb ik gehaald uit een mp3 bestand dat ik hier op het forum vond in het volgende draadje https://forum.beneluxspoor.net/index.php?topic=19817.0.
Met behulp van Wavpad van NCH heb ik hier de belslagen uitgeknipt en gesaved als een 16kHz, 8 bit, ongecomprimeerd, mono wav bestand. Daarna heb ik met een Java programmaatje (met methods van AudioSystem) de 8bit muziekstream omgezet naar een tekst bestand, dat ik als byte array in de Arduino schets kon opnemen. Het enige waar ik op gelet heb is dat ieder belslag ongeveer 240mSec lang was en dat er geen grote verschillen in de onderlinge lengte zijn, omdat dat niet goed klonk.

In het code voorbeeld ontbreekt de wav data, als iemand de complete code wil hebben, stuur me een PB dan wil ik de complete code wel naar iemands prive mail sturen. De volledige code is te groot om hier te kunnen publiceren.

Dat was het voorlopig weer.

Groet Meino




A clean desk is a sign of an empty mind

Kranenberg
De CanBus komt naar Kranenberg

bask185

  • Offline Offline
  • Berichten: 4050
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #121 Gepost op: 07 mei 2020, 22:26:15 »
met uintX_t bedoelde ik dus uint8_t, uint16_t etc :police: maar ik had geen zin om telkens die hele rijtjes te tikken  :P en ik dacht dat het wel duidelijk was. I was wrong.
Citaat
Maar ik vind de overzichtelijkheid en helderheid van de code belangrijker dan het besparen van 8 bits.
precies daarom noemde ik dus de int8_t en uint16_t notaties. :D  Ja en wat ik tegen de bool heb. De bool heeft in mijn ogen geen voordeel op een uint8_t. Zo had ik dus een slechte dag toen ik een derde state wilde invoeren en was vergeten dat ik een bool had gebruikt. 1 slechte ervaring is all it takes.

Ik had vandaag wat research gedaan en je kan idd constantes meegeven aan een constructor. Dat wist ik eerst niet. Ik dacht namelijk dat het lastig was als je 2 dezelfde type objecten maakt die elk een verschillende constante nodig hebben. En dat je om die reden een variabele had gebruikt. Zoals je programma nu is, gebruik je 2 bytes aan onnodig geheugen om een constante waarde te gebruiken. Maar aan de andere hand, je kan hem zo wel nog achteraf beinvloeden, zou je dat ooit willen. Maar ik snap dat bedoeld is.

Waar ik dus in SW op doelde was:
class   BlinkingLed {
private:
    const byte   blPin;
    const unsigned short blinkInterval;
    bool  blinking;
    bool  ledOn;
    unsigned long  lastTime;

public:
    BlinkingLed(byte pin, unsigned short interval)
       : blPin(pin), blinkInterval(interval)  {}
Je kan zo dus de compiler vertellen dat hij met constantes te maken heeft voor de objecten. Dit zou dus hetzelfde doen, met minder geheugen mits je ze ook wilt dat het constantes zijn. Dit leerde ik dus vandaag  :police:

Die 3 termen van je moet ik eens opzoeken. Geen idee wat het is. Ik weet wel dat ik in de wonderlijke assembly wereld op werk soms bijzonder van streek wordt gemaakt door de meest verschrikkelijke "abominations" dat zij daar software noemen.

Back to buisness:
Als in koploper een trein van punt A naar punt B laat rijden en hij komt halverwege een bepaalde melder tegen kan je dan een instructie voor een soort overweg ding aansturen? Je kan natuurlijk seinstanden en wisselstanden kan opsturen, maar onbekend als ik ben met koploper, weet ik niet of je zo ook een overgang kan dichtgooien. Hoe ga je dat aanpakken?

Wat wel interessant is, is dat je arduino informatie kan ontvangen over de wisselstanden. Daar moet je toch zeker mee kunnen werken?

mvg

Bas
Train-Science.com
Train-Science github
It ain't rocket science ;-)

meino

  • Offline Offline
  • Berichten: 2098
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #122 Gepost op: 07 mei 2020, 23:37:11 »
Die 3 termen van je moet ik eens opzoeken. Geen idee wat het is. Ik weet wel dat ik in de wonderlijke assembly wereld op werk soms bijzonder van streek wordt gemaakt door de meest verschrikkelijke "abominations" dat zij daar software noemen.
Dat is heel spijtig, want IMHO vind ik dat dit tot de geestelijke bagage van iedereen die (semi)beroepsmatig software ontwikkelt zou moeten behoren. Dus deze begrippen zijn nooit op je opleiding behandeld? Overigens zijn dit al heel oude begrippen.

Als in koploper een trein van punt A naar punt B laat rijden en hij komt halverwege een bepaalde melder tegen kan je dan een instructie voor een soort overweg ding aansturen? Je kan natuurlijk seinstanden en wisselstanden kan opsturen, maar onbekend als ik ben met koploper, weet ik niet of je zo ook een overgang kan dichtgooien. Hoe ga je dat aanpakken?

Wat wel interessant is, is dat je arduino informatie kan ontvangen over de wisselstanden. Daar moet je toch zeker mee kunnen werken?
Koploper kan inderdaad een instructie sturen naar een accessory decoder als een specifieke loc een blok binnengaat. Maar daar maak ik geen gebruik van. De titel van dit draadje geeft al aan hoe ik werk. Alle status wijzigingen van alle bezetmelders worden op de CanBus gepubliceerd, en kunnen door ieder systeem opgepikt worden. Uiteindelijk worden ze dan door een systeem (de S88_Interface) via de centrale naar Koploper gestuurd. Ook alle wisselopdrachten worden op de CanBus gepubliceerd en kunnen ook door ieder aangesloten systeem gelezen worden. Kortom elk systeem dat met de CanBus verbonden is, is in staat om alle wisselstanden en de status van alle bezetmelders te kennen. Verder heb ik de AKI software op de SeinController gezet, die houdt al de standen van de wissels bij omdat die nodig zijn om het juiste seinbeeld voor de driehoogte seinen systeem46 te kunnen tonen

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg
De CanBus komt naar Kranenberg

Reinout van Rees

  • Team forummoderators
  • Offline Offline
  • Berichten: 7397
  • Forummoderator
    • Persoonlijke website + weblog
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #123 Gepost op: 08 mei 2020, 22:26:04 »
Object georiënteerd programmeren hoera! Ik vind er altijd een zekere elegantie in zitten om gewoon eens naar de verschillende soorten objecten te kijken. Een "AKI", die ervoor moet zorgen dat de boel knippert en geluid maakt enzo. Een "sensor" die alleen hoeft te detecteren of er iets over z'n vingers rijdt of niet. Enz.

Bas: je lijkt booleans niet leuk te vinden? Waarom niet? Er zijn in mijn dagelijkse praktijk een heleboel dingen die "wel/niet", "ja/nee" zijn. Als je er een derde iets bij wilt hebben wordt het een beetje quantumcomputing achtig ofzo: "ja/nee/misschien"? Tenminste, zo komt het op mij over. Een aki is aan of uit. Een wissel staat recht of afbuigend. Een spoor is vrij of niet. "Misschien is wat gevaarlijk in het laatste geval :)

Natuurlijk zijn er uitzonderingen. Zo'n Duits twee-armen-sein als ik heb heeft netjes drie staten (rood=0, groen=1 en geel=2). Maar dat weerhoud mij er niet van om voor de ja/nee zaken de IJzeren Logica van boolean True/False te gebruiken.

(Zeg ook ik, die sinds 2000 met Python werkt en zich alleen voor arduino's met C-achtige zaken hoef bezig te houden :) Ook leuk voor de verandering.)

Reinout
Bouw v/d EifelBurgenBahn (h0, zijlijn in de Eifel)
Eifelgeschiedenis (verhalen en video's over de Eifelburgenbahn)

Klaas Zondervan

  • Offline Offline
  • Berichten: 25274
    • Pagina van klaas
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #124 Gepost op: 08 mei 2020, 22:33:38 »
Een wissel staat recht of afbuigend.
Een wissel kent nog een derde toestand: in beweging. Dan staat hij niet recht en ook niet afbuigend.

ikbenerevenniet

  • Offline Offline
  • Berichten: 379
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #125 Gepost op: 08 mei 2020, 22:50:15 »
Nee, dat geldt niet als een toestand.

Klaas Zondervan

  • Offline Offline
  • Berichten: 25274
    • Pagina van klaas
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #126 Gepost op: 08 mei 2020, 23:24:04 »
Wat is het dan? Reinout stelt dat een wissel recht of afbuigend kan zijn. Maar gedurende de beweging is hij allebei niet. Hoe moet ik dat dan noemen?

Martin Hornis

  • Offline Offline
  • Berichten: 1413
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #127 Gepost op: 08 mei 2020, 23:30:33 »
Er zijn twee soorten toestanden:
a) statische (stilstaand);
b) dynamische (bewegende).

Pierre-Simon Laplace heeft daar zo'n 200 jaar geleden het een en ander over geschreven. Zie Wikipedia. Vooral bij Statistiek staan opmerkelijke zaken. Daar staan o.a. "posities en snelheden". Hij benoemt daar ook de kansrekening. Dus wat is de kans dat een wissel in een bepaalde positie stilstaat of aan het bewegen is. Je zult met beide toestanden rekening moeten houden.

Vergelijk het maar eens met (twee) afzonderlijke flitspalen en trajectcontrole.
« Laatst bewerkt op: 08 mei 2020, 23:33:17 door Martin Hornis. Reden: flitspalen »
Märklin K-rails met boogstralen > 500 mm; NS-lichtseinen met cijferbak: 4, 6 en 8 in één bak; iTrain; Intellibox I; OC32;
eigen treindetectiesysteem aangesloten op OC32;
controleprogramma voor OC32.

meino

  • Offline Offline
  • Berichten: 2098
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #128 Gepost op: 09 mei 2020, 00:12:30 »
Grappig hoe er op eens een discussie op gang komt.

Klaas heeft wel gelijk dat het wissel ook in beweging kan zijn. Echter dat is alleen van belang voor het wissel object zelf. De buitenwereld hoeft dat niet te weten. Die zet gewoon het wissel in rechtdoor of afbuigend, het is dan aan het wisselobject zelf om het wissel in beweging te brengen en die beweging te controleren tot dat het wissel in de gewenste stand staat. Kortom voor de buitenwereld heeft het wisselobject slechts twee toestanden, rechtdoor of afbuigend. In de praktijk werkt dit prima, het omzetten gebeurd snel genoeg binnen de tijdspanne die bijv. Koploper reserveert.
Mocht de buitenwereld besluiten om opnieuw de toestand te wijzigen terwijl het wisselobject nog in beweging is, dan is dat een probleem voor het wisselobject om dat correct af te handelen, niet voor de gebruiker. Mocht het om wat voor reden ook nodig zijn dat de buitenwereld wel moet weten of het wissel al goed ligt, dan zou ik een tweede toestand invoeren, n.l. gereed of niet gereed.
Dat is het prettige van OO. Je kunt zaken die voor de gebruiker niet relevant zijn makkelijk isoleren (eigenlijk is dat een vereiste om te doen).

Groet Meino
« Laatst bewerkt op: 09 mei 2020, 00:15:26 door meino »
A clean desk is a sign of an empty mind

Kranenberg
De CanBus komt naar Kranenberg

Martin Hornis

  • Offline Offline
  • Berichten: 1413
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #129 Gepost op: 09 mei 2020, 00:20:41 »
Die zet gewoon het wissel in rechtdoor of afbuigend, het is dan aan het wisselobject zelf om het wissel in beweging te brengen en die beweging te controleren tot dat het wissel in de gewenste stand staat.
Dus controleren d.m.v. eindstandschakelaars. Derhalve twee onderling onafhankelijke contacten. Dus geen wisselcontact.
Märklin K-rails met boogstralen > 500 mm; NS-lichtseinen met cijferbak: 4, 6 en 8 in één bak; iTrain; Intellibox I; OC32;
eigen treindetectiesysteem aangesloten op OC32;
controleprogramma voor OC32.

meino

  • Offline Offline
  • Berichten: 2098
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #130 Gepost op: 09 mei 2020, 09:47:07 »
Op dit moment is de eneige terugkoppeling die ik heb is visueel, door middel van ledjes op een paneel.
Voor een geplande uitbreiding met een schaduwstation zit ik wel te denken aan een vorm van een simpele terugkoppeling op een digitale pin van de Arduino. Dusdit zou een mogelijkheid zijn.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg
De CanBus komt naar Kranenberg

Klaas Zondervan

  • Offline Offline
  • Berichten: 25274
    • Pagina van klaas
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #131 Gepost op: 09 mei 2020, 10:01:53 »
Ik ben al jaren gewend om op mijn wissels terugmelding toe te passen. Tijdens het omlopen staat het wissel niet rechtdoor en ook niet afbuigend. En dat is voor mij de derde toestand: stand onbepaald. Bij handbediening kan ik dat op het paneel ook zien, beide leds zijn uit.
Als je geen terugmelding hebt dan ga je er van uit dat het wissel staat in de stand waarin je het hebt gestuurd, en dan ken je inderdaad maar 2 toestanden.

Reinout van Rees

  • Team forummoderators
  • Offline Offline
  • Berichten: 7397
  • Forummoderator
    • Persoonlijke website + weblog
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #132 Gepost op: 10 mei 2020, 15:20:07 »
Op video's van Duitse bedieningspanelen zie je inderdaad het ledje van de ene stand uitgaan en pas na een seconde ofzo het ledje van de andere stand aangaan. Ik had dat niet met de terugmelding geassocieerd, maar dat zal het wel zijn, ja.

Reinout
Bouw v/d EifelBurgenBahn (h0, zijlijn in de Eifel)
Eifelgeschiedenis (verhalen en video's over de Eifelburgenbahn)

Klaas Zondervan

  • Offline Offline
  • Berichten: 25274
    • Pagina van klaas
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #133 Gepost op: 10 mei 2020, 17:00:14 »
Waar zouden die ledjes anders voor zijn?  ;)

Reinout van Rees

  • Team forummoderators
  • Offline Offline
  • Berichten: 7397
  • Forummoderator
    • Persoonlijke website + weblog
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #134 Gepost op: 10 mei 2020, 22:38:13 »
Als je erover nadenkt: logisch inderdaad.
Ik zat naar het leuke visuele effect te kijken i.p.v. na te denken :)

Reinout
Bouw v/d EifelBurgenBahn (h0, zijlijn in de Eifel)
Eifelgeschiedenis (verhalen en video's over de Eifelburgenbahn)