BeneluxSpoor.net forum
Vraag en antwoord => Elektronica en analoog => Topic gestart door: meino op 18 april 2018, 16:54:00
-
Ik zag dat het hoofdstukje over Digitaal op dit forum hoofdzakelijk over problemen en vragen gaat, dus plaats ik dit draadje toch maar hier, ondanks het feit dat het alleen maar over digitale- en computerzaken gaat.
Zoals ik in de bouwbeschrijving van Kranenberg (https://forum.beneluxspoor.net/index.php?topic=77057.msg0#msg0) beschrijf, ben ik op een gegeven moment van analoog bedrijf naar digitaal overgestapt. Dat is gebeurd met een MDRRC-II Centrale. De volgende stap, die al snel kwam, was om dan ook met een PC de baan te gaan besturen. De MDRRC-II centrale kan met een aantal programma's aangestuurd worden, waarbij Robert Evers Koploper als referentie gebruikt. Alhoewel ik zelf een voorkeur voor JMRI had, maar dat ondersteunde de MDRRC-II centrale niet. Dus Koploper gedownload en opgetuigd. Dat had best wat voeten in de aarde, omdat Koploper zo zijn eigenaardigen heeft. Maar om Koploper (en ook andere programmatuur) zijn werk te kunnen laten doen, moet Koploper informatie van de baan krijgen en de mogelijkheid hebben om wissels te kunnen aansturen. Teminste als je automatisch wilt rijden. Verder wilde ik ook iets met seinen gaan doen. In eerste instantie had ik het idee om dat puur met armseinen te doen, totdat ik ontdekte dat er ook 3D geprinte seinen van het seinstelsel '46 beschikbaar waren. Na een test met het bouwen van een sein, besloten om, op 2 versimpelde vertakkingseinen na, alles met seinen van het seinstelsel '46 te doen, zie https://forum.beneluxspoor.net/index.php?topic=34476.540 (https://forum.beneluxspoor.net/index.php?topic=34476.540), vanaf reactie #543. Dat betekende dat er een aantal verschillende componenten bedacht en gebouwd moesten worden. Een systeem dat de bezetmelding van een sectie in de baan in de gaten houdt en terugmeldt aan de centrale, een systeem dat DCC wisselcommando's ontvangt en de wissels omzet en een systeem dat de ledjes en servo's van de seinen aanstuurt.
Dat heeft uiteindelijk tot het volgende complex van systemen geleid.
(https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers.jpg) (https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers.jpg)
Oorspronkelijk waren de systemen voor de bezetmelders en wisselaansturing gescheiden. Maar ik had al snel het idee dat ik de wissels ook handmatig nog wilde kunnen aansturen. Dat moest dan wel via Koploper gebeuren in verband met de controle, het is niet zo handig om een wissel om te zetten als de wissel nog bezet is. Dat kon via een bezetmelder (gekoppeld aan een drukknop) en een speciale actie. Alleen om dat goed werkend te krijgen is het eigenlijk ook nodig om een terugmelding naar Koploper van de wisselstand te hebben via een bezetmelding. Vandaar dat er communicatie is ontstaan tussen deze systemen, waarbij de wisselsteller een melding maakt aan de bezetmeldercontroller als een wissel omgaat. Later toen ik de systemen voor de seinen ontwikkelde, bleken die ook behoefte te hebben om te weten hoe de wissels staan. Verder deze laatste worden ook door DCC commando's aangestuurd, ik had ze apart aan de DCC bus kunnen verbinden, maar omdat dat de wisselsteller al een koppeling met de DCC bus had, vangt die de seincommando's op en geeft die ook door aan de seincontrollers.
Een opmerking voor de nitpickers, ik heb iets de S88 bus genoemd, technisch gezien is dit een shiftregister en geen bus, maar conceptueel vond ik het beter om dit een bus te noemen.
Tot zover deze introductie, in de volgende stukjes zal ik wat dieper ingaan op de verschillende systemen.
Groet Meino
-
Hoi Meino,
de categorieën zijn wat dat betreft een beetje een ramp inderdaad :-\
Maar waarom ben je voor I2C gegaan ipv XPressNet wat de MDRRC-II zo ondersteund? I2C is namelijk absoluut niet geschikt om onder een baan te leggen. Na 10 a 20cm houdt I2C echt wel op stabiel te zijn ::)
Timo
-
Hoi Timo
dat weet ik, maar gemak dient de mens. Deze systemen zitten allemaal vlak bij elkaar onder de baan, dus afstand is nog geen probleem, overigens de grootste afstand die ik heb overbrugd is 50-60 cm en werkt in mijn situatie nog probleemloos. Maar de implementatie is dood simpel, 2 draadjes en een bestaande library. Als het in de toekomst toch problemen gaat geven, door extra systemen die verder af gaan komen, dan kan ik altijd nog het vervangen door een ander bus systeem. Dan denk ik zelf eerder aan Loconet dan XpressNet.
Groet Meino
-
Maar waarom ben je voor I2C gegaan ipv XPressNet wat de MDRRC-II zo ondersteund?
Schrok even, maar gelukkig gebruik je de I2C bus van MDRRC-II niet...
Ondersteuning daarvoor gaat namelijk bij de eerste beste update eruit.....
a 10 a 20cm houdt I2C echt wel op stabiel te zijn
Mwaahhh, als je bitrate niet te hoog zet gaat een metertje of twee wel :)
Mvg
Robert
-
Schrok even, maar gelukkig gebruik je de I2C bus van MDRRC-II niet...
Ondersteuning daarvoor gaat namelijk bij de eerste beste update eruit.....
Nee, ik zou eerlijk gezegd niet weten waarvoor ik die kon gebruiken. de enige data die ik naar MDRRC-II stuur gaat via S88. Maar nog wel even een compliment voor je over de MDRRC-II.
Groet Meino
-
Leuke opzet. Zie mogelijkheden voor een SX-bus ipv een I2C bus.
Groet,
Gerard van der Sel.
-
Ja, dat is de dunne lijn tussen "het werkt" en een goed ontwerp. Zeg niet dat je het moet aanpassen hoor (y) Maar als je rare dingen ziet zou dat wel je eerste punt van aandacht moeten zijn. Door inderdaad maar de standaard 100 kbit/sec gebruikt en niet te lichte pull ups gebruikt is het nog wel een beetje te rekken\stabiliseren. Maar bedenk dat de meeste modelspoorbanen redelijk veel storing bevatten.
Timo
-
Timo
Wat een goed ontwerp is zullen we hier niet over twisten, dat heb ik in mijn werkzame leven al genoeg gedaan. Nu ben ik met een hobby bezig en het meeste is organisch gegroeid, waarbij veel zaken achteraf anders en beter hadden gekund.
Ik ben me zeer bewust van de potentiele problemen, Ik heb al genoeg problemen gehad met servo's - opgelost door afgeschermde cat6 kabels te gebruiken - en nu heb ik een bezetmelder die zo nu en dan vervelend doet, helaas is het juist de bezet melder die met het kortste kabeltje (20cm) met de arduino verbonden is. Verder heb ik de DCC library aangepast om stoorsignalen(spikes) op het DCC kanaal software matig uit te filteren.
Toen ik met de I2C bus begon was het een verbinding tussen 2 mega's die naast elkaar zitten, dus een heel korte verbinding en heel simpel te realiseren, later heb ik ook nog een cluster van 3 mega's verbonden. Die drie zitten ook naast elkaar alleen is de cluster zelf ongeveer 50-60 cm verwijderd van de andere 2. Tot nu toe werkt dat vlekkeloos, waarbij ik nog niets aan de clockrate (ik wist niet eens dat dat kon) gedaan heb, dus dat loopt nog op de default waarden. Verder probeer ik me aan het adagium "If it ain't broke, don't fix it" te houden, soms is dat best wel moeilijk omdat ook ik vaak denk "Dat kan beter". Mocht ik in de toekomst meer Arduino's te gaan koppelen, dan is de kans groot dat ik de I2C bus door iets anders moet vervangen.
Groet Meino
-
Naar aanleiding van dit draadje heb ik eens gekeken wat I2C inhoudt. In alle beschrijvingen die ik vind wordt gesteld dat er slechts 2 lijnen zijn, een datalijn en een kloklijn. Maar om het goed te laten werken moet de ground van de diverse controllers toch ook gekoppeld zijn?
-
Klopt Klaas. I2C bestaat uit een klok lijn en een bidirectionele datalijn. Om het geheel elektrisch te laten werken is er nog een derde lijn de GND. I2C is bedoeld voor communicatie IN een apparaat. Hierbij is sprake van een voeding (Zal je wel bekend zijn). Hierdoor staat het ook bekend als een twee draads protocol. Het is dus bij grotere afstanden drie draads.
Groet,
Gerard van der Sel.
-
Ik wist dat dat voor I2C nodig was, dus alle Arduino's zijn gekoppeld aan de zelfde GND. Het zelfde voor de voeding, alle arduino's en aangekoppelde hardware wordt vanuit 1 bron gevoed.
Overigens heb ik ook maar eens op wikipedia gekeken en de Engelse versie (https://en.wikipedia.org/wiki/I%C2%B2C (https://en.wikipedia.org/wiki/I%C2%B2C)) geeft een zeer uitgebreide beschrijving. Overigens kwam ik daar het volgende tegen:
"The maximal number of nodes is limited by the address space and also by the total bus capacitance of 400 pF, which restricts practical communication distances to a few meters. The relatively high impedance and low noise immunity requires a common ground potential, which again restricts practical use to communication within the same PC board or small system of boards."
Daaruit leid ik af dat de maximale afstand die veilig te overbruggen is hoofdzakelijk bepaald wordt door de maximale capaciteit van de kabel. Als ik het zo bekijk dan komt mijn situatie redelijk overeen met wat beschreven wordt. Het is weliswaar geen koppeling op een board, maar de gekoppelde systemen zitten in mijn geval wel fysiek dicht bij elkaar. Het is echter wel duidelijk dat als de te koppelen systemen verspreid over de baan zitten, de I2C bus niet zonder meer een goede oplossing is.
Groet Meino
-
Nu ben ik met een hobby bezig .....
Gewoon lekker doorgaan :)
Soms is het wat omslachtig of kan het anders maar jij moet er plezier aan hebben !
Zo is MDRRC ook ontstaan...
Mvg
Robert
-
Er bestaan overigens I2C busdrivers die de afstand erg vergroten. Wat betreft de adresspace, die is 7 bits. Dus 128 apparaten. Hoeveel data ieder apparaat ontvangt is niet gedefinieerd. Bij je draaischijf gebruik je een afgeleide van I2C, en daar gaan met iedere dataslag een stuk of 32 bits heen en weer. Hiervan is een gedeelte subadres.
Groet,
Gerard van der Sel.
-
Dag Gerard
De Adafruit motorshield die ik eerst gebruikte bij de draaischijf, gebruikt inderdaad de I2C bus. Het driverkaartje dat ik nu gebruik, de TMC2130, gebruikt de SPI bus. Tenminste dat leid ik uit het commentaar in de library af. De SPI bus zou dus ook nog een mogelijkheid zijn om Arduino's te laten communiceren, maar daar heb ik me nog niet echt in verdiept.
Groet Meino
-
Ik kom toch nog even terug op de afgelopen discussie.
Timo heeft echt wel een punt betreffende het gebruik van I2C bus. Het is hiermee erg makkelijk om Arduino's te koppelen, en in mijn situatie werkt het goed. Maar dat hoeft niet in iedere situatie op te gaan. Daarnaast heb ik voldoende kennis om eventuele problemen op te lossen, maar dat hoeft niet voor iedereen op te gaan.
Daarom heb ik toch nog eens naar wat alternatieven gekeken, n.l. XpressNet en Loconet. Maar ik vind dat aan beide alternatieven toch wel nadelen kleven.
- XpressNet is een gesloten systeem die naast de hardware ook een complete definitie van alle commando's tussen de master en aangesloten apparaten bevat. Dat betekend dat ik voor mijn toepassing waarschijnlijk gebruik moet maken van commando's die in beschreven zijn door Lenz. Verder maakt XpressNet gebruik van een adres van 5 bits, wat betekend dat XpressNet maximaal 31 apparaten kan aansturen. Verder is binnen het XpressNet de centrale verantwoordelijk voor het toewijzen van transmissie slots aan de aangesloten apparaten. Kortom de Centrale is verantwoordelijk voor het ordelijk functioneren van het netwerk/bus. Ook de transmissie snelheid (64Kb) vindt wat aan de lage kant.
- Loconet is anders, het bevat niet een master en alle apparaten hebben de zelfde rechten (het is afgeleid van Ethernet). Maar voor zover ik kan zien bevat het ook set van voorgedefinieerde commando's. Overigens dit weet ik niet helemaal zeker, omdat Lenz een document met een complete definitie heeft gepubliceerd, maar voor Loconet heb ik dat nog niet kunnen vinden. De vrije, op Ethernet gebaseerde werking spreekt mij wel aan. Maar de transmissie snelheid (16Kb) vindt ik zelf veel te laag voor de toepassing die ik voor ogen heb.
Kortom bij geen van de beide alternatieven loop ik erg warm om dat te gaan gebruiken. Toen kwam ik op Ebay het volgende tegen https://www.ebay.de/itm/mini-ENC28J60-Ethernet-LAN-Netzwerk-Modul-Arduino-RJ45-SPI-CP01002 (https://www.ebay.de/itm/mini-ENC28J60-Ethernet-LAN-Netzwerk-Modul-Arduino-RJ45-SPI-CP01002).
Een kaartje waarmee je Arduino's op Ethernet kunt aansluiten, voor de prijs (vanaf euro 2,50) hoef je het niet te laten, en met de juiste bibliotheek, kan een Arduino in een IP netwerk worden opgenomen, je kunt zelfs een HTML server bouwen op een Arduino. Dit opent vele mogelijkheden, peer to peer communicatie met UDP of TCP, remote configuratie en monitoring door middel van een Webbrowser etc. Verder alle hardware is makkelijk te krijgen, iedere bouwmarkt heeft tegenwoordig een grote collectie aan patchkabels, stekkers, tangen, losse cat5 kabel. Switches en routers zijn ook voor weinig geld overal te krijgen.
Dus ik heb wat van deze kaartjes besteld in China om te kijken of dit kan gaan werken. De resultaten zal ik hier in draadje wel laten weten.
Groet Meino
-
Je kunt nog eens naar CAN kijken (link is eerste beste die ik zag)
http://henrysbench.capnfatz.com/henrys-bench/arduino-projects-tips-and-more/arduino-can-bus-module-1st-network-tutorial/
Of Bidib
https://www.opendcc.de/bidib/overview/overview.html
Verkijk je niet op de Arduino's en ENC28J60, daar haal je geen 1GByte mee :)
Welke Arduino's gebruik je eigenlijk?
Mvg
Robert
-
Dag Robert
nee dat ik geen 1Gb haal weet ik, de betreffende kaartjes gaan niet verder dan 10Mb, maar dat is al 100x sneller dan de 100Kb van I2C. Dus voor mijn toepassing is dat ruim voldoende. Ik gebruik Mega's. Ik denk zelf dat een Uno (of Nano) misschien aan de krappe kant is voor wat ik wil, maar dat ga ik uitproberen.
Bedankt voor de tips over CAN en Bidip daar ga ik ook nog eens naar kijken.
Groet Meino
-
Dag Robert
ik heb nog eens naar die andere bussen gekeken. Bidib is zoals Karst zegt de natte droom voor electrotechnici, Dat ben ik niet en vindt de oplossing voor mijn toepassing veel te zwaar, met al die hardware. Echter om eerlijk te zijn de CAN bus is misschien precies wat ik zoek, net als I2C een simpele oplossing met 2 draadjes en een simpel protocol om pakketjes van de ene node naar de andere node te krijgen, met een zeer ruime adres ruimte en voldoende snelheid, dus heb ik ook maar 2 kaartjes (MCP2515 CAN Bus Module TJA1050) uit China besteld om dat ook eens uit te proberen.
Groet Meino
-
\Oke dan nog een alternatief. Volledig zelfbouw, maar toch maar eens geschoten. De SX-bus. Je richt een van je Arduino's in als master en je "klikt" de volgende er snel op. Eigenschappen SX-bus: bidirectioneel, opgebouwd rond een LM339/4049, geen speciale kabel nodig (tenzij je fabrieks apparatuur gebruikt), 112 adressen (van 8 bit). Het communicatie protocol is synchroon en iedere 76,8 msec worden alle adressen langs gestuurd.
Zowel een master als een slave zijn beschikbaar voor de Arduino.
(Wordt op dit moment door Railclub Utrecht voor cimmunicatie onder hun modelbaan gebruikt.)
Groet,
Gerard van der Sel.
-
Allereerst I2C. In de ideale wereld is inderdaad de capaciteit de bottle neck. Maar naast dat je waarschijnlijk niet ideale kabel gebruikt wordt in die "several meters" geen storing meegenomen. Dat is puur en alleen de gestelde steilheid van de flanken kunnen halen.
nee dat ik geen 1Gb haal weet ik, de betreffende kaartjes gaan niet verder dan 10Mb, maar dat is al 100x sneller dan de 100Kb van I2C.
Nouwwwwwwww, verkijk je niet. De module meldt zich als 10Mbit maar met een 8-bit micro zonder hardware ethernet support of DMA mag je denk ik blij zijn met dezelfde snelheid als fast-I2C (400kbit) en dat is zonder de overheid van ethernet. En van dat laatste heb je wel het een en ander. Adressering nog niet eens bekeken maar goed, dat heb je met I2C nu ook. In mijn optiek is ethernet dus een beetje zwaar voor deze toepassing. Maar laat je je daardoor zeker niet weerhouden om het te proberen ;D
CAN lijkt me dan wel weer een aardige zeker met de goedkope CAN-drivers en CAN-receiver die er zijn. Maar zelf helaas nog niet mee gespeeld.
En denk je echt zoooo veel snelheid nodig te hebben voor wat commando's? :o Met zowel XpressNet als LocoNet worden toch aardig grote banen aangestuurd zonder problemen.
Timo
-
Hoi Timo
die Ethernet oplossing heeft een grote nostalgische aantrekkingskracht, van 85-97 was ik o.a. IP en netwerk architect. Dus IP (en Ethernet) ken ik als mijn broekzak. Ik weet dus ook wat overhead etc doet ten aanzien van de performance.
Maar ik heb nu eigenlijk besloten om voor deze toepassing de CAN bus te gaan gebruiken. Ik had dat eerder kunnen weten, want ik ben lid van MERG (https://www.merg.org.uk/) en die hebben een eigen systeem van modules, nl de CBUS. Die gebruiken ook de CAN bus voor de communicatie. Ze hebben een interessante oplossing, nl een Producer-Consumer model voor hun communicatie, ik denk dat ik dat ook maar ga implementeren.
Ik geloof best dat de performance van Loconet, XpressNet, Bidib, Cbus etc meer dan voldoende is, de reden dat ik toch die kant niet opga is dat al deze oplossingen te groot zijn. Ze leveren een complete oplossing met uitgedefinieerde protocollen en complete hardware oplossingen. Ik zoek eigenlijk alleen een goed en betrouwbaar transport medium waarmee ik informatie van Node A naar Node B kan krijgen, waarbij de benodigde hardware zo simpel mogelijk is. Dat sprak me aan met de I2C bus en nu bij de CAN bus. Overigens ook de Ethernet oplossing spreekt me om die reden aan, afgezien van het feit dat ik met Ethernet en IP weer terug ben op mijn "Stomping Ground"
@Gerard, bedankt voor het idee van de SX bus, maar interface kaartjes voor de CAN bus kosten nog geen 1,5 euro en op een gegeven moment moet je een keus maken voor iets, en daarom ga ik op dit moment eerst de CAN bus eens proberen.
Groet Meino
-
(y) Wat ik al zei, jij moet er lol in hebben dan heeft het zijn doel bereikt ;D
Toch nog één ding (https://xkcd.com/927/). ;D
Timo
-
(https://forum.beneluxspoor.net/Smileys/classic/duim.gif) Leuk
Groet Meino
-
Toch nog één ding (https://xkcd.com/927/). ;D
Had hem al eens eerder gezien, maar geeft treffend de situatie weer. Ik snap ook niet waarom elke firma zijn eigen bus moet uitvinden. Volgens mij verschillen ze alleen maar op hardware level.
-
nl de CBUS.
Je kunt ook voor de Maerklin variant gaan :)
https://www.maerklin.de/fileadmin/media/produkte/CS2_can-protokoll_1-0.pdf
Meen dat in dit document de terugmelding niet is beschreven....
Ik snap ook niet waarom elke firma zijn eigen bus moet uitvinden.
* Geld verdienen
* IP bescherming
* Laat je concurrent NIET simpel connectie maken met hun goedkope apparaat aan jouw eigen (duurdere) apparatuur.....
* Dat kan veeeeeeeeeeeeeeeeel beter....
* .....
Maar back on topic :)
Mvg
Robert
[/list]
-
Ok, op basis van alle reacties en de discussie die daar opvolgde, ga ik toch een versie 2 bouwen.
(https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V2.jpg) (https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V2.jpg)
Dit is niet zoals het momenteel gebouwd is, het gebruik van de I2C bus is toch te beperkt en kan bij nabouw tot onvoorziene problemen leiden. Dus dit gaat meer een bouw verslag worden waarin ik de (ver)bouw van de diverse modules beschrijf. Voor het ontwerp en de realisatie zijn de volgende zaken van belang.
- Als bus ga ik voor de CAN bus, dat is een bewezen oplossing en algemeen in gebruik. Interface kaartjes zijn makkelijk te krijgen en kosten weinig.
- De communicatie tussen de verschillende componenten volgt het Producer-Consumer model. Dat betekend dat sommige componenten (Producenten) gebeurtenissen (events) registreren en dat als bericht op de bus publiceren zonder te weten voor wie dit belangrijk is. Andere componenten (Consumenten) lezen alle gepubliceerde berichten en handelen eventueel een bericht af. Dit is een model dat gevolgd wordt door Marklin met de CS2 en MERG met de CBUS.
- De keuze voor een van deze twee protocollen wordt uitgesteld tot later. Doordat C++ een object oriented taal is, kan ik dat makkelijk achter de facade van de protocol objecten verbergen.
- In de huidige implementatie zijn een aantal functionele componenten samen op een Arduino actief. Door de keuze van het Producer-Consumer model is het verstandiger om deze componenten (DCC interface en S88 interface) te scheiden en uit te rollen op een eigen Arduino.
Nog even wat anders, waarom doe ik dit terwijl er kant en klare oplossingen zijn?
- Ik vind programmeren en het oplossen van dit soort technische problemen leuk.
- Het kostenaspect.
Zo dit is het voor nu, het wachten is op de CAN bus kaartjes.
Groet Meino
-
Voordat ik verder ga met de beschrijving van de meeste componenten, wacht ik totdat ik de CAN-bus heb geïmplementeerd.
Er is echter een component waarbij de implementatie van de CAN-bus niet erg relevant is voor de werking, die zal ik dan nu proberen te beschrijven. Dit is ook een buitenbeentje voor wat betreft de functionaliteit, dat is de SeinController.
Een klein beetje achtergrond, oorspronkelijk was ik van plan om alles met klassieke armseinen te doen aangestuurd vanuit Koploper. Maar ik ontdekte dat er 3D geprinte driehoogte seinen van het seinstelsel 1946 bestonden. Nadat ik als proef er een gebouwd had en het bleek dat het mogelijk was om deze werkend te krijgen (zie draadje https://forum.beneluxspoor.net/index.php?topic=34476.msg3221800162#msg3221800162 (https://forum.beneluxspoor.net/index.php?topic=34476.msg3221800162#msg3221800162)), besloten om voor het grootste deel (hoofdbaan + Emplacement) met seinstelsel '46 te beveiligen.
Maar er waren wel een aantal complicerende factoren, Koploper heeft geen definities voor dit seinstelsel, en voor Koploper gurus is het misschien simpel, maar mijn ervaring met Koploper bij het configureren van de NS Armseinen was niet van dien aard dat ik het met Koploper wilde proberen te doen, ik vindt het makkelijker om een Arduino programma te ontwikkelen dan me in krochten van Koploper te begeven.
Het seinstelsel '46 heeft als bijzonderheid dat het verschillende seinbeelden kent die afhankelijk zijn van de toegestane snelheid op het huidige en verwachte baanvak.
Wat voorbeelden, waarbij ik een versimpeld deel van Kranenberg gebruik. Het betreft het hoofdspoor dat door het station gaat en twee parallel sporen, de treinen rijden van links naar rechts.
(https://images.beneluxspoor.net/bnls/Seinen1.jpg) (https://images.beneluxspoor.net/bnls/Seinen1.jpg)
Wissel 1 staat rechtdoor, sein en wissel mogen met 120km/u gepasseerd worden, voor het perronspoor geldt een maximum
van 80km/u.
Stop voor sein 2 seinbeeld sein 2: rood-zwart-zwart
Doorrijden sein 2, doorrijden sein 4 seinbeeld sein 2: groen-groen-wit
Doorrijden sein 2, stop sein 4 seinbeeld sein 2: geel-wit-wit
(https://images.beneluxspoor.net/bnls/Seinen2.jpg) (https://images.beneluxspoor.net/bnls/Seinen2.jpg)
Wissel 1 rechtsaf, wissel 2 linksaf , sein en wissel mogen met 60 km gepasseerd worden wat ook geldt voor het
perronspoor.
Stop voor sein 2 seinbeeld sein 2: zwart-rood-zwart
Doorrijden sein 2, doorrijden sein 6 seinbeeld sein 2: wit-groen-wit
Doorrijden sein 2, stop sein 6 seinbeeld sein 2: wit-geel-wit
(https://images.beneluxspoor.net/bnls/Seinen3.jpg) (https://images.beneluxspoor.net/bnls/Seinen3.jpg)
Wissel1 rechtsaf, wissel2 rechtsaf, sein en wissel mogen met 60km/u gepasseerd worden, voor het volgende
wissel en spoor geld een limiet van 40km/u.
Stop voor sein 2 seinbeeld sein 2: zwart-zwart-rood
Doorrijden sein 2, doorrijden sein 8 seinbeeld sein 2: wit-groen-groen
Doorrijden sein 2, stop sein 8 seinbeeld sein 2: wit-geel-wit
De drie stop seinbeelden mogen ook vervangen worden door een beeld nl. rood-zwart-zwart, dan
komt het er op neer dat een driehoogte sein 13 verschillende seinbeelden kan vertonen -10 standaard plus 3 extra, nl. geel knipper (75/min)-. De drie andere seinbeelden, geel knipper snel (180/min) die later toegevoegd zijn, vergeet ik dan gemakshalve maar. Het eenhoogte sein kent 4 seinbeelden (rood, groen, geel en geel knipper (75/min), ook hier is later het seinbeeld geel knipper snel (180/min) aan toegevoegd. Overigens nog een korte opmerking, het baanplan dat ik gebruik in de voorbeelden is een schema van dit deel, het komt fysiek niet overeen en verder de snelheidsbeperkingen heb ik ook gedefinieerd om een wat gevarieerder seinbeeld te krijgen.
Een zeer uitgebreide beschrijving van het seinstelsel '46 is te vinden op Seinarm.nl (http://www.seinarm.nl/Licht46/Seinstelsel1946/invoeringstelsel46.aspx) en vooral de uitleg over de situatie bij Blauwkapel 1949-1961 is erg verhelderend.
Een andere factor om rekening mee te houden zijn de karakteristieken van de gebruikte smd ledjes. In het geval van het eenhoogte sein gebruikt ik een tweekleurige (rood-groen) smd ledje, geel maak ik door de rode en groene led tegelijkertijd aan te sturen. Helaas moet de intensiteit van iedere kleur apart geregeld kunnen worden om een goede tint geel te krijgen, verder zit er ook intensiteit verschil tussen het rood en het groen. Voor een deel kun je dit compenseren door met de waarden van de voorloop weerstand te spelen, maar een precieze afstemming doe ik door de leds aan te sturen via een PWM pin. Het zelfde geldt voor de driehoogte seinen, waar ik een drie kleuren (rood, groen en blauw) smd ledje gebruikt. De kleuren wit en geel worden ook weer geproduceerd door de kleur te mengen. Ook hier is het voor een optimale kleur nodig om ieder led kleur apart te kunnen afregelen, Vandaar dat ook hier de ledjes via een PWM pin worden aangesloten. Dat betekend dat voor een driehoogte sein ik 9 PWM pinnen, en voor een eenhoogte sein 2 PWM pinnen nodig heb. Vandaar mijn keuze om voor de SeinController een Arduino Mega te gebruiken.
In de volgende stukje zal ik in gaan op de programmatuur voor de arduino die dit regelt.
Groet Meino
-
Hallo dan nu een stukje techniek. Ik heb voor de bouw van dit systeem een Arduino bibliotheek gemaakt (NS_Seinstel46) die de werking van het geheel realiseert. De Arduino schets bevat dan alleen maar de configuratie, een interrupt routine voor het afhandelen van de (DCC) commando's en een aantal functie aanroepen om het geheel te laten werken. Indien er belangstelling voor is, stuur me een PB voor een zip bestand met de bibliotheek.
De werking van het geheel bespreek ik aan de hand van een versimpeld deel van het stations emplacement van Kranenberg.
(https://images.beneluxspoor.net/bnls/Emplacement-S66.jpg) (https://images.beneluxspoor.net/bnls/Emplacement-S66.jpg)
De volgende typen seinen komen daar op voor; een driehoogte sein, diverse eenhoogte seinen en een versimpeld arm vertakkingssein. Het driehoogte sein maakt gebruik van een driekleurige led, de eenhoogte seinen gebruiken tweekleurige leds en het armsein wordt met twee servo's aangestuurd en heeft een witte led voor de verlichting.
Opmerking:
De leds zijn verschillend, de driekleuren leds werken met een gemeenschappelijke anode, welke aan de 5v pin van de arduino is aangesloten, Dat betekend dat de werking van de PWM pinnen anders is, Als een PWM pin vol uitstuurt wordt, zal de aangesloten kleur gedoofd zijn. De twee kleuren leds en de witte led werken met de kathode die aan gnd aangesloten is. De C++ classes die de werking van de leds aansturen houden hier rekening mee. Mocht iemand driekleuren leds met common kathode willen gebruiken dan zal de RGBLed class aangepast moeten worden.
Het arduino programma met de configuratie voor bovenstaand schema.
/*
A program do control railroad semaphores from the Dutch Railways (NS) system 1946
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.
*/
#include <Servo.h>
#include <Wire.h>
#include <NS_Seinstelsel46.h>
#define I2C_BASE 8
#define I2C_CONTROLLERS 2
#define I2C_BEZETMELDER_ID 8
#define I2C_SEINCONTROL1_ID 9
#define I2C_SEINCONTROL2_ID 10
#define I2C_SEINCONTROL3_ID 11
//
// ID that defines this specific instance of the controller.
// It's actual value is established during setup and is based on some jumpers
//
int i2cId = 0;
//
// Table with all active turnouts
//
const int nrOfTurnouts = 12;
Turnout turnouts[nrOfTurnouts] =
{
Turnout(1),
Turnout(2),
Turnout(3),
Turnout(4),
Turnout(5),
Turnout(6),
Turnout(7),
Turnout(8),
Turnout(9),
Turnout(10),
Turnout(11),
Turnout(12)
};
//
// Table of all defined semaphores
//
const int nrOfSemaphores = 7;
Semaphore semaphores[nrOfSemaphores] = {
//------------------- Semaphore 55 on controller 2 --------------------------//
Semaphore(CONTROLLER(2), SEMAPHORE(55), NO_STOP_DELAY,
new Route(TURNOUT(10),
new Route(TURNOUT(11), // Turnout 10 straight
new Route(SEMAPHORE(58)), // Turnout 11 Straight
SPEED_HIGH,
new Route(ROUTE_BARRED), // Turnout 11 Diverting
SPEED_STOP),
SPEED_HIGH,
new Route(ROUTE_BARRED), // Turnout 10 diverting
SPEED_STOP),
SEIN46_EENHOOG,
new RGLed(PWM_PIN(13), INTENSITY(255), PWM_PIN(44), INTENSITY(160))),
//------------------- Semaphore 56 on controller 3 --------------------------//
Semaphore(CONTROLLER(3), SEMAPHORE(56), NO_STOP_DELAY,
new Route(TURNOUT(8),
new Route(TURNOUT(9), // Turnout 8 straight
new Route(SEMAPHORE(60)), // Turnout 9 straight
SPEED_MIDDLE,
new Route(TURNOUT(10), // Turnout 9 diverting
new Route(ROUTE_BARRED), // Turnout 10 straight
SPEED_STOP,
new Route(TURNOUT(11), // Turnout 10 diverting
new Route(SEMAPHORE(58),SPEED_LOW,DANGER),
SPEED_LOW,
new Route(ROUTE_BARRED),
SPEED_STOP),
SPEED_LOW),
SPEED_LOW),
SPEED_HIGH,
new Route(ROUTE_BARRED), // Turnout 8 diverting
SPEED_STOP),
SEIN46_EENHOOG,
new RGLed(PWM_PIN(4), INTENSITY(18), PWM_PIN(5), INTENSITY(20))),
//------------------- Semaphore 57 on controller 3 --------------------------//
Semaphore(CONTROLLER(3), SEMAPHORE(57), NO_STOP_DELAY,
new Route(TURNOUT(8),
new Route(ROUTE_BARRED), // Turnout 8 straight
SPEED_STOP,
new Route(TURNOUT(9), // Turnout 8 diverting
new Route(SEMAPHORE(60)), // Turnout 9 straight
SPEED_LOW,
new Route(TURNOUT(10), // Turnout 9 diverting
new Route(ROUTE_BARRED), // Turnout 10 straight
SPEED_STOP,
new Route(TURNOUT(11), // Turnout 10 diverting
new Route(SEMAPHORE(58),SPEED_LOW,DANGER),
SPEED_LOW,
new Route(ROUTE_BARRED),
SPEED_STOP),
SPEED_LOW),
SPEED_LOW),
SPEED_LOW),
SEIN46_EENHOOG,
new RGLed(PWM_PIN(6), INTENSITY(5), PWM_PIN(7), INTENSITY(6))),
//------------------- Semaphore 58 (Dummy) ----------------------------------//
Semaphore(58),
//------------------- Semaphore 60 (Dummy) ----------------------------------//
Semaphore(60),
//------------------- Semaphore 66 on controller 1 --------------------------//
Semaphore(CONTROLLER(1), SEMAPHORE(66), NO_STOP_DELAY,
new Route(Turnout(2),
new Route(TURNOUT(3), // Turnout 2 straight
new Route(SEMAPHORE(55), SPEED_MIDDLE),// Turnout 3 straight
SPEED_HIGH,
new Route(TURNOUT(4), // Turnout 3 diverting
new Route(ROUTE_BARRED), // Turnout 4 straight
SPEED_STOP,
new Route(TURNOUT(5), // Turnout 4 diverting
new Route(SEMAPHORE(56)), // Turnout 5 straight
SPEED_MIDDLE,
new Route(SEMAPHORE(57)), // Turnout 5 diverting
SPEED_LOW),
SPEED_MIDDLE),
SPEED_MIDDLE),
SPEED_HIGH,
new Route(ROUTE_BARRED), // Turnout 2 diverting
SPEED_STOP),
SEIN46_DRIEHOOG,
new RGBLed(PWM_PIN(2),INTENSITY(18),PWM_PIN(3),INTENSITY(15),PWM_PIN(4),INTENSITY(9)),
new RGBLed(PWM_PIN(5),INTENSITY(20),PWM_PIN(6),INTENSITY(22),PWM_PIN(7),INTENSITY(9)),
new RGBLed(PWM_PIN(8),INTENSITY(21),PWM_PIN(9),INTENSITY(14),PWM_PIN(10),INTENSITY(9))),
//------------------- Semaphore 67 on controller 3 --------------------------//
Semaphore(CONTROLLER(3), SEMAPHORE(67), DELAY_STOP,
new Route(TURNOUT(4),
new Route(TURNOUT(5), // Turnout 4 straight
new Route(SEMAPHORE(56)), // Turnout 5 straight
SPEED_HIGH,
new Route(SEMAPHORE(57)), // Turnout 5 diverting
SPEED_LOW),
SPEED_HIGH,
new Route(ROUTE_BARRED), // Turnout 4 diverting
SPEED_STOP),
ARMSEIN_VERTAKKING,
new ArmServo(PWM_PIN(11), 25, 104, 66),
new ArmServo(PWM_PIN(12), 23, 50, 93),
new WhiteLed(PWM_PIN(13), INTENSITY(60))), // (blok 14)
};
//
// A function that executes whenever data is received from the bus
// this function is registered as an interupt event, see setup()
// It's purpose is to analyze the received event (Signal or turnout) and
// update the proper element in the semaphore table or turnout table.
//
void receiveI2CEvent(int howMany)
{
unsigned int x = Wire.read(); // receive byte as an integer
unsigned int dccId = x / 2;
unsigned int dccState = x % 2;
//
// Find the proper turnout detector with the matching address
// and sets its state.
//
if (Turnout::updateDirection(dccId, dccState))
{
//
// The dcc id matched a turnout no need to try the semaphores
//
return;
}
else
{
//
// the dcc id didn't match a turnout, so try the semaphores
//
Semaphore::updateState(dccId, dccState);
}
}
//
// Pins used to define the ID of this controller
// It is used to filter out all semaphores which aren't controlled by
// this instance of the SeinController
//
#define PIN_ID_1 51
#define PIN_ID_2 52
#define PIN_ID_3 53
void setup()
{
//
// Based on which pin is connected to ground, the controller ID is established
//
i2cId = 0;
pinMode(PIN_ID_1, INPUT_PULLUP);
pinMode(PIN_ID_2, INPUT_PULLUP);
pinMode(PIN_ID_3, INPUT_PULLUP);
if (!digitalRead(PIN_ID_1)) i2cId = 1;
else if (!digitalRead(PIN_ID_2)) i2cId = 2;
else if (!digitalRead(PIN_ID_3)) i2cId = 3;
//
// Tell the semaphore control where to find its turnouts and semaphores
// and initialize the whole shebang
//
Semaphore::init(i2cId, nrOfTurnouts, turnouts, nrOfSemaphores, semaphores);
//
// Start the I2C communication
//
Wire.begin(I2C_BASE + i2cId); // join i2c bus
Wire.onReceive(receiveI2CEvent); // register event handler
}
void loop()
{
//
// Scan all semaphores for updates in states and routes and change their
// image if necessary
//
Semaphore::loop();
}
De code bevat de volgende configuratie tabellen,
Turnout turnouts[nrOfTurnouts] =
{
Turnout(1), // Wissel met dcc adres 1
…....
};
Deze tabel definieert alle wissels die van belang zijn voor de mogelijke routes die van sein tot sein gevolgd kunnen worden. De definitie van een wissel is simpel, nl. Turnout(dcc adres).
Verder een tabel waarmee alle seinen worden beschreven
Semaphore semaphores[nrOfSemaphores] = {
…...
};
Laten we eens kijken naar de definitie van één Sein
Semaphore(CONTROLLER(1), SEMAPHORE(66), NO_STOP_DELAY,
De leds van dit sein worden aangestuurd door de Arduino met controller id 1(CONTROLLER(1)). Aangezien ik voor de aansturing van de seinen soms veel pwm pinnen nodig heb, gebruik ik meerdere arduino's. Echter ieder arduino moet een volledig beeld hebben van de staat van alle wissels en alle seinen. Alleen de controller van het betreffende sein stuurt uiteindelijk ook de leds of de arm servo's aan. SEMAPHORE(66) geeft aan dat dit sein het DCC adres 66 heeft. NO_STOP_DELAY geeft aan dat het sein onmiddellijk een onveilig beeld geeft na de ontvangst van onveilig van Koploper. Soms wil je dit wat uitstellen zodat het sein iets later pas reageert en niet onmiddellijk als een trein het volgende blok inrijd. Dan kun je DELAY_STOP op geven, dan wacht het sein 1,5 sec voor dat hij het onveilig seinbeeld geeft.
new Route(Turnout(2),
new Route(TURNOUT(3), // Turnout 2 straight
new Route(SEMAPHORE(55), SPEED_MIDDLE),// Turnout 3 straight
SPEED_HIGH,
new Route(TURNOUT(4), // Turnout 3 diverting
new Route(ROUTE_BARRED), // Turnout 4 straight
SPEED_STOP,
new Route(TURNOUT(5), // Turnout 4 diverting
new Route(SEMAPHORE(56)), // Turnout 5 straight
SPEED_MIDDLE,
new Route(SEMAPHORE(57)), // Turnout 5 diverting
SPEED_LOW),
SPEED_MIDDLE),
SPEED_MIDDLE),
SPEED_HIGH,
new Route(ROUTE_BARRED), // Turnout 2 diverting
SPEED_STOP),
Dit beschrijft welke mogelijke routes er zijn vanaf dit sein tot een of meerdere ander seinen en welke snelheidsbeperkingen er gelden op deze route. Er zijn verschillende Route objecten. Route(adres) en Route(adres, snelheid) beschrijven een sein dat bereikt wordt via de actieve route, adres is het dcc adres van het betreffende sein. Als voor een sein ook snelheid is gespecificeerd, dan betekend dat dat de maximum snelheid is waarmee dit sein mag worden benaderd.
Route(adres, route1, snelheid1, route2, snelheid2) beschrijft een wissel. Adres is het dcc adres van het betreffende wissel, route1 is de route die gevolgd wordt als het wissel rechtdoor gaat, route2 is de route voor een afbuigende stand. Snelheid1 is de snelheid waarmee het wissel rechtdoor gaand bereden mag worden, snelheid2 is de snelheid voor een afbuigende stand. Route1 en route 2 kunnen dus weer nieuwe routes zijn over vervolg wissels.
SEIN46_DRIEHOOG,
Type van het sein, in dit geval een Driehoog sein.
new RGBLed(PWM_PIN(2),INTENSITY(18),PWM_PIN(3),INTENSITY(15),PWM_PIN(4),INTENSITY(9)),
new RGBLed(PWM_PIN(5),INTENSITY(20),PWM_PIN(6),INTENSITY(22),PWM_PIN(7),INTENSITY(9)),
new RGBLed(PWM_PIN(8),INTENSITY(21),PWM_PIN(9),INTENSITY(14),PWM_PIN(10),INTENSITY(9))),
Een Driehoogte sein heeft 3 driekleurenleds, boven, midden, laag. Iedere driekleuren led is aangesloten op 3 PWM pinnen (rood, groen en blauw), ieder met een gespecificeerde licht intensiteit.
Tot zover de configuratie. Nu de actieve delen van de schets.
void setup()
{
//
// Based on which pin is connected to ground, the controller ID is established
//
i2cId = 0;
pinMode(PIN_ID_1, INPUT_PULLUP);
pinMode(PIN_ID_2, INPUT_PULLUP);
pinMode(PIN_ID_3, INPUT_PULLUP);
if (!digitalRead(PIN_ID_1)) i2cId = 1;
else if (!digitalRead(PIN_ID_2)) i2cId = 2;
else if (!digitalRead(PIN_ID_3)) i2cId = 3;
//
// Tell the semaphore control where to find its turnouts and semaphores
// and initialize the whole shebang
//
Semaphore::init(i2cId, nrOfTurnouts, turnouts, nrOfSemaphores, semaphores);
//
// Start the I2C communication
//
Wire.begin(I2C_BASE + i2cId); // join i2c bus
Wire.onReceive(receiveI2CEvent); // register event handler
}
In de setup functie worden een aantal zaken geïnitialiseerd. Als eerste wordt de controller id bepaald, in dit geval aan de hand van 3 pinnen, door een van deze pinnen aan gnd te verbinden, is het makkelijk om met de zelfde schets 3 verschillende arduinros te gebruiken. Daarna Semaphore::init(..) verteld de bibliotheek wat de controller id is van deze arduino, hoeveel wissels er zijn en waar de tabel is. Verder hoeveel seinen er zijn en waar de tabel met sein definities is.
void receiveI2CEvent(int howMany)
{
unsigned int x = Wire.read(); // receive byte as an integer
unsigned int dccId = x / 2;
unsigned int dccState = x % 2;
//
// Find the proper turnout detector with the matching address
// and sets its state.
//
if (Turnout::updateDirection(dccId, dccState))
{
//
// The dcc id matched a turnout no need to try the semaphores
//
return;
}
else
{
//
// the dcc id didn't match a turnout, so try the semaphores
//
Semaphore::updateState(dccId, dccState);
}
}
Dit is een interrupt routine die aangeroepen wordt als er over de I2C bus een bericht binnenkomt. Deze routine kan makkelijk vervangen worden door een interrupt routine voor een andere techniek (DCC, CAN-bus etc). Turnout::updateDirection() gaat alle bekendende wissel definities langs en als er een wissel is met het gegeven adres (dccId) dan zal de positie van dit wissel gewijzigd worden naar de stand die in de dccState staat. Als er geen wissel is die overeenkomt met het adres, dan zal de aanroep van Semaphore::updateState() het zelfde doen voor alle bekende seinen.
void loop()
{
//
// Scan all semaphores for updates in states and routes and change their
// image if necessary
//
Semaphore::loop();
}
Door de arduino loop functie wordt continu Semaphore::loop(..) aan geroepen. Deze bibliotheek functie checkt continu de staat van alle wissels en seinen en past het seinbeeld aan als dat nodig is.
Dit was het voor dit moment, ik hoop dat het duidelijk genoeg is en bruikbaar.
Groet Meino
-
Leuk om te zien hoe hard je bezig bent! (y) Vooral het CAN deel vind ik erg interessant :)
Paar random opmerkingen. Geen enkele opmerking is slecht bedoelt! (y) Ook al kan het over komen als gezeur ::)
Alleen een Mega gebruiken voor het aantal PWM pinnen lijkt me beetje overkill. Ding is nogal groot en lomp. Heb je er ook over gedacht om iets als een PCA9685 te gebruiken? Goedkoop, I2C, 16 kanalen en 12-bit (komt fading ten goede).
En zo te zien gebruik je niet de Arduino IDE voor eht schrijven van de code ;D Nogal heftige indentatie zo :P Waar schrijf / compile jij mee?
En qua code, het is inderdaad C++. Weet je dan ook dan het gebruik van macro's voor pin definities als slecht wordt gezien? :angel: Mooie aan C++ is juist dat er type safe alternatieven zijn.
Ook valt me op dat je een beetje de Arduino gekte met betrekking tot het altijd gebruiken van int hebt opgepikt. Ik denk dat op veel plekken een byte / uint_8 of in ieder geval een unsigned type logischer is. Lijkt me sterk dat je -300 als 'nrOfTurnouts' zou willen gebruiken ;D
Mag ik vragen hoe je de PWM hebt inverted? Doe je gewoon analogWrite(pin, 255 - x)? Er zit namelijk een kleine valkuil / rariteit in analogWrite(). Bij gebruik van de hardware PWM kan je namelijk nooit een duty cycle van 100% krijgen en zit je vast op 255/256. Omdat men dit als raar zag (mensen verwachten 100% duty) doet Arduino:
void analogWrite(uint8_t pin, int val)
{
else if (val == 255)
{
digitalWrite(pin, HIGH);
}Gevolg is dus dat de PWM van 254/256 naar 256/256 gaat, een stap van 2 dus. Geen probleem als dat de maximale waarde aan geeft maar jammer als dat juist het onderste bereik van je led is waar dit goed op valt.
Timo
-
Hoi Timo
nee hoor, het is altijd goed om te horen hoe een ander er tegenaan kijkt. Dat ik een mega gebruik is gewoon omdat ik niet meer weet. Mijn achtergrond is puur software, van PIC's en dergelijke weet ik, buiten het feit dat ze bestaan, niets. Verder kosten die dingen zo weinig dat ik niet de moeite neem om kleinere alternatieven te vinden. Alhoewel ik nu toch er over na denk om Arduino Nano's te gaan gebruiken voor bepaalde functionaliteit.
Toen ik met Arduino's begon, was dat ook omdat het makkelijk was met een simpele IDE en geen gedoe met configuren van cross compilers en Makefiles.
Tot nu toe red ik me met de Arduino IDE aangevuld met notepad. Wel denk ik iedere keer na een exercitie zoals dit dat ik toch maar Netbeans (mijn preverente IDE voor Java) ga optuigen voor Arduino ontwikkelwerk. Maar dat is er tot nu toe nog niet van gekomen.
Wat je zegt over macro's kan wel zijn dat dat als slecht wordt gezien, maar dat zit gewoon in mijn systeem, net als het gebruik van int's. Lang geleden was ik assembler programmeur (IBM 360, Sperry Univac 9000-90 serie) daar heb ik het gebruik van macro's geleerd. Toen ik in '83 in het Unix kamp verzeild raakte, was dat ook in C de methode om standaard zaken dmv defines en complete functies definities vast te leggen.
Het hele gedoe rondom de grootte van een int is ook langs mij heen gegaan. Toen ik in de Unix wereld terecht kwam, waren de systemen waar wij op werkten gebaseerd op motorola 68020-68040 met VME bus, later in Berkeley kwamen daar Sun Sparc's en intel systemen bij, allemaal 32 (en later 64) bit systemen, dus de grootte van een int (minimaal 32 bit) was niet zo belangrijk, zolang je maar wist dat de maximale waarde groot genoeg was voor je toepassing. Als we echt iets wilden afdwingen gebruikten we byte, short, long of long long. Overigens was dat vaak alleen het geval als je met memcpy of menset aan de gang moest gaan. Vanuit die achtergrond let ik dus absoluut niet op geheugen beslag, ook een reden om Mega's te gebruiken - die hebben 256kb aan boord, Als je in 4kb of 8kb iets aan de praat wilt krijgen, zul je wel op dat soort zaken moeten letten.
Overigens gebruik ik in een aantal situaties -1 als adres om het systeem iets te laten weten (ROUT_BARRED is -1).
Ik gebruik de inverted PWM inderdaad op de simpele manier, maar ik probeer de voorloop weerstanden voor de led's zodanig te kiezen dat ik voor de PWM waardes ergens in het middengebied uit kom. Omdat de stapjes voor PWM lineair zijn (als je van waarde 1 naar waarde 2 gaat, dan verdubbeld de licht intensiteit). Eigelijk zou ik een gamma functie daar voor willen hebben. Ik heb nog gekeken of het makkelijk was om een PWM implementatie met een hogere resolutie te bouwen, maar dat uiteindelijk niet gedaan. Vandaar.
Groet Meino
-
Arduino IDE voor eht schrijven van de code
Dat iemand daar mee kan werken.. ??? ??? ??? ???..
Ik gebruik Sloeber, is Eclipse based met alle voordelen (zoals code completion).
http://eclipse.baeyens.it/
Heb er de ESP8266 ook onder zitten en de STM32 ook.
Vanuit Sloeber kun je gewoon flashen en al..
Als je dan nog clang gebruikt wordt de code geformat naar standaard, en die standaard kun je zelf aanpassen.
Clang formater is onderdeel van https://llvm.org/
Ik denk dat op veel plekken een byte / uint_8 of in ieder geval een unsigned type logischer is.
Een Atmel is een 8 bits processor, dus alles wat je byte / uint8_t kunt doen DOEN....
16 Bits is gelijk meer code, en uint32_t en float is eigenlijk not done op een 8 bits...
aantal situaties -1 als adres om het systeem iets te laten weten (ROUT_BARRED is -1).
Return een bool / enum van die functie, en geef de waarde die je wilt lezen als pointer mee in functie.
Mvg
Robert
-
Dat iemand daar mee kan werken.. ??? ??? ??? ???..
Robert ik heb het vak geleerd in de tijd van ponskaarten en teletypes. Later kregen we groene (of oranje) schermen met 24 regels van 80 posities. Dat was echt high tech (3270, VT100, UTS200 etc). X11 terminals met xterm was nog weer later. Kortom ik heb het een en ander zien veranderen, dus de Arduino IDE daar kan ik wel mee overweg.
Met vriendelijke groet
Meino
-
Wissel 1 staat rechtdoor, sein en wissel mogen met 120km/u gepasseerd worden, voor het perronspoor geldt een maximum van 80km/u.
Stop voor sein 2 seinbeeld sein 2: rood-zwart-zwart
Doorrijden sein 2, doorrijden sein 4 seinbeeld sein 2: groen-groen-wit
Doorrijden sein 2, stop sein 4 seinbeeld sein 2: geel-wit-wit
…
Wissel 1 rechtsaf, wissel 2 linksaf , sein en wissel mogen met 60 km gepasseerd worden wat ook geldt voor het perronspoor.
Stop voor sein 2 seinbeeld sein 2: zwart-rood-zwart
Doorrijden sein 2, doorrijden sein 6 seinbeeld sein 2: wit-groen-wit
Doorrijden sein 2, stop sein 6 seinbeeld sein 2: wit-geel-wit
…
Wissel1 rechtsaf, wissel2 rechtsaf, sein en wissel mogen met 60km/u gepasseerd worden, voor het volgende wissel en spoor geld een limiet van 40km/u.
Stop voor sein 2 seinbeeld sein 2: zwart-zwart-rood
Doorrijden sein 2, doorrijden sein 8 seinbeeld sein 2: wit-groen-groen
Doorrijden sein 2, stop sein 8 seinbeeld sein 2: wit-geel-wit
De drie stop seinbeelden mogen ook vervangen worden door een beeld nl. rood-zwart-zwart, ...
Klopt dat wel? Vóór elke lamp waren slechts drie kleuren mogelijk. Dus de drie stop-seinbeelden moeten vervangen worden door één beeld nl. zwart-zwart-rood. Want bij de onderste lamp is geen Geel nodig.
-
Of het klopt, dat weet ik niet. Ik ben in het bezit van de Kilometer kampioen uit 1954, aan het eind daarvan staan alle seinbeelden met hun betekenis, wat overeenstemde met de beschrijving op de site van seinarm (http://www.seinarm.nl). Kortom dat is wat ik geimplementeerd heb.
Groet Meino
-
Dat boek heb ik ook. Het is mijn eerste treinenboek. Op de site van seinarm staat een tabel met de tien mogelijke seinbeelden. Onder die tabel staat het volgende:"Van de tien seinbeelden kunnen er per driehoogtesein maar negen weergegeven worden (drie lampen met elk een kleurenbril voor drie standen)."
Het gedeelte tussen haakjes moet niet overgeslagen worden. Dat er maar negen seinbeelden weergegeven konden worden, houdt verband met het rode licht dat noodzakelijk ergens een plek moet hebben. Dus één van de standen 2 t/m 10 in de tabel moet vervallen. Op een andere plaats op dit forum staat een foto van zo'n kleurenbril.
-
Ok, dat was niet echt doorgedrongen. Ik heb nog even op de site van seinarm de situatie bij Blauwkapel bestudeerd en begrijp nu wat je bedoeld. Je ziet dat het rode licht niet echt een vaste plaats heeft. Ik ga kijken of dat te implementeren is. Het is wel een complex seinstelsel, want een driehoogte sein kan dan 9 seinbeelden weergeven, maar dat is een subset van de 12 mogelijke kleurcombinaties. Dus de seinbeelden die twee driehoogte seinen kunnen tonen zullen onderling afwijken (ieder driehoogte sein heeft zijn eigen unieke set van 9 seinbeelden).
Groet Meino
-
Naar aanleiding van de informatie van Martin, heb ik iets aangepast. Dat heeft te maken met de positie van het rode licht, dat niet op ieder lamp kan voorkomen. Aangezien de kleurwisselaar slechts 3 glazen heeft. Als een lamp rood moet tonen, zal een van de andere kleuren moeten vervallen. In de praktijk toont die lamp rood welke een van de andere kleuren (meestal geel of wit) niet hoeft te tonen. In het voorbeeld is dat de onderste lamp omdat die nooit geel toont.
(https://images.beneluxspoor.net/bnls/Seinen1.jpg) (https://images.beneluxspoor.net/bnls/Seinen1.jpg)
Wissel 1 staat rechtdoor, sein en wissel mogen met 120km/u gepasseerd worden, voor het perronspoor geldt een maximum
van 80km/u.
Stop voor sein 2 seinbeeld sein 2: zwart-zwart-rood
Doorrijden sein 2, doorrijden sein 4 seinbeeld sein 2: groen-groen-wit
Doorrijden sein 2, stop sein 4 seinbeeld sein 2: geel-wit-wit
(https://images.beneluxspoor.net/bnls/Seinen2.jpg) (https://images.beneluxspoor.net/bnls/Seinen2.jpg)
Wissel 1 rechtsaf, wissel 2 linksaf , sein en wissel mogen met 60 km gepasseerd worden wat ook geldt voor het
perronspoor.
Stop voor sein 2 seinbeeld sein 2: zwart-zwart-rood
Doorrijden sein 2, doorrijden sein 6 seinbeeld sein 2: wit-groen-wit
Doorrijden sein 2, stop sein 6 seinbeeld sein 2: wit-geel-wit
(https://images.beneluxspoor.net/bnls/Seinen3.jpg) (https://images.beneluxspoor.net/bnls/Seinen3.jpg)
Wissel1 rechtsaf, wissel2 rechtsaf, sein en wissel mogen met 60km/u gepasseerd worden, voor het volgende
wissel en spoor geld een limiet van 40km/u.
Stop voor sein 2 seinbeeld sein 2: zwart-zwart-rood
Doorrijden sein 2, doorrijden sein 8 seinbeeld sein 2: wit-groen-groen
Doorrijden sein 2, stop sein 8 seinbeeld sein 2: wit-geel-wit
Om dit te laten gebeuren, heb ik de bibliotheek aangepast en een aantal extra parameters toegevoegt.
Deze parameters vertellen de bibliotheek welke lamp rood bevat, zodat de correcte lamp geselecteerd wordt om een stop beeld te tonen. Welke lamp dit is, moet van situatie tot situatie zelf bepaald worden aan de hand van de seinbeelden die getoond kunnen worden. Selecteer dan een lamp die een van de 3 andere kleuren (groen, geel of wit) niet zal tonen, dit zal vaak een lamp zijn die geen geel toont.
SEIN46_DRIEHOOG,
Type van het sein, in dit geval een Driehoog sein.
new RGBLed(PWM_PIN(2),INTENSITY(18),PWM_PIN(3),INTENSITY(15),PWM_PIN(4),INTENSITY(9)),
new RGBLed(PWM_PIN(5),INTENSITY(20),PWM_PIN(6),INTENSITY(22),PWM_PIN(7),INTENSITY(9)),
new RGBLed(PWM_PIN(8),INTENSITY(21),PWM_PIN(9),INTENSITY(14),PWM_PIN(10),INTENSITY(9), RED_ON, GREEN_ON, YELLOW_OFF, WHITE_ON)),
Definitie van de drie lampen, waarbij de onderste voor het tonen van rood wordt gebruikt. De definities voor RED_ON, RED_OFF etc ,zijn bools waarbij voor het gemak correcte #defines in de bibliotheek aanwezig zijn.
Groet Meino
-
Ok, het is tijd om de draad weer op te pakken. Het idee is om de automatisering te distribueren over een aantal afzonderlijke systeempjes, welke onderling d.m.v. een Can bus met elkaar communiceren. Zie onderstaand schema;
(https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V2.jpg) (https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V2.jpg)
Ondertussen zijn de bestelde Can-bus interface kaartjes aangekomen uit China, type "MCP2515 CAN Bus Modul mit TJA1050 Transceiver"
(https://images.beneluxspoor.net/bnls/TMC2515.jpg) (https://images.beneluxspoor.net/bnls/TMC2515.jpg)
Omdat ik voor dat ik de code van de bestaande systemen ga aanpassen, het een en ander wil uitproberen, een testopstelling gemaakt met twee arduinos die ik nog had liggen.
(https://images.beneluxspoor.net/bnls/Testplankje.jpg) (https://images.beneluxspoor.net/bnls/Testplankje.jpg)
Het plan is om een bibliotheek te maken waarmee een systeem op een simpele manier via de Can-bus kan praten met de andere systemen aan de bus. Dat zal gaan gebeuren d.m.v een "Producer-Consumer Communication" model. Omdat misschien niet iedereen weet wat dat betekent, een kleine uitleg.
Een veel gebruikte manier om systemen met elkaar te laten praten is het "Sender-Receiver Communication" model (sorry voor de Engelse termen, maar als ik dat vertaal wordt het misschien te verwarrend). In dit model zullen twee systemen direct met elkaar praten, dat betekend dat de zender van een bericht, dat bericht adresseert met een adres van een specifieke ontvanger. Kortom de zenders van berichten (de Producers) moet voor ieder bericht weten naar wie het gestuurd moet worden. Dit is analoog met iemand die een brief of eMail naar iemand anders stuurt, dat moet ook een adres krijgen, anders komt het niet aan. Een potentieel nadeel is, dat je voor verschillende situaties de systemen moet kunnen configureren met de correcte adressen.
Een "Producer-Consumer Communication" model werkt anders. Denk aan de dorpsomroeper die op het centrale plein zaken omroept, of een bakker die d.m.v zijn hoorn dorp/stadje verteld dat de broden uit de oven zijn. In dit model weet een zender (de Producer) niet wie een bepaald bericht gaat afhandelen. hij zet het bericht gewoon op de bus en ieder ander systeem aan de bus, leest dat bericht en als die weet hoe dat bericht moet worden afgehandeld dan doet hij dat. Het voordeel van dit systeem is dat de zenders (producers) en ontvangers (consumers) niet geconfigureerd hoeven te worden met adresgegevens van de andere systemen.
Wat wel moet gebeuren is een strakke definitie van de verschillende type berichten die op de bus gepubliceerd worden zodat zenders en ontvangers daar duidelijkheid over hebben. Verder moet de bus deze techniek ook ondersteunen, wat Broadcasting heet. De Can-bus ondersteund dit, zoals ook Ethernet dit ondersteund.
Tot zover, ik ga nu aan de slag met de test opstelling
Groet Meino
-
Nu de eerste testen, die zien er goed uit.
Ik heb vanuit Github de volgende bibliotheek https://github.com/coryjfowler/MCP_CAN_lib (https://github.com/coryjfowler/MCP_CAN_lib) opgehaald, en de CAN_send en CAN_receive voorbeelden op de arduino's gezet. Wel moest ik nog een kleine aanpassing doen, beide voorbeelden gaan uit van een 16Mhz klok op de MCP2515, toevallig had ik gelezen dat de bewuste kaartjes een 8Mhz klok hebben, dus dat wel eerst aangepast. Dat werkte probleemloos. We viel het me op dat als de receiver niet aanstond, dat dan de zender op ieder bericht een fout gaf. Dus toch maar eens op zoek naar documentatie (Ja je bent natuurlijk een eigenwijze software man, dus eerst proberen voordat je het manual gaat opzoeken en lezen). Dat gedrag bleek normaal te zijn bij de CAN-bus.
Een heel goede beschrijving vond ik op Wikipedia (https://en.wikipedia.org/wiki/CAN_bus).
Daar uit blijkt dat deze communicatie techniek primair ontwikkeld is om een hoge betrouwbaarheid te realiseren in een electrisch vuile omgeving. Verder is het masterloos, dus geen master die transmissie slots toewijst. Iedere node op de bus heeft de zelfde rechten. In de basis is alle communicatie op een "Producer-Consumer communication" protocol gebaseerd waarbij berichten gekenmerkt worden door een 11 of 29 bit grote ID en niet door een adres van de zender of de ontvanger. De maximale informatie die in een bericht geplaatst kan worden is 8 bytes. Verder bij 1Mbit transmissie is de maximale buslengte 40m en een maximale buslengte van 100m bij een transmissie snelheid van 500Kbit. Dat is meer dan voldoende voor de toepassingen waar ik nu mee bezig ben.
Groet Meino
-
De eerste testen zagen er goed uit. Dat was met de voorbeeld programmaatjes van de bibliotheek. Dus een eigen bibliotheek geschreven, toegespitst op de toepassing. Helaas kwamen er toen problemen. Zolang een Arduino+MCP2515 als een pure zender en de andere Arduino+MCP2515 als een pure ontvanger werden gebruikt, liep alles als een zonnetje. In die combinatie werden er ongeveer 950-1000 berichten per seconde verwerkt (de limiet wordt bepaald door de verwerkingstijd op de MCP van 1 millsec per bericht).
Maar toen ik beide Arduino's tegelijkertijd liet zenden ontstonden er grote problemen in de vorm van berichten die door de Arduino niet uit de MCP gelezen werden. Kortom veel berichten kwamen niet aan in de Arduino.
Daarna met timers geprobeerd de hoeveelheid berichten te reduceren, Pas bij een reductie tot ongeveer 10 berichten per seconde begon het betrouwbaar te worden. Dit beviel me niet, dus iets anders geprobeerd, nl een extra MCP bordje aan de Arduino, zodat 1 als zender en 1 als ontvanger wordt gebruikt. Dit verbeterde de situatie aanmerkelijk. Op dit moment kan ik in deze constructie ongeveer 170-200 berichten per seconde betrouwbaar zenden (dus een totaal op de bus van 340-400 berichten/sec).
Wel ben ik overgegaan op een andere bibliotheek, nl. https://github.com/autowp/arduino-mcp2515 (https://github.com/autowp/arduino-mcp2515). Deze bibliotheek is een ietsje efficienter en betrouwbaarder dan de bibliotheek waarmee it begon.
Een ding dat ik ontdekte, is dat het gebruik maken van de interrupt pin (die de MCP2515 laag trekt bij ontvangst van een bericht) niet bevorderend is voor de betrouwbaarheid. Communicatie met de MCP2515 vindt plaats via de SPI bus en dat is een betrouwbaardere methode om binnenkomende berichten te detecteren dan de interrupt pin. Daarom gebruik ik deze pin niet meer.
Ik ga dus nu verder volgens het volgende schema
(https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V3.jpg) (https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V3.jpg)
Groet Meino
-
Even nog iets. Al deze testen zijn gedaan met standaard bordjes uit China. Daarop wordt de MCP2515 aangestuurd op 8Mhz. Ik ben van plan om deze 8Mhz kristallen te vervangen door 16 of 20MHz kristallen om te kijken hoe groot het verschil is.
Groet Meino
-
Nu de grote verbouwing is begonnen, is het is tijd om weer iets te laten zien. Alhoewel het allemaal goed werkte, vond ik de verzameling draad die zich onder de baan heeft verzameld toch wat minder.
(https://images.beneluxspoor.net/bnls/20181220_221127_DSC_0727.jpg) (https://images.beneluxspoor.net/bnls/20181220_221127_DSC_0727.jpg)
Dus het overgaan op de Canbus biedt ook de gelegenheid om dit netter te doen.
Het plan is om dat volgens het volgende schema te gaan doen
(https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V3_1.jpg) (https://images.beneluxspoor.net/bnls/Overzicht-Kranenberg-Controllers-V3_1.jpg)
Er zijn twee overgangen tussen de klassieke DCC omgeving, de DCC-Interface en de S88-Interface.
De DCC-Interface converteert alle DCC commando's (snelheid- en accessory commando's) naar simpele Canbus berichten. De S88-Interface doet dat de andere kant op, alle ontvangen bezetmelder berichten worden omgezet naar de S88 shiftregister. Dit zijn unieke systemen die slechts een keer voorkomen. Alle controllers kunnen vaker voorkomen. Bijvoorbeeld op dit moment plan ik 7 Sein-Controllers.
De ombouw ga ik in fasen doen. Ik begin met het overzetten van alle seincontrollers naar de Canbus. Daarvoor heb ik de DCC-Interface en een aantal Sein-Controllers nodig.
De DCC-Interface (https://images.beneluxspoor.net/bnls/20181220_220646_DSC_0723.jpg) (https://images.beneluxspoor.net/bnls/20181220_220646_DSC_0723.jpg)
en de Sein-Controller (https://images.beneluxspoor.net/bnls/20181220_221016_DSC_0726.jpg) (https://images.beneluxspoor.net/bnls/20181220_221016_DSC_0726.jpg)
Dat biedt gelijk de mogelijkheid om deze vlak bij de seinen te plaatsen.
(https://images.beneluxspoor.net/bnls/20181218_113206_DSC_0733_1.jpg) (https://images.beneluxspoor.net/bnls/20181218_113206_DSC_0733_1.jpg)
Dit is het even voor nu.
Groet Meino
-
vond ik de verzameling draad die zich onder de baan heeft verzameld toch wat minder.
:) Herkenbaar
Nav seindecoder, kun je niet gebruik maken van een 328Pro Mini / Nano boardjes, zo'n ding van Ali of zo voor 2 dollar...
Board wat je nu gebruikt lijkt me wat overkill :)
Dan kun je met Eagle oid zelf printje maken en in China voor weinig bestellen ....
Beperkt ook de kabel salade rond de seindecoder en de losse printen, die losse CAN print en Mega328 zet je dan gewoon op eigen printje..
Mvg
Robert
-
Dag Robert
Ik weet dat, maar ik heb zelf absoluut geen ervaring met printjes en Eagle.
Maar belangrijker is, dat ik een Arduino met minimaal 9 PWM pinnen nodig heb. Veel van de seinen zijn driehoogte seinen uit het stelsel 46. Bij de driehoogte seinen heb ik per lamp een driekleuren led. Het vervelende is, is dat er best wel wat variatie in de lichtintensiteit zit tussen de ledjes onderling. Dat is geen probleem als je alleen de primaire kleur (rood, groen of blauw) moet tonen. Maar in dit seinstelsel moet ik ook twee mengkleuren gebruiken, geel en wit. Het vervelende is dat als je bijv. voor geel, rood en groen mengt, dan krijg je een tint die vaak te groen, of te oranje is. Dat hangt van het spectrum van de led en de onderlinge intensiteit af. Om de kleuren van ieder lamp apart op elkaar af te stemmen, moet ik iedere led-kleur apart in zijn intensiteit kunnen regelen, verder bij de mengkleuren moet ik ook de onderlinge menging kunnen regelen om een goede tint te krijgen. Met PWM pinnen is dat allemaal perfect te doen. Maar 3x3 kleurtjes zijn dus 9 PWM pinnen. Vandaar de Mega. O ja, wat ik bijna nog vergeet, ik heb ook nog 4 pinnen voor SPI nodig om met de MCP2515 te kunnen communiceren. 3 van de 4 SPI pinnen hebben een vaste definitie, Op de Uno bijt dat bijv. met een paar PWM pinnen.
Om de bekabeling toch een beetje in de hand te houden, monteer ik iedere Arduino met de ondersteunende hardware (MCP2515, DCC bordje etc) op een stukje spaanplaat, dat ik verder als een eenheid onder de baan schroef. Overigens, qua kosten denk ik dat het niet zoveel uitmaakt, ik heb net weer een paar Mega's besteld voor 6 euri per stuk. Misschien dat een ander bordje wat goedkoper is, maar dan heb je toch ook weer kosten voor een PCB.
Groet Meino
-
Nog even wat meer, de CanBus bestaat uit twee aders die in elkaar gedraaid zijn. Verder combineer ik de Canbus draden ook met een ringleiding voor 5V, waar ik alle systemen, seinen, servo's etc van spanning kan voorzien.
(https://images.beneluxspoor.net/bnls/CanBus.jpg) (https://images.beneluxspoor.net/bnls/CanBus.jpg)
Groet Meino
-
Meino,
Ik heb op mijn ATtiny2313 8 pwm uitgangen (1 timer, 8 uitgangen software gestuurd, 8MHz), dus op een Arduino moet dat ook fluitend gaan. Een print maken is niet al te moeilijk als je het een paar keer hebt gedaan. En als je het niet durft kan je de vraag hier in je draadje stellen. Ik zelf heb regelmatig printen gemaakt voor anderen dus ook dat hoeft geen probleem te zijn. Overigens als je i.p.v. Eagle Kicad gebruikt dan is het zelfs gratis.
Dus als software man neem die uitdaging eens aan.
Groet,
Gerard van der Sel.
-
Dag Gerard
Met software gestuurde pulsjes op een digitale pin heb ik wat problemen gehad. Dit werd veroorzaakt door interrupt afhandeling voor andere functionaliteit. Dus ben ik wat huiverig om dat ook voor PWM te gaan doen. Nu is het wel zo dat de interrupts die de handel verstoorden (I2C en DCC) nu niet meer gebruikt worden, dus zou ik het kunnen proberen. Voor de huidige Seincontrollers ga ik geen boardjes meer maken, dat laat ik zoals het is, een houtje touwtje constructie, dat vind ik zelf goed genoeg. Maar voor de volgende fase (bezetmelders) zit ik daar wel aan te denken, daar heb ik toch 6 nieuwe Arduino's voor nodig, en dat kunnen Nano's zijn. Maar dat is voor volgend jaar, want dat wordt een grote klus omdat ik dan alle voedingskabels onder de baan wil gaan vervangen door een aantal ringleidingen.
Maar jullie beiden bedankt voor het advies.
Groet Meino
-
Nee, van die interrupts heb je inderdaad geen last meer, maar SPI wel, of ga je die pollen (We zien het wel in de code verschijnen.).
Groet,
Gerard van der Sel.
-
Dus ben ik wat huiverig om dat ook voor PWM te gaan
Is een WS2812 mini led geen optie voor nieuwe signalen?
Link als voorbeeld
https://www.sparkfun.com/products/11821
Dat zijn van die RGB ledjes die je met één stuur signaal en massa/5V kunt aansturen...
Doorlussen leds is out aan in koppelen...
Even geen idee hoe groot je ruimte is in de seinpaal overigens...
Mvg
Robert
-
@Robert
dat ledje is interessant, helaas nog iets te groot. De ruimte in het lamphuis van deze 3d geprinte seinen is ongeveer 3,2x2,7mm. Tenminste dat is de maat van de ledjes die ik gebruik, die passen net niet, maar als ik van de lamphuis met een scherp mesje iets afschraap, dan past het precies. Deze ledjes hebben een common anode, dus moeten er vier draadjes (0,01mm2) aan vast gesoldeerd worden. Dat is net te doen.
@Gerard
Ik gebruik geen interrupts voor de MSC2515, dat werkte mij niet betrouwbaar genoeg. Ik pol de MCP nu voor ontvangen berichten, dat werkt goed omdat de MCP meerdere berichten buffered.
Groet Meino
-
(https://images.beneluxspoor.net/bnls/20181220_221127_DSC_0727.jpg) (https://images.beneluxspoor.net/bnls/20181220_221127_DSC_0727.jpg)
Precies waarom ik altijd huiverig ben als mensen met een Mega aan de slag gaan ;D
En ben het met Gerard en Robert eens wat betreft printen. En dan zeker met Gerard wat betreft KiCad ;D (zeker met Autidesk's forcering van cloud ::)) Misschien wint je eerste print niet gelijk een schoonheidsprijs of zit er nog een foutje in maar lastig is het niet meer.
Maar belangrijker is, dat ik een Arduino met minimaal 9 PWM pinnen nodig heb.
Misschien een Nano / Pro Mini combineren met een PCA9685 (https://www.aliexpress.com/item/16-Channel-12-bit-PWM-Servo-Driver-I2C-interface-PCA9685-for-arduino-or-Raspberry-pi-shield/32447354314.html) (op een PCB ;D)? Als je ook nog PWM van pin 9 en 10 erbij pakt (namelijk ook als 12-bit te gebruiken) heb je genoeg voor 2 seinen (= 6x RGB). Met als extra voordeel, je hebt 12-bit sturing! Alternatief is de seinen te voorzien van WS2812 ledjes zoals Robert suggereert of de 4020 variant met SK6812 (https://www.aliexpress.com/item/10-3000pcs-SK6812-4020-Side-Emmitting-RGB-LED-Chip-with-built-in-SK6812-IC-SMD-4020/32877531241.html). Ander alternatief is de losse variant, de WS2811 (https://www.aliexpress.com/item/100pcs-pack-DC5V-DC12V-ws2811-IC-led-Circuit-Board-PCB-WS2811-LED-RGB-Pixel-Module-IC/32821263233.html).
En mja, software PWM moet ook nog aardig lukken.
Met software gestuurde pulsjes op een digitale pin heb ik wat problemen gehad. Dit werd veroorzaakt door interrupt afhandeling voor andere functionaliteit. Dus ben ik wat huiverig om dat ook voor PWM te gaan doen.
Zolang je de boel nooit ophoudt is er niets aan de hand (y)
Wat betreft de lichtintensiteit, stuur je het geheel aan met HSV (of een andere kleurruimte met een intensiteit parameter)?
Verder combineer ik de Canbus draden ook met een ringleiding voor 5V, waar ik alle systemen, seinen, servo's etc van spanning kan voorzien.
Tja, dat zou ik niet doen. Dat is vragen voor storing ::) Zeker als je stroomvreters als servo's op dezelfde voeding gooit. Maar ook zonder koppel je dan zo troep in. Beter/stabieler is om een hogere spanning als distributie spanning te gebruiken en lokaal naar beneden te regelen. Voor een uC en seinen kan dit prima lineair maar voor een servo kan je makkelijk een DCDC module pakken.
Ik gebruik geen interrupts voor de MSC2515, dat werkte mij niet betrouwbaar genoeg. Ik pol de MCP nu voor ontvangen berichten, dat werkt goed omdat de MCP meerdere berichten buffered.
Dat is bijzonder. Juist met CAN is een interrupt te verantwoorden en juist daarmee kan je garanderen niets te missen. Dus als dat niet lukt hielt de de uC toch nog ergens opgehouden (waarschijnlijk met interrupts uit). Anders zou juist met een interrupt bedrijfszekerder moeten zijn. (y)
Timo
-
Dag Timo
Precies waarom ik altijd huiverig ben als mensen met een Mega aan de slag gaan ;D
Die spaghetti van kabels heeft weinig te maken met een Mega, maar meer met het idee om alles te centraliseren, een uitvloeisel van de oorspronkelijk analoge aanleg.
Zolang je de boel nooit ophoudt is er niets aan de hand (y)
Nu ik geen I2C en DCC interrupts hoef af te handelen, werkt de reguliere Servo bibliotheek ook goed.
Wat betreft de lichtintensiteit, stuur je het geheel aan met HSV (of een andere kleurruimte met een intensiteit parameter)?
Aangezien de output RGB is (een RGB driekleuren led) heeft het weinig zin om in HSV (Hue,Saturation,Value) te gaan rekenen, omdat je dat daarna weer naar RGB moet omzetten. Dus doe ik het door direct de RGB waarden om te zetten in PWM waarden.
Tja, dat zou ik niet doen. Dat is vragen voor storing ::) Zeker als je stroomvreters als servo's op dezelfde voeding gooit.
Dat begrijp ik, maar het voordeel van Canbus zou juist zijn dat het in een electrisch vuile omgeving (in een Auto) goed blijft werken. Om storing te minimaliseren heb ik wel de twee draden van de Canbus in elkaar gedraaid. Tot nu toe heb ik nog niet gemerkt dat er storing op de Canbus is. Overigens heb ik twee armseinen, aangedreven met servo's, die via de Canbus aangestuurd worden, en dat werkt goed. Wel is het zo, dat ik de servo's met minimale stapjes aanstuur om een langzame beweging van de armen te krijgen.
Dat is bijzonder. Juist met CAN is een interrupt te verantwoorden en juist daarmee kan je garanderen niets te missen. Dus als dat niet lukt hielt de de uC toch nog ergens opgehouden (waarschijnlijk met interrupts uit). Anders zou juist met een interrupt bedrijfszekerder moeten zijn. (y)
Dat dacht ik ook. Maar tijdens de testen die ik gedaan heb, werkte dat niet goed. Achteraf was de voorbeeld code niet goed, later vond ik andere voorbeelden die anders omgaan met de MCP2515 chip. Die chip heeft meerdere buffers, die je apart kunt en moet uitlezen, achteaf gezien deed ik dat waarschijnlijk niet goed. Maar ondertussen had ik al een ander voorbeeld, dat niet gebruik maakte van interrupts, maar dat de chip pollde voor ontvangen berichten, en met die implementatie kreeg ik goede prestaties. Dat heb ik dus nu ook in mijn bibliotheek zitten. Als ik tijd en zin heb, kan ik later misschien nog wel eens proberen of het werken met interrupts (mits goed geimplementeerd) ook kan. Voorlopig ben ik tevreden met hoe het werkt.
Groet Meino
-
Aangezien de output RGB is (een RGB driekleuren led) heeft het weinig zin om in HSV (Hue,Saturation,Value) te gaan rekenen, omdat je dat daarna weer naar RGB moet omzetten. Dus doe ik het door direct de RGB waarden om te zetten in PWM waarden.
Daar mis je het hele voordeel van een kleurruimte zoals HSV. In 99% van de gevallen zal je inderdaad weer RGB uitsturen. Maar HSV maakt het makkelijk om de intensiteit aan te kunnen passen ongeacht de kleur. En ook als je eventueel een fade toepast tussen kleuren is de intensiteit correct constant. En ook is de kleurovergang dan zoals je zou verwachten. Doe je dit puur in RGB heb je dit absoluut niet ;) Vandaar dat HSV daarvoor populair is in bijvoorbeeld de Hue. Ook die zet dat uiteindelijk weer om in RGB voor de ledjes.
Dat begrijp ik, maar het voordeel van Canbus zou juist zijn dat het in een electrisch vuile omgeving (in een Auto) goed blijft werken.[...]
Het gaat me dan ook absoluut niet om de CAN bus ;) Die gaat wel goed ja. Maar de spanning naar de uC en de signalen na de transceiver. Er is een reden dat ze in de auto ook geen 5V transporteren met de CAN-bus en dat ze bij andere industriële toepassingen 12V of 24V transporteren. En ook met lage snelheid is een servo nog een enorme vreter, alleen nu in nog kleinere pulsje...
Timo
-
Dag Timo
Daar mis je het hele voordeel van een kleurruimte zoals HSV. In 99% van de gevallen zal je inderdaad weer RGB uitsturen. Maar .......
Ik begrijp precies wat je bedoelt, Een andere passie van mij is fotografie, daardoor werk ik al vele jaren (>15) met fotobewerkings programma's (Photoshop, Picture Window pro, tegenwoordig hoofdzakelijk met Lightroom). Dus de voordelen van het werken in HSV of HSL ken ik. Maar we hebben het hier over lichtjes in een sein. Dat die niet precies de exacte kleur hebben is niet zo belangrijk. Ik gebruik een klein testprogrammaatje om de RGB leds mee in te stellen, dat doe ik op het oog. Voor deze toepassing is dat goed genoeg. Kijk ik kan natuurlijk de spectrometers, die ik bezit voor het calibreren van mijn scherm en het maken van ICC profielen voor mijn printer, kunnen gebruiken, maar dat vind ik echt waanzin.
Maar de spanning naar de uC en de signalen na de transceiver. Er is een reden dat ze in de auto ook geen 5V transporteren met de CAN-bus en dat ze bij andere industriële toepassingen 12V of 24V transporteren.
Dat begrijp ik, maar we hebben het hier niet over een industriële toepassing, het is maar een treinbaan. Ik gebruik die 5V omdat de meeste subsystemen die ik gebruik (Bezetmelders, DCC interface etc) ook met 5v werken. Die 5V kan ik natuurlijk ook van de Arduino betrekken. maar ik vind het wel makkelijk omdat rechtstreeks uit een 5V gereguleerde voeding te krijgen. Overigens ook S88 heeft een Ground en een 5v voedingslijn om de benodigde zaken van stroom te voorzien. Of deze microservo's grote stroomvreters zijn, betwijfel ik. Ik heb in een andere situatie ook 2 servo's, voor het openen en sluiten van deuren, die ik vanuit een UNO voed, via de 5v pin. Ik weet dat die niet veel stroom kan leveren en dat heeft in de afgelopen 2 jaar geen problemen gegeven. Als ik zie hoe klein het motortje is dat in deze micro servo's zit, kan ik me niet voorstellen dat ze meer dan 150-200 mA trekken en waarschijnlijk minder. Kortom, voor mij is belangrijk dat het werkt en dat het niet voldoet aan eisen voor een industriele omgeving vind ik zelf geen probleem.
Groet Meino
-
Ik begrijp precies wat je bedoelt,
Nouwja, ik denk toch nog niet ;) Het gaat mij er ook niet om dat de absolute kleur klopt. Maar dat de helderheid van de verschillende seinbeelden constant is. En doe je nog een fade tussen de kleuren of gewoon pats-boem? (Weet eigenlijk ook niet hoe het echt ging ook al kan ik me voorstellen dat met kleurlenzen er een snelle fade was.) Ook in het fade geval zorgt HSV er dan voor dat de tussenkleuren correct zijn wat niet zo is bij een simpele lineaire RGB fade. Laatste is misschien niet zo van belang als het snel gaat.
En een extreem makkelijke manier om het toe te passen is door de FastLed library te downloaden. Ja, deze is in zijn geheel voor NeoPixels maar bezit de CRGB class die efficiënt HSV omzet in RGB die je los kunt gebruiken van de rest.
En tuurlijk, even goede vrienden, het is jouw feestje ;D Maar wat ik zeg, ik denk dat je nog steeds mijn punt miste :)
Dat begrijp ik, maar we hebben het hier niet over een industriële toepassing, het is maar een treinbaan.
Dat klopt, maar wel een toepassing met veel storing...
Overigens ook S88 heeft een Ground en een 5v voedingslijn om de benodigde zaken van stroom te voorzien.
Klopt, en dat is ook al jaren een gevoelig systeem. Toegegeven, meeste in de data. Maar op een S88 bus zitten in ieder geval geen zware verbruikers.
Of deze microservo's grote stroomvreters zijn, betwijfel ik. Ik heb in een andere situatie ook 2 servo's, voor het openen en sluiten van deuren, die ik vanuit een UNO voed, via de 5v pin. Ik weet dat die niet veel stroom kan leveren en dat heeft in de afgelopen 2 jaar geen problemen gegeven.
Paar honderd mA zal dat wel zijn in mooie lelijke pieken.
En wat betreft de Uno, dat hangt af hoe je hem voedt. Als je die via USB of 5V voedt is er geen probleem. En vanaf 12V zal je het in dit geval ook niet merken. Probleem is namelijk dat de regulator op een Uno prima grote stromen aan kan. Alleen bij continue belasting de hitte niet weg krijgt. Dus zo af en toe een deur openen ook al kost dat eens 500mA zal hij prima doen. Dus "niet veel stroom kan leveren" is inderdaad wat snel geroepen wordt tegen newbies die er complete schijnwerpers mee willen voeden maar ligt dus iets complexer.
En nogmaals, jouw feestje! (y) Mijn punt is ook niet om er een industrieel systeem van te maken. Maar dit zijn nu typisch van die dingen die van die super intermediate fouten kan opleveren. En dit terwijl het nu nog makkelijk op te lossen is door 12V-ish te gebruiken en wel de spanningsregulator op de Arduino's te gebruiken. Kost niets ;D
Timo
-
Dag Timo
Ik denk dat ik je argumenten wel begrijp. Maar dat is niet belangrijk. Ik heb geen fade-in, fade-out voor deze lichten. Alhoewel deze seinen met gloeilampen waren uitgerust, dus langzaam aan en uit gaan, wordt de echte kleurwisseling met gekleurde lenzen voor de lamp gedaan. Dus de lamp blijft branden tijdens de wisseling, die snel plaatsvind. Ik denk dan ook dat de echte wisseling erg snel ging. Ik zal je eerlijk zeggen dat ik er niet aan gedacht heb en ik ook nu dat nog steeds niet belangrijk vind. Dus ja de kleurwisseling vind direct plaats, zonder overgangen.
Over het stroomverbruik van servo's is niet veel te vinden. Er zijn wat discussies op RC fora, daar bestaat de consensus dat het stroomverbruik van reguliere servo's in de range van 10-15mA in idle mode, 150-250mA als een servo geblokkeerd is, en tussen 50-100 mA tijdens regulier gebruik ligt. Dat gaat dan over grotere servo's dan ik gebruik. Ik ga er vanuit dat de gebruikte microservo's niet meer gebruiken dan deze grotere jongens. Dus denk ik zelf dat het gebruik ergens rond de 50-75mA zal liggen als ze in beweging zijn.
Overigens ik voed de Arduino's rechtstreeks via de 5V pin en niet via Vinn.
Groet Meino
-
Met servo’s moet je oppassen. Het ‘gemiddeld’ stroomverbruik tijdens beweging is laag. Maar als je het stroomverbruik op een scoop bekijkt, dan kan deze zeer hoog zijn tijdens een ‘korte periode’.
Als voorbeeld neem ik van die goedkope blauwe mini servo’s. Deze kunnen tijdens beweging ‘onbelast’ tot 700mA over 3ms stroom uit de voeding wegnemen. Zie onderstaande foto:
(http://users.telenet.be/RedDeBist/MBAAN/beeld%20stroomverbruik%20servo.png)
Eerste piek is referentiepuls (2ms/50Hz), tweede piek is stroomverbruik door servo (spanningsval gemeten over R van 1.0 Ohm)
Mogelijk is het eigen aan dit type servo’s, maar de interne elektronica van deze servo’s zal pas nadat de servo de referentiepuls heeft ingelezen stroom sturen naar de servomotor om deze te laten bewegen.
Dit ter info,
@Meino, mooi project. Ik ben iets gelijkaardigs bezig maar met LocoNet
Geert
-
Prima (y) Jouw feestje. Wilde alleen zeker zijn dat je het punt snapte. En dat ging nu eenmaal niet over de kleurechtheid ofzo. Maar over constante helderheid :)
Maar moet wel zeggen dat je dan een aardige conservatieve site hebt gevonden. Gangbaar is om zo'n 500mA te rekenen tijdens bewegen en zo'n 650-750mA stall. [edit]Geert2 was me net voor ;D Natuurlijk is het gemiddelde een heeeel stuk lager. 50-75mA voor een rustige beweging zou best kunnen. Maar het gaat juist om die pieken die voor de problemen zorgen wat betreft stabiliteit voor uC's. Arduino forum staat dan ook vol met (reset) problemen bij gebruik van servo's. Nogmaals, kan goed gaan maar kan nare problemen geven.
Overigens ik voed de Arduino's rechtstreeks via de 5V pin en niet via Vinn.
Gelukkig, want 5V op Vin werkt niet ;D Bij gebruik van een Uno (en volgens mij is de Mega daarin gelijk) geen USB aansluiten. Maar doelde er dus op dat je "voor niets" op 12V over kunt stappen door wel Vin te gebruiken.
Timo
-
@Geert en @Timo
Bedankt voor de info. De fora waar ik die gegevens vandaan heb zijn fora gewijd aan RC vliegtuigen en die gegevens kwamen van testen gedaan om te bepalen hoelang er gevlogen kon worden. Ik kan me voorstellen dat de initiele piek van 3mSec in dat soort testen geen rol speelt. Overigens in de test van Geert wordt een stuurpuls van 2mS gegeven, dat betekend dat de servo gelijk naar een uiterste stand gestuurd wordt. Ik weet niet wat de stand van de servo was, maar als ik dat met een servo die in een middenstand staat, doe, dan maakt hij wel een heel forse klap. Dus wat is de puls als je slechts 1 stapje doet.
Overigens ik heb een klein filmpje met mijn mobile gemaakt van een driehoogte sein https://www.youtube.com/watch?v=qtjoA2sUvgM (https://www.youtube.com/watch?v=qtjoA2sUvgM).
Groet Meino
-
Dat verklaard het wel ja. En de LiPo's in die dingen vinden pulsen van enkele amps geen enkel probleem.
Naar welke stand je hem stuurt zal voor de stroom weinig uitmaken, alleen voor de duur. Een servo probeert nu eenmaal zo snel mogelijk (dus full power) de juiste stap te behalen. Er zit geen gas op zeg maar. Voor ons lijkt de klap alleen wat groter door de snelheid die de motor behaald.
En blijf die seinen erg leuk vinden! (y) Veel te complex maar wel leuk ;D
Timo
-
Precies waarom ik altijd huiverig ben als mensen met een Mega aan de slag gaan
Moet ook maar weer eens een poging wagen met jouw sketch, Meino.
Gr Koen.
-
@timo
Timo, je gebruikt in je mailtje de termen uC's en LiPo's, kun je me in gewoon Nederlands vertellen wat dat zijn? Ik behoor niet tot de cirkel van ingewijden die dat soort termen kennen.
Groet Meino
-
uC => Microcontroller
LiPo => Lithium ion accu (batterij of voeding)
Groet,
Gerard van der Sel.
-
Ahh, ja, sorry! Als je wat langere reacties schrijft ga je dingen afkorten, uC, LiPo, LoPi etc. Dacht dat ik gezien de diepte van het onderwerp ze wel bekent zouden zijn. Mijn excuses!
Gerard heeft de afkortingen inderdaad al verklaard. Kleine uitleg waarom ze zo zijn.
- uC moet eigenlijk zijn µC zijn, met een mu (https://nl.wikipedia.org/wiki/Mu_(letter)), de afkorting van micro in het SI-stelsel. Maar die µ is altijd even nadenken dus wordt vaak vervangen door een reguliere u.
- LiPo is Lithium-ion-Polymeer accu, een type lithium-ion accu. Ook al wordt er vaak met LiPo dus meer algemeen lithium-ion bedoelt, in de RC wereld zijn echte LiPo's heel gangbaar. Combineren veel energie met het aankunnen van hoge ontlaadstromen.
Timo
-
Gerard en Timo, hartstikke bedankt, weer wat geleerd.
Groet Meino
-
Naar welke stand je hem stuurt zal voor de stroom weinig uitmaken,
Klopt, op het plaatje dat ik poste (hiervoor) zie je een max. stroom van 700mA. Deze is afhankelijk van de weerstand servomotor.
alleen voor de duur. Een servo probeert nu eenmaal zo snel mogelijk (dus full power) de juiste stap te behalen. Er zit geen gas op zeg maar. Voor ons lijkt de klap alleen wat groter door de snelheid die de motor behaald.
Daar twijfel ik over, die 3ms dat er stroom vloeide naar de servo is de maximale tijd na elke referentiepuls. De elektronica in de servo zorgt er voor dat de motor niet oververhit geraakt.
M.a.w. als je plots van 1ms referentiepulsen gaat naar 2ms, dan zal de servo elektronica er voor zorgen dat de servomotor een beperkte tijd stroom krijgt. (Ook al lijkt dit snel te gaan) Je hebt dus meerdere referentiepulsen nodig van 2ms om de juiste stand te bereiken.
Het kan zijn dat dit enkel op de door mij gebruikte servo's zo is?
Ik ga dit is vastleggen op meerdere plaatjes.
Edit: Zal voor volgend jaar zijn, het is oudjaar... ;)
Geert
-
Allereerst nog een goed Oud en Nieuw en de beste wensen voor 2019.
Op de valreep heb ik toch nog eens met mijn multimeter het stroomverbruik op de 5V voeding gemeten (dat is geen piekmeting, dat weet ik). Daar zijn momenteel 5 Arduino's (4xMega, 1xUno) met leds aan gekoppeld. Het verbruik is constant 450-458 mA. Dat betekend dat iedere Arduino ongeveer 75mA trekt. Op het moment dat ik een servo activeer, zie ik tijdens de tijd dat het servo bewoog, dat het gebruik naar ongeveer 600-640mA gaat. Dus een bewegend servo (de kleine blauwe 9g) trekt ergens tussen 160-200 mA tijdens de beweging. Mijn stekkervoeding kan 2A leveren, dus heb ik voorlopig nog capaciteit over
Groet Meino
-
Jullie ook nog de beste wensen! (y)
De elektronica in de servo zorgt er voor dat de motor niet oververhit geraakt.
Of dat echt de elektronica is betwijfel ik, zeker in de kleine/goedkope servo's. Immers als je gewoon een 5V motor hebt kan deze gewoon tegen vol gas en zal deze dit zelf reguleren. Dat je meerdere referentie pulsen nodig hebt om van 1ms naar 2ms te gaan komt puur door hoe lang de servo (door de overbrenging etc) over doet om op volle motorsnelheid de "overkant" te halen en na hoelang de servo stopt met aansturen na het wegvallen van de puls. Dit zorgt ook voor een "ontspannen" servo na het aanroepen van .detach().
@meino, voor de maximale stroom ben ik dan ook absoluut niet bang ;) Spontane resets van uC's wel.
Timo
-
voor de maximale stroom ben ik dan ook absoluut niet bang ;) Spontane resets van uC's wel.
Ik zal er op letten. Tot nu toe heb ik daar nog geen last van.
Groet Meino
-
Nog even een update, ik heb de software voor de seincontroller nog wat aangepast. Voor de armseinen heb ik namelijk een "bounce" toegevoegd. Omdat ik geen bewegende beelden kon vinden, heb ik zelf maar iets bedacht. Op dit moment doe ik het alleen als de arm naar beneden gaat, dan laat ik als het ware de arm vallen. Zie het volgende filmpje van een Versimpeld vertakkingsein (https://www.youtube.com/watch?v=C9giiHsmvIo&t=10s). Als iemand wel een filmpje kent, of weet hoe dit er uitzag, laat me het weten.
Ik heb ook nog een filmpje gemaakt van de werking van een Driehoogtesein, stelsel 46 (https://www.youtube.com/watch?v=O4E56X_gYFg&t=6s).
Groet Meino
-
Zoeken in het Engels levert dit op: https://youtu.be/MPQFi9jJgEo (https://youtu.be/MPQFi9jJgEo)
-
Klaas,
dat videootje had ik ook gevonden. Maar dat is geen NS Armsein en ik weet niet of die op de zelfde manier reageren. Maar in ieder geval nog bedankt.
Groet Meino
-
Schitterend driehoogtesein. (y)
-
Met dank aan Serve, toch wat meer informatie gekregen. Het blijkt dat door de constructie bij NS armseinen vrijwel geen stuiter reacties zijn, alleen bij mechanische bediening kan wat vibratie optreden. Er is wel verschil tussen het gedrag bij mechanische- en electrische bediening. Bij mechanische bediening zal het voorsein arm en vertakkingsein arm in volgorde bewegen (zoals in het eerste filmpje) maar bij een electrische bediening gaan ze tegelijkertijd. Omdat ik in de hoofdbaan gebruikmaak van lichtseinen, en de twee armseinen voor het secundaire spoor gebruik, maar wel bij het station, moet ik er wel van uitgaan dat het geheel electrisch (NX etc) bediend wordt, inclusief wissels. Dus een kleine wijziging in de Arduino schets en het volgende filmpje: Werking Enkelvoudig vertakkingsein (https://youtu.be/5cs4bDIAxYw)
Groet meino
-
Mooi om te zien hoe dat werkt. Staat de bovenste seinarm wel echt horizontaal (bij onveilig)?
-
Dag Martin
hij staat ongeveer horizontaal. Afstelling doe ik via de positie van de servo. Maar er zit best wel wat speling in de aandrijving, dus een kleine afwijking is vrijwel niet te vermijden.
Groet Meino
-
Momenteel heb ik goed werkende implementatie van een CanBus op Kranenberg actief. Het leek me beter om voor de beschrijving daarvoor met een schone lei te beginnen. Daarom een nieuw draadje gestart. Dat draadje is De CanBus komt naar Kranenberg.... (https://forum.beneluxspoor.net/index.php?topic=90291.new#new)
Dit specifieke draadje zal ik waarschijnlijk niet meer gebruiken in de toekomst.
Groet Meino
-
Ik lees dat veel mensen bezig zijn, net als ik, een Arduino te integreren in hun modelspoorbaan. Ik heb een TCO gebouwd met een Mega 2560 om de wissels en de ontkoppelaars mee te bedienen (zie foto). Ik heb de smaak te pakken en wil nu ook de bezetmelder er in betrekken. Ik gebruik Multimaus en heb de N-baan is geautomatiseerd met Koploper. De communicatie met de laptop loopt via een S88XpressNetLI (USB) en gebruik de s88SD16-n bezet melders dit alles van Rosoft. De TCO (de Arduino) is met en RS485-kaartje met XpressNet verbonden.
Het probleem waar ik tegen aanloop is, hoe ik nu de status bezetmelders uitlees met de Arduino. Ik zie in Koploper twee adressen voor een bezetmelder staan, bv: 65.1 en 513. Ik het idee dat de eerste het S88-interface adres is en de tweede de XpressNet representant. Ik heb met verschillende commando's die de Librarie ExpressNet rijk is, geprobeerd de status van de bezetmelders uit te lezen, maar zonder resultaat.
Heeft iemand dit al eens geprobeerd?
Of weet iemand waar voorbeelden van Skeches staan?
Kees.
(https://images.beneluxspoor.net/bnls/20191012_155836_1.jpg) (https://images.beneluxspoor.net/bnls/20191012_155836_1.jpg)
-
Ik vrees dat je de bezetmelders niet kan uitlezen op de xpressnet interface van de multimaus. de S88XpressNetLI zet de bezet meld info enkel op de usb verbinding en niet op de xpressnet interface naar de multimaus.
-
Kees
Hoe is die arduino gekoppeld? en aan wat? Aan de DCC bus, via Xpressnet?
Over bezetmelders, voor zover mijn kennis gaat, gebruikt Koploper S88 voor de bezet melders. In Onderhouden->Baan ontwerp->Onderhouden Digitale onderdelen kun je een aantal bezetmelders opgeven. Let op, dit is niet het aantal echte bezetmelders, maar het aantal S88 shiftregisters dat gebruikt wordt. Ieder shiftregister is 16 bits voor 16 fysieke bezetmelders. Ik heb er 3 gespecificeerd, voor 3x16 bezetmelders. In koploper zie je dan adressen van 1.01-1.16, 2.01-2.16 en 3.01-3.16 In mijn geval bevraagt Koploper via de USB kabel de centrale voor de status en de centrale krijgt via een S88 koppeling de informatie van een Arduino die via een andere Arduino de status van de fysieke bezetmelder krijgt. Koploper zelf kan deze informatie niet zelf via de S88 opduikelen, daarvoor heeft hij de centrale voor nodig. Hoe ik dit nu doe ga ik wat uitgebreider beschrijven in het nieuw gestarte draadje.
Overigens was de oorspronkelijk situatie anders, daar had ik een Mega die wissels, bezetmelders en de S88 koppeling combineerde. Maar die Mega kreeg zijn wissel opdrachten via DCC en de bezetmelder status liep via een S88 kabel naar de Centrale.
Uit de foto maak ik op dat in jou geval de wisselstanden via de knoppen op het paneel worden gezet. Dat maakt eigenlijk niet zoveel uit, belangrijk is dat de centrale de status van de bezetmelders krijgt. Dus weer, waar is Koploper aan gekoppeld, de MultiMaus? en verder wat kan de multimaus met bezetmelders?. Ik gebruik ook een ouder type lokmaus maar die is als slave aan mijn centrale gekoppeld (MDRRC-II).
Een hoop vragen, maar misschien kunnen we er dan wel uit komen. Ik heb schetsjes, maar die gebruiken allemaal S88 om bezetmelder status door te geven.
Groet Meino
-
Ik vrees dat je de bezetmelders niet kan uitlezen op de xpressnet interface van de multimaus. de S88XpressNetLI zet de bezet meld info enkel op de usb verbinding en niet op de xpressnet interface naar de multimaus.
Klopt ! Bezetmeldingen zijn niet te zien op XpressNet.
Grtzz,
Karst
-
Meino,
Ondanks dat Dirk en Karst zeggen dat het niet kan toch antwoord op je vragen.
Bijgaand een schema op hooflijnen van mijn spoorbaan, waarmee ik denk ik al je vragen beantwoord.
Misschien is er toch een omweg te bedenken.
Kees
(https://images.beneluxspoor.net/bnls/Schema-Spoorbaan-van-Kees.png) (https://images.beneluxspoor.net/bnls/Schema-Spoorbaan-van-Kees.png)
-
Kees
ik ben toch bang dat ze gelijk hebben. Bij mij ziet het in een versimpelde vorm als volgt uit:
(https://images.beneluxspoor.net/bnls/S88-overzicht.jpg) (https://images.beneluxspoor.net/bnls/S88-overzicht.jpg)
Bij mij zit de centrale tussen Koploper en de S88 aansluiting. Dat is in wezen bij jouw ook het geval, alleen is dat de S88XpressNetLI en die geeft alles door aan de master (PC met Koploper). Echter de rest is slave. Ik ken het XpressNet protocol niet, dus daar kan ik niks over zeggen, behalve dat ik denk dat Dirk en Karst daar vermoedelijk meer van weten en waarschijnlijk gelijk hebben. Ik zou wel een technische oplossing kunnen bedenken, n.l. dat je de S88 verbinding tussen de s88SD16-n en de S88XpresNetLI via de Arduino Mega laat verlopen. Dus de S88 kabel komende van de s99SD16-n verbindt je met de Mega en dan een aparte kabel tussen de S88XpressNetLI en de Mega, en dan de Mega als een soort router laten functioneren waarbij hij dan wel ondertussen kennis kan nemen van de status van de bezetmelders.
Een vraagje. Ik begrijp dat je de wissels d.m.v drukknoppen op een tableau aanstuurt via de Mega. Maar hoe laat je Koploper weten wat de stand van een wissel is. Of omgekeerd kan Koploper ook een wissel besturen (i.v.m. automatisch rijden) of heb je van dat soort mogelijkheden afgezien?
groet Meino
-
Kees
Ik zit nog eens naar je schema te kijken, maar ik denk dat ik het al begrijp. De Mega functioneert gewoon als een extra lokmaus c.q. handregelaar. Hij zet niet zelf de wissels om, dat gebeurd via DCC commando's vanuit de Centrale.
Tenminste dat denk ik.
Groet Meino
-
... behalve dat ik denk dat Dirk en Karst daar vermoedelijk meer van weten en waarschijnlijk gelijk hebben...
... laat dat "vermoedelijk" maar weg. Ik heb namelijk de S88XpresNetLI bedacht, ontworpen en geprogrammeerd :P
De "reasoning behind" : in een XpressNet omgeving is de centrale de baas op de XpressNet-bus. Die verzamelt de bezetmeldingen en broadcast die op het XpressNet. Daar er ten tijde van bedenken (2008) geen centrales waren die de (low-cost) s88 ondersteuen, is voor deze oplossing gekozen. Vooral bedoeld om de toemalige Roco MultiMAUS aan de PC aan te sluiten.
... Ik zou wel een technische oplossing kunnen bedenken, n.l. dat je de S88 verbinding tussen de s88SD16-n en de S88XpresNetLI via de Arduino Mega laat verlopen. Dus de S88 kabel komende van de s99SD16-n verbindt je met de Mega en dan een aparte kabel tussen de S88XpressNetLI en de Mega, en dan de Mega als een soort router laten functioneren waarbij hij dan wel ondertussen kennis kan nemen van de status van de bezetmelders....
... meer voor de hand liggend zou ik vinden, om de Arduino op s88 bus mee te laten luisteren, zonder dat hij zelf de s88 door moet geven.
Grtzz,
Karst
-
... meer voor de hand liggend zou ik vinden, om de Arduino op s88 bus mee te laten luisteren, zonder dat hij zelf de s88 door moet geven.
Dat is inderdaad het simpelst, dat had ik ook moeten bedenken.
Groet Meino
-
Meino,
... meer voor de hand liggend zou ik vinden, om de Arduino op s88 bus mee te laten luisteren, zonder dat hij zelf de s88 door moet geven. Dat is inderdaad het simpelst, dat had ik ook moeten bedenken.
Dit is inderdaad de beste oplossing lijkt mij, ik ga kijken of dit kan realiseren.
Op je vraag of de handelingen op het tableau bij Koploper aankomen is nee. Dit is overigens erg vreemd, want de centrale ziet het wel. Andersom werkt het ook. De leds voor de wisselstand worden door de terugmelding van de centrale bestuurd, deze functie is eigen bedoeld voor het oplossen van fouten.
Bedankt voor het meedenken ik ga weer aan de slag. Als lukt laat ik van mij horen.
Kees
-
Bij de buren (https://forum.3rail.nl/index.php?topic=76461.0) heeft iemand verzonnen dat je Koploper-activiteiten kunt uitlezen.
Waar is die trein??
Dat is een wat lastiger, maar Koploper biedt uitkomst. Er wordt, indien deze optie wordt aangezet, op poort 5700 een bericht verzonden als een locomotief een blok aandoet. Het decodernummer van de loc, gevolgd door het blok waar deze naar toe gaat en de modeltijd en werkelijke tijd.
De exacte layout van dit record is:
0x1b, byte: lengte, 0x1b,locnr,0x1b,bloknr,0x1b,tijd mode,0x1b,tijd pc, 0x1b,omschrijving, 0
Ik heb geen idee of ik de vragensteller met deze link een dienst bewijs, maar niet geschoten is altijd mis. ???
-
Op je vraag of de handelingen op het tableau bij Koploper aankomen is nee. Dit is overigens erg vreemd, want de centrale ziet het wel. Andersom werkt het ook. De leds voor de wisselstand worden door de terugmelding van de centrale bestuurd, deze functie is eigen bedoeld voor het oplossen van fouten.
Dat kan wel kloppen. Ik laat een deel van de wissels door koploper bedienen. Die worden via DCC commando's aangestuurd. Maar ik kan op de display van mijn centrale (MDRRC II) die ook bedienen. Als ik dat doe, ziet Koploper de wijziging ook niet. Ik ben van plan om op het mijn tableau d.m.v drukknoppen een bezetmelding in koploper te maken, die dan door middel van een gekoppelde speciale actie het wissel omzet. Maar dat is nu nog in de planning fase.
Groet Meino