Dinamo

Posted by Jan Hendriks on 2014-08-26 15:13

Jaco

Ook wij van de MSC RailRunners Groningen gebruiken OC32's in de modulebaan.
Voor ons zou een ruimere adressering ook mooi zijn.
Volg deze Topic graag.

mvg
Jan Hendriks

Posted by Leon van Perlo on 2014-08-29 08:44

Voor de adresbeperking OC32 verwacht ik binnenkort een oplossing te hebben.

TM44 is een ander verhaal. 32 devices op 1 bus is al best veel. Tel daar ook nog eens een stuk of 20 OC32's bij en je zit zo op 52. Dat begint in de buurt te komen bij het punt waar je wel heel zorgvuldig moet gaan worden met het aanleggen van je RS485 bus. De overgangsweerstanden van alle niet-ideale connectoren beginnen dan serieus een rol te spelen.
Voor dergelijk grote systemen zul je uiteindelijk toch op meerdere RS485 bussen gaan uitkomen, is mijn verwachting.

Mvg,
Leon

Posted by Frans Staal on 2014-08-29 09:01

Jaco,
met een slimme opstelling van je PC en RM-U('s) kan je volgens mij nog steeds met 1x RS485 kabel onder de modules werken, ondanks dat je 2 bussen hebt. Als je de RM-U('s) ergens in het midden van de opstelling kan positioneren, dan ga je met de ene bus naar links en met de andere bus naar rechts.
Groet
Frans

Posted by Jaco Hagoort on 2014-08-29 09:59

We willen eventueel een 2e rs485 bus sturen over pin 1 en 8 van de cat5e kabel. Deze worden volgens mij niet gebruikt/aangesloten op de Dinamo printen.
Met een kabelsplitter brengen we dan de pinnummers weer op de juiste positie.
De pinnummers van de synchronisatie clock voor de TM44's kunnen voor beide rs485 bussen gebruikt worden.
Pin 2 en 7 worden volgens mij gebruikt als Ground. Deze gebruiken we wel, omdat de TM44's veelal niet bij elkaar staan en een aparte voeding hebben.

Mvrg,

Jaco.

Posted by Frans Staal on 2014-08-29 10:12

Jaco,

we hebben het steeds over de RS485 bus, maar eigenlijk heb je altijd al 2 bussen, namelijk een databus en een clockbus. Op de TM's heb je beiden nodig, maar voor de OC's (en eventueel PM's) volstaat de databus.

Zou je de TM's verdelen over meerdere databussen om de load op de bus te verminderen, dan heb je nog steeds alle TM's op die ene clockbus. De TM's moeten immer synchroon lopen, dus kunnen niet verdeeld worden over meerdere clockbussen.

Nu zijn er repeaters en extenders in de handel waarmee je het aantal nodes (en de lengte) van de bus kan vergroten, maar dat zijn over het algemeen prijzige oplossingen.

groet
Frans

Posted by Frans Staal on 2014-08-29 10:52

Jaco,

de RS485 chip die op alle Dinamo modules gebruikt worden is de MAX3082. Volgens de specificatie van de fabrikant kan je hiermee 256 nodes op 1 bus aansluiten omdat de ingangen van de receivers van de MAX3082 1/8 van de load zijn van een "normale" receiver. Normaal is: volgens de specs van RS485.

Maar er is meer wat een rol speelt, namelijk de lengte van de bus, het aantal overgangen (connectoren), de gebruikte bitrate en de hoeveelheid data die je over de bus "perst". Dit is de theorie, de praktische kant en het totaal overzicht heeft slechts een persoon, dus het laatste woord is aan Leon

groet
Frans

Posted by Leon van Perlo on 2014-08-29 12:33

Nou, ik ben ook niet alwetend hoor.
De OC32 is inderdaad niet voorzien van RJ45. Aan de ene kant kun je dat jammer vinden. Anderzijds voorkomt dat wel dat de ketting van modules nog langer wordt. Een korte 'drop' naar de dichtsbijzijnde TM44 heeft dat nadeel niet.
In de praktijk voor zover ik die ken is het aantal contactovergangen (contacten van de connectoren en aangeknepen stekkertjes) eerder een probleem dan de fan-out van de RS485 driver. Bij het doorlussen via een TM44 heb je dus al 4 contactovergangen per ader. Gemak dient de hobbyist, maar naar mijn mening houdt dat gemak ietwat op bij 32 modules in serie en moet je daarboven gaan nadenken over een voldoende robuuste bedradingstechniek. Maar iemand die zo'n grote miniatuurwereld bouwt kan dat meestal wel.

Mvg Leon

Posted by Jaco Hagoort on 2014-09-01 11:28

Hallo Frans

Verschillende modules met dezelfde adressen uitvoeren gaat toch niet helemaal goed.
Althans als je in iTrain opgeeft dat alle magneetartikelen goed gezet moeten worden bij het online zetten.

(Dubbele) adressen van niet gebruikte modules worden dan ook geactiveerd. Wat conflicten kan geven met wel gebruikte modules.
O.a. wissels gaan klapperen omdat ze in beide standen (kunnen) worden aangestuurd.

Weet jij of er nog meer neveneffecten zijn te verwachten, door adressen dubbel te gebruiken?

Mvrg,

Jaco.

Posted by Frans Staal on 2014-09-01 14:43

Hallo Jaco,

als het goed is gaan verschillende modules met gelijke adressen helemaal niet goed! Tenzij identieke adressen op verschillende RM-U's (lees: databussen) zitten. In principe moet een adres uniek zijn per bus.

Heb je alleen last bij het online zetten? Of ook tijdens het rijden? Je kan het zetten van wissels bij online zetten natuurlijk uitzetten, als je dan maar bij de treinroutes opgeeft dat hij de wissels altijd (dus ook als iTrain denkt dat ze goed staan) moet zetten.

Ik kan zo geen neveneffecten bedenken.

Groet
Frans

Posted by Jaco Hagoort on 2014-09-01 15:15

Hallo Frans,

Ik heb alleen last bij het online zetten. Ik kan die functie inderdaad uitzetten.
Tijdens het rijden heb ik geen last ondervonden, omdat wissels wel een andere naam hebben. En blijkbaar wordt alleen de naam met bijbehorend adres geactiveerd.

Wanneer ik de RM-U's in het midden van de baan zet, zoals jij eerder voorstelde, moet ik wel adressen dubbel gebruiken. De ene keer zit een module rechts en een volgende keer links van het midden.

Mvrg,

Jaco.

Posted by Jaco Hagoort on 2014-09-02 08:23

In iTrain hebben we meerdere tabbladen met elk een aantal getekende modules. Eventueel ook dezelfde modules aangestuurd door verschillende adressen.
Voor een evenement maken we dan een 'hoofdtabblad' waar de baan samenstellen uit de beschikbare modules. Wat we dan nog moeten doen is op elk blok dubbelklikken en 'automatisch vullen' aanklikken. Op dat moment worden de blokken aan de naastgelegen blokken gekoppeld.

Niet alle modules worden dus gebruikt. Ook zijn dan niet alle TM's en OC's fysiek aanwezig. Dit lijkt geen probleem te zijn voor het programma. Er volgt geen foutmelding. Het is waarschijnlijk vergelijkbaar met wissels en seinen die foutieve of niet bestaande adressen hebben. Dan gebeurd namelijk gewoon niets.

Mvrg,

Jaco.

Posted by Frans Staal on 2014-09-02 09:04

Hallo Jaco,

wat er wel gebeurt bij het online komen van Dinamo (na verbinden in iTrain), is dat iTrain "op zoek gaat" naar alle bezetmelders die fysiek aanwezig zijn. Daardoor kan het gebeuren dat het online komen erg lang duurt.

Omdat het onderwerp nu geen Dinamo item meer is, moet je wellicht dit onderwerp op het iTrain forum plaatsen als een aanpassingsverzoek, waarbij we misschien eerst eens moeten bekijken waar je verder nog tegenaan loopt of specifiek voor samengestelde banen aan Xander zou willen voorleggen.

Groet
Frans

Posted by Jaco Hagoort on 2014-09-29 14:33

Hallo Leon,

Is het BIDIB protocol misschien een oplossing voor de uitbreiding van de adressen?
Gebruikt ook RS485.

Of zeg ik nou iets geks?

Mvrg,

Jaco Hagoort

Posted by Frans Staal on 2014-10-01 21:35

Hallo Jaco,

Nee, BiDiB op zich biedt geen oplossing voor het uitbreiden van de adressering. BiDiB is een protokol voor het besturen van modelbanen, waarvan een van de eigenschappen is (vandaar de naam) dat het bi-directioneel is. Er gaan dus niet alleen commando's van de centrale naar de loc, maar ook van de loc naar de centrale. Vergelijk het maar met RailCom.

Nu kan je BiDiB over allerlei infrastructuur sturen, zoals Ethernet of CAN en dus ook over een RS485 bus. Maar daar houdt het verband tussen de OC32 addressering en BiDiB op.

Groet
Frans

Posted by Jaco Hagoort on 2014-10-13 14:01

Hallo Leon/Frans,

ik zag dat het huidige protocol voorziet in extra bytes.
Misschien is het een idee om een extra byte te gebruiken voor de adressering naast de huidige adressering.
Een software matig adres die weggeschreven kan worden op de OC32 en TM44. Hier zijn dan 128 adressen mogelijk en i.c.m. de hardwarematige adressering van de modules moet dat ruim voldoende zijn.
De reguliere hobbyisten kunnen dan gewoon gebruik maken van de dip-switches.
Het software adres zou je dan moeten kunnen instellen via rmu-config en/of oc32-config.
Standaard staat dit adres dan op 0, of indien het byte niet aanwezig, dit als adres 0 te zien.
Hardwarematig behoeven dan waarschijnlijk de OC32 en TM44 niet aangepast worden.

Mvrg,

Jaco Hagoort