BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: AP3737 op 07 July 2024, 11:44:45
-
Hallo
Ik lees dat de Yamorc 7010 xpressnet ondersteund. Mooi. Maar kan ik de 7010 ook via xpressnet met een PC verbinden? Kan dat via TCP/IP (wifi of LAN poort)? Indien ja, welke XpressNet commando’s worden ondersteund? V3.6? V4? Zijn er uitbreidingen ten opzichte van de Lenz Specificaties, bijvoorbeeld extended acessory commands? Waar kan ik de details vinden?
Achtergrond van mijn vraag is dat ik XPressNet software (DLL) voor onze modelbouw club aan het schrijven ben en me afvraag of Yamorc een alternatief voor de Lenz LZV met 23151 interface kan zijn.
Groet, Aiko
-
Niet om Karst onder de vleugels te schieten maar met die Lenz heb je een uitstekende centrale die alles doet wat je wilt.... en puur met XPressNet werkt.
-
Hi Aiko,
De DR5000 en de YD7010 ondersteunen XpressNet via LAN, is compatible met het XpressNet LAN protocol van Lenz. (= 2 byte header + XpressNet bericht.)
OpenDCC heeft wel een commando voor Extended Accessory, zie: https://www.opendcc.de/elektronik/opendcc/xpressnet_commands_e.html
Ik heb niet getest of dat ook werkt met een DR5000, een YD7010 heb ik niet liggen. (Karst kan er vast uitsluitsel over geven :))
Wil je perse XpressNet gebruiken, of is LocoNet ook een optie? Via LocoNet kun je sowiso Extended Accessory aansturen, met het OPC_IMM_PACKET commando, hiermee kun je zelf een DCC pakket op de rails zetten en dus ook een Extended Accessory commando.
Mocht je documentatie vinden over XpressNet 4.0, dan ben ik ook wel geïnteresseerd :)
De open source applicatie die ik aan het ontwikkelen ben in C++ ondersteund zowel LocoNet (incl. Extended Accessory) als XpressNet (en nog een aantal) over zowel serial/USB/LAN, zie: https://github.com/traintastic/traintastic
In welke taal ben je de DLL aan het ontwikkelen?
-
Volgens mij deed DR5000 nog geen DCC EXT commando's. Mijn versie althans niet. Ik weet nog dat ik decoder aan testen was dat ik toch de z21 en de app uit de kast moest pakken. Maar ik ben niet 100% zeker.
Van wat ik lees uit yamorc handleidingen, moeten de YD centrales het wel allemaal doen.
Bas
-
Dank voor de antwoorden
@Ronald: het zou kunnen dat we later nog een aantal centrales nodig hebben Qua prijs is Yamorc natuurlijk interessant.
@Reinder & Bas. Goed te weten dat bij de Yamorc centrale XpressNet over LAN is geïmplementeerd. Blijft natuurlijk de vraag wat precies geïmplementeerd is. Hopelijk kan Karst die vraag beantwoorden. Momenteel implementeer ik V3.6 specificatie die Reinder al heeft genoemd, en de XpressNet V4 die op de Lenz website staat (dat is de pure XpressNet specificatie, dus zonder de 0xFF 0xFE Framing bytes).
De OpenDCC extensies ken ik, en zou ik kunnen toevoegen.
Misschien even wat meer achtergrond over wat ik aan het doen ben. Sinds kort ben ik lid van de Twentse Modelspoorbaan Club (TMC). De digitale besturing is daarvan 20 à 25 jaar geleden gestart. De besturing van locomotieven gaat handmatig via DCC, IB en Daisy; voor de besturing van wissels, seinen en bezetmeldingen is een eigen systeem ontwikkeld. Per station (Enschede, Hengelo, Oldenzaal, ...) is er een eigen controlepost (PC). In de PCs zitten nog oude PIO kaarten; de software is geschreven in VB6. PIO kaarten passen natuurlijk niet meer in moderne PCs, maar over de VB6 besturingssoftware is iedereen nog heel tevreden, en daar wil men graag mee doorgaan. Ik ben dus een DLL aan het schrijven die XpressNet praat via TCP/IP, en vanuit VB6 gebruikt kan worden. Ik vermoed echter dat deze (32bit) DLL ook in combinatie met moderne (.Net) software zou moeten kunnen werken.
Maar misschien is het handiger als ik een apart draadje over de TMC digitaliseringsplannen begin, waarin ook alternatieven besproken kunnen worden. Dit draadje blijft dan zich richten op de vraag: welke XpressNet commando's ondersteund Yamorc.
Groet, Aiko
PS: ik kan Karst natuurlijk ook privé mailen, maar ik vermoed dat meerdere mensen in het antwoord geïnteresseerd zijn, of dat iemand dat al weet.
-
Volgens mij deed DR5000 nog geen DCC EXT commando's. Mijn versie althans niet.
In de DR5000 changelog V1.5.0 staat:
OPC_IMM_PACKET Now this LocoNet command is fully implemented so that e.g. JMRI the so called Signal mast aspects can be sent to so called Extended Accessory Decoders.
De centrale kan DCCext via LocoNet, de software die tegen de centrale praat moet het ook kunnen natuurlijk.
Misschien even wat meer achtergrond over wat ik aan het doen ben. Sinds kort ben ik lid van de Twentse Modelspoorbaan Club (TMC). De digitale besturing is daarvan 20 à 25 jaar geleden gestart. De besturing van locomotieven gaat handmatig via DCC, IB en Daisy; voor de besturing van wissels, seinen en bezetmeldingen is een eigen systeem ontwikkeld. Per station (Enschede, Hengelo, Oldenzaal, ...) is er een eigen controlepost (PC). In de PCs zitten nog oude PIO kaarten; de software is geschreven in VB6. PIO kaarten passen natuurlijk niet meer in moderne PCs, maar over de VB6 besturingssoftware is iedereen nog heel tevreden, en daar wil men graag mee doorgaan. Ik ben dus een DLL aan het schrijven die XpressNet praat via TCP/IP, en vanuit VB6 gebruikt kan worden. Ik vermoed echter dat deze (32bit) DLL ook in combinatie met moderne (.Net) software zou moeten kunnen werken.
Dat is een leuk project :) zijn dat van die ISA PIO kaarten met 48 IO's? Daar heb ik ooit als 16 jarige ook een wat automatisering gebouwd in VB6, ik denk dat ik die kaart nog wel heb ergens in een bak.
Als die 32bit DLL een C api heeft, dan kun je em in de meeste talen wel gebruiken (mits 32bit).
Zn project is zeker een topic waard! dat ga ik zeker volgen!
-
Ik weet weer waarom ik dit dacht. Ik was toen in iTrain aan het spelen. En ik heb deze knop over het hoofd gezien, waar ik hem bij de z21 wel zag staan. Daarom wist ik niet zeker of het er in zat.
(https://images.beneluxspoor.net/bnls_2024/deleteme-668c50da48e9b.png) (https://images.beneluxspoor.net/bnls_2024/deleteme-668c50da48e9b.png)
-
De DR5000 en de YD7010 ondersteunen XpressNet via LAN, is compatible met het XpressNet LAN protocol van Lenz. (= 2 byte header + XpressNet bericht.)
Klopt. Alleen in de YD70xx ( DR5000 niet ! ) wordt V4.0 momenteel slechts deels ondersteund. Er is niet veel vraag meer naar dit protocol. Z21 en OpenDCC zijn hier op het moment leidend. En, kwalijkerwijze, bedenken zelf uitbreidingen op het protocol. :'(
OpenDCC heeft wel een commando voor Extended Accessory, zie: https://www.opendcc.de/elektronik/opendcc/xpressnet_commands_e.html
Ik heb niet getest of dat ook werkt met een DR5000, een YD7010 heb ik niet liggen. (Karst kan er vast uitsluitsel over geven :))
Dat werkt niet, omdat het door OpenDCC "gedefinieerde" commando niet klopt met de RCN norm. De NMRA9.2.1 beschrijving is beperkt tot 4 Bits voor het aspect.
Wil je perse XpressNet gebruiken, of is LocoNet ook een optie? Via LocoNet kun je sowiso Extended Accessory aansturen, met het OPC_IMM_PACKET commando, hiermee kun je zelf een DCC pakket op de rails zetten en dus ook een Extended Accessory commando.
Dat kan, en zal werken. Ook bij een DR5000. maarrrr... dat "kaapt" tijd uit de refresh-stack. De YD70xx centrales decoderen dit LocoNet packet en nemen het intern op als een "echt" DCCext-Commando, waardoor het net zo behandeld wordt als een "normaal" wisselcommando.
Mocht je documentatie vinden over XpressNet 4.0, dan ben ik ook wel geïnteresseerd :)
Hier op de meest voor de hand liggende plaats: https://www.lenz-elektronik.de/src/pdf/Lenz_XpressNet_Doku.pdf (https://www.lenz-elektronik.de/src/pdf/Lenz_XpressNet_Doku.pdf)
Ik was toen in iTrain aan het spelen. En ik heb deze knop over het hoofd gezien, waar ik hem bij de z21 wel zag staan. Daarom wist ik niet zeker of het er in zat.
iTrain heeft sinds de directe ondersteuning van de YaMoRC centrales de mogelijkheid om decoders via DCCext ( aspects ) aan te sturen. Zowel via het Z21 als het LocoNet protocol.
Grtzz,
Karst
-
Ik heb met veel moeite (no bueno deutch :P) dat lenz document gecrunched. Er lijkt geen ext, accessoire instructie in te zitten. Je kan van loks wel t/m F68 schakelen en wissels tot 2048. Je kan bijna net zo goed lokadressen gaan gebruiken voor accessoire decoders ::)
Dat werkt niet, omdat het door OpenDCC "gedefinieerde" commando niet klopt met de RCN norm. De NMRA9.2.1 beschrijving is beperkt tot 4 Bits voor het aspect.
Kan het heel misschien zijn dat je een tikfoutje gemaakt bij het getal 4?
Dat nmra document specificeert 6 bits.
Ik begrijp het probleem ook niet helemaal. Kan je niet simpelweg de waarde uit het Xnet ext commando vissen, waardes boven 31 dan maar negeren en de waarde op de baan zetten? Als je voorste 3 bits op nul laat staan, doen sein decoders het snappen of ze nu nmra of rcn aanhouden.
Extended Accessory Decoder Control Packet Format
The Extended Accessory Decoder Control Packet is included for the purpose of transmitting aspect control to signal
decoders or data bytes to more complex accessory decoders. Each signal head can display one aspect at a time.
{preamble} 0 10AAAAAA 0 0AAA0AA1 0 000XXXXX 0 EEEEEEEE 1
Op die 3 puntloze nullen na verschillen ze niet
10AA-AAAA 0AAA-0AA1 DDDD-DDDD // rcn213
10AA-AAAA 0AAA-0AA1 000X-XXXX // nmra
En, kwalijkerwijze, bedenken zelf uitbreidingen op het protocol
Soms moet je wel als je nieuwe dingen wilt toevoegen. Ik wil bijvoorbeeld met loconet 'tekst' berichten kunnen sturen naar hand regelaars met display.
Voor analoog bedrijf wil ik dat een toegewijde PWM booster, de centrale opdracht geeft om DCC over railsynch lijnen te vervangen voor een 100Hz klok
Zelfde idee met railcom. Ik zou het liefst willen dat een railcom apparaat bij opstarten een instructie over loconet stuurt die de cutouts inschakelt bij d'n centrale. Dat scheelt alleen maar settings.
En dit kan allemaal bereikt worden door 1 hele OPCODE toe te voegen, wat ik dan afstem met Digitrax ::)
Mvg,
Bas
-
Kan het heel misschien zijn dat je een tikfoutje gemaakt bij het getal 4?
Dat nmra document specificeert 6 bits.
Klopt ;)
Kan het Ik begrijp het probleem ook niet helemaal. Kan je niet simpelweg de waarde uit het Xnet ext commando vissen, waardes boven 31 dan maar negeren en de waarde op de baan zetten? Als je voorste 3 bits op nul laat staan, doen sein decoders het snappen of ze nu nmra of rcn aanhouden.
Natuurlijk kan dat, maar is vrij nutteloos, daar alle momenteel commercieel op de markt zijnde decoders meer dan deze 5 bits gebruiken...
Op die 3 puntloze nullen na verschillen ze niet
10AA-AAAA 0AAA-0AA1 DDDD-DDDD // rcn213
10AA-AAAA 0AAA-0AA1 000X-XXXX // nmra
Klopt ook.
Soms moet je wel als je nieuwe dingen wilt toevoegen. Ik wil bijvoorbeeld met loconet 'tekst' berichten kunnen sturen naar hand regelaars met display.
Voor analoog bedrijf wil ik dat een toegewijde PWM booster, de centrale opdracht geeft om DCC over railsynch lijnen te vervangen voor een 100Hz klok
Zelfde idee met railcom. Ik zou het liefst willen dat een railcom apparaat bij opstarten een instructie over loconet stuurt die de cutouts inschakelt bij d'n centrale. Dat scheelt alleen maar settings.
En dit kan allemaal bereikt worden door 1 hele OPCODE toe te voegen, wat ik dan afstem met Digitrax ::)
Daarvoor heeft LocoNet OPC_PEER_XFER.
Daar kun je knutselen wat je wilt. Echter, dat hebben al meer partijen gedaan. De enige die ik ken die dat ook met Digitrax afgestemd heeft, is Uhlenbrock.
Dus OPCODE toevoegen hoeft niet. Dat heb ik overigens wel geprobeerd om dat met Digitrax af te stemmen voor het melden van RailCom berichten.... Antwoord: RailCom is voor ons "non-existent" en derhalve werken we niet mee aan uw voorstel ::) :o
Helaas houdt Digitrax deze "afspraken" lekker voor zich zelf. Zelfs in de NDA komen ze niet voor, anders dan "Third-Party-propriatry" :(
Grtzz,
Karst
-
Tjonge, snap het allemaal niet echt, maar kan ik uit deze berichten nu opmaken dat het met de standaardisering eerder de verkeerde kant opgaat?
-
Muricanen doen soms moeilijk :P
het melden van RailCom berichten
Dacht dat die OPC_MULTI_SENSE daar voor bedoeld was ::), stond iets in over transponder enters a block en transponder exists a block. Die beschrijvingen of afwezigheid daarvan, kan ik niet altijd kaas van maken :'(
Mvg,
Bas
-
Tjonge, snap het allemaal niet echt, maar kan ik uit deze berichten nu opmaken dat het met de standaardisering eerder de verkeerde kant opgaat?
Ik vrees dat je daar helaas helemaal gelijk in hebt :'(
Zimo/Roco, D&H, ESU, Märklin maar vooral PIKO, koken heel graag allemaal hun eigen soepje :'( en dat ondanks het RailCommunity gremium dat de europeesche standaarden maakt/bewaakt.
Dacht dat die OPC_MULTI_SENSE daar voor bedoeld was ::), stond iets in over transponder enters a block en transponder exists a block. Die beschrijvingen of afwezigheid daarvan, kan ik niet altijd kaas van maken :'(
Die maken onderdeel uit van de LocoNet NDA Versie. Daarover mag je niet in het openbaar uitwijden. ;) (maar het antwoord is nee, transponding is exclusief Digitrax en is ook niet compatibel met de RailCom data)
Grtzz,
Karst
-
Dat is een leuk project :) zijn dat van die ISA PIO kaarten met 48 IO's?
Nee, nog erger: 192 IOs :)
... in de YD70xx ( DR5000 niet ! ) wordt V4.0 momenteel slechts deels ondersteund.
Kan ik dit zo lezen dat V3.6 voor 100% wordt ondersteund, maar de nieuwe V4 slechts een deel??
Z21 en OpenDCC zijn hier op het moment leidend.
Dat het Z21 protocol populair is, zie ik zelf tegenwoordig ook. Naar dat je ook OpenDCC noemt, verrast me wat. Bedoel je BIDIB? Dat zou een interessante ontwikkeling zijn.
Ik begrijp het probleem ook niet helemaal. Kan je niet simpelweg de waarde uit het Xnet ext commando vissen, waardes boven 31 dan maar negeren en de waarde op de baan zetten? Als je voorste 3 bits op nul laat staan, doen sein decoders het snappen of ze nu nmra of rcn aanhouden.
Sorry, maar ik begrijp het nu helemaal niet meer ;)
Over welk XpressNet commando heb je het? Of heb je het over DCC commando's??
Het lijkt er inderdaad op dat vendor lock-in belangrijker wordt gevonden dan standaardisatie. In plaats dat het voor de gebruiker eenvoudiger wordt, komt er steeds meer verschil tussen fabrikanten. En open beschikbare documentatie wat het apparaat ondersteund is ook niet altijd beschikbaar. Daarnaast lijkt het er ook op dat Europa en de VS steeds verder uit elkaar groeien; fabrikanten opereren steeds vaker alleen voor hun "lokale" markt. Illustratief vind ik dat de Lenz XpressNet V4 spec, voor zover ik weet, niet mee in het Engels heeft. In de VS heb je LCC, waarover je in Europa niets hoort. Enz.
De enige echt "open" ontwikkeling is Bidib, maar dat vraagt veel meer om te implementeren. AVR 328/2560 kan je meteen vergeten. Xmega's zijn exclusief en duur.
Groet, Aiko
-
Over welk XpressNet commando heb je het? Of heb je het over DCC commando's??
Ik had het over allebei. Dat een centrale DCC EXT op de DCC bus kan is 1. Maar als je dat soort instructies wilt uitsturen, moet je je centrale dat eerst vertellen. En jouw originele vraag was deels of de extended instructies ook in de YD's implementatie van Xnet was opgenomen.
Zijn er uitbreidingen ten opzichte van de Lenz Specificaties, bijvoorbeeld extended acessory commands?
De enige echt "open" ontwikkeling is Bidib, maar dat vraagt veel meer om te implementeren.
True maar ik denk dat dit ook een beetje speelt:
(https://imgs.xkcd.com/comics/standards.png)
Met loconet kunnen we al een soort van alles. We hebben railsync, boosters, throttles, terugmelders.. d'r bestaan schakeldecoders. We kunnen railcom en ext. instructies sturen. Dus waarom willen we dan nog een bus die zo'n beetje hetzelfde kan?
Mvg,
Bas
-
Met loconet kunnen we al een soort van alles. We hebben railsync, boosters, throttles, terugmelders.. d'r bestaan schakeldecoders. We kunnen railcom en ext. instructies sturen. Dus waarom willen we dan nog een bus die zo'n beetje hetzelfde kan?
Er zijn toch behoorlijk wat functies die Bidib kan, maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie). Daarnaast staat de complete Bidib specificatie gewoon op Internet, terwijl die van Loconet slechts gedeeltelijk openbaar is. (Commerciële) nabouw van Loconet is beperkt mogelijk. Daarnaast is Bidib technisch veel moderner en krachtiger.
Voorkeuren (en toepassingsgebieden) verschillen, en dat is ook prima. Maar zeggen dat Loconet alles al kan ..... ;)
Groet, Aiko
-
Daarnaast is Bidib technisch veel moderner en krachtiger
Moderner geef ik niet altijd om, krachtiger klinkt opzich wel leuk maar dan ga ik me altijd afvragen. Do we need krachtiger? ;D. BiDib heeft wel een hogere baudrate 500k vs 16.6k, maar mensen rijden al succesvol op loconet apparaten. Die atmega328 gingen volgens mij niet zo hoog kwa baudrate. En ik hou m'n good ol' 8 bitter. If it works...
Ik ga binnenkort een test opstelling maken met 10 loconet terugmelders. Elke melder zal dan tegelijk alle 16 contacten door willen geven. Met een beetje mazzel kan ik dat dan goed vastleggen op een terugmeld monitor op de PC.
maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie).
De DR5088RC doet toch precies dat? Je kan als ontwikkelaar sws van alles doen met die vrije OPCODE waar Karst het over had. Er kunnen tot 255 bytes in een bericht. Daarin kan je elke data zetten wat je maar wilt. En als de nood echt hoog is, voeg je zelf een OPCODE toe.
Met LNCV programmering kom je ook nog eind met dingen instellen. No problem.
Mvg,
Bas
-
De DR5088RC doet toch precies dat?
Klopt, alleen het nadeel van OPC_MULTI_SENSE is dat die net wat te beperkt is. Je kan bijvoorbeeld de trein richting niet doorgeven. De DR5088RC kan dat wel, maar dat gebruikt die de hoogste bit van het sensor adres of lok adres. Nadeel daarvan is dat je de helft van je adressen kwijt bent. Als je de richting in het lok adres codeert heb je "maar" 4096 adressen, daarboven krijg je een rollover, voor thuis niet zn issue, maar hier op de club geven ze ieder lid een 100 adressen blok, toen de persoon met de 41xx range zn lok op de rails zette ging dat aanmelden niet goed. TrainController 9 ondersteund helaas alleen de Blücher GBM 16XN methode (richting in adres).
De DR5088RC ondersteund ook nog OPC_MULTI_SENSE_LONG, daar zit veel meer RailCom info in.
Ik heb het OPC_MULTI_SENSE bericht formaat uitgepuzzeld door gewoon te proberen, loks met andere adressen, andere ingang en kijken wat er verandert, zoveel bytes zijn het niet, dat puzzel je zo uit. Heb wel contact gehad met Digitrax over de NDA, maar toen ik vroeg hoe dat samen ging met open source software toen kreeg ik geen reactie meer.... Toen ben ik het maar gaan reverse engineeren, als ze dat niet oke vinden dan hoor ik dat wel, kunnen we dan verder praten.
@Karst bij de YD70xx doe je dus wat speciaals met de OPC_IMM_PACKET als het DCCext is, dat is wel een mooie feature :) Wat doe je dan met de repeat count van OPC_IMM_PACKET? (Ik heb die nu op 2 staan voor DCCext, leek me wel voldoende, die decoders zitten toch direct op DCC, zonder wielen ertussen :))
Nee, nog erger: 192 IOs :)
Wow dat zijn er echt een boel, als je een topic begint (met foto's) let me know (via PM), ben heel benieuwd.
De enige echt "open" ontwikkeling is Bidib, maar dat vraagt veel meer om te implementeren. AVR 328/2560 kan je meteen vergeten. Xmega's zijn exclusief en duur.
BiDiB heb ik ook wel eens naar gekeken, op papier een mooi systeem, tot ik de prijs zag van modules, dat viel me wel tegen. Denk toch dat als je een nieuwe strandaard wil zetten (bij voorkeur een open standaard), dan moet de hardware niet te duur zijn, dan kopen veel mensen toch eerder wat anders waarbij de prijs per poort lager is.
-
Kan ik dit zo lezen dat V3.6 voor 100% wordt ondersteund, maar de nieuwe V4 slechts een deel??
Dat klopt. de V4 implementaie is "on-going". ( pick your cherries ;) )
Dat het Z21 protocol populair is, zie ik zelf tegenwoordig ook. Maar dat je ook OpenDCC noemt, verrast me wat. Bedoel je BIDIB? Dat zou een interessante ontwikkeling zijn.
Sorry, maar ik begrijp het nu helemaal niet meer ;) Over welk XpressNet commando heb je het? Of heb je het over DCC commando's??
Nee, ik bedoel echt OpenDCC. BiDiB is een ander beest. Hoewel het onder water veel van de OpenDCC specs gebruikt. En ja, het gaat dan over XpressNet commando's.
Zie hier: https://www.opendcc.de/elektronik/opendcc/xpressnet_commands_e.html (https://www.opendcc.de/elektronik/opendcc/xpressnet_commands_e.html) Dat is de Lenz V3.6 set, aangevuld met "eigen" commando's. Die dan weer deels door Z21 overgenomen zijn.
Het lijkt er inderdaad op dat vendor lock-in belangrijker wordt gevonden dan standaardisatie. In plaats dat het voor de gebruiker eenvoudiger wordt, komt er steeds meer verschil tussen fabrikanten. En open beschikbare documentatie wat het apparaat ondersteund is ook niet altijd beschikbaar. Daarnaast lijkt het er ook op dat Europa en de VS steeds verder uit elkaar groeien; fabrikanten opereren steeds vaker alleen voor hun "lokale" markt. Illustratief vind ik dat de Lenz XpressNet V4 spec, voor zover ik weet, niet mee in het Engels heeft. In de VS heb je LCC, waarover je in Europa niets hoort. Enz.
Ik volg op verzoek van de noord-Amerikaanse klanten al geruime tijd die ontwikkeling... Ik heb helaas maar 1 conclusie: volledig over-engineered, conceptloos ( alles "kan" alles ) en amateuristisch ( de gebruiker moet zelf ALLES letterlijk programmeren. Een grote hobbel voor 99% van de modelspoorders ) : ==> Niche.
De enige echt "open" ontwikkeling is Bidib, maar dat vraagt veel meer om te implementeren.
Dat is wat men ( de BiDiB jongens ) de wereld graag wil doen geloven. Maar het is maar net wat je onder de term "Open" verstaat. Persoonlijk vind ik Z21, XpressNet, WiThrottle allemaal behoorlijk Open: goede, publieke specificaties, die voor iedereeen zonder restricties te gebruiken zijn.
...AVR 328/2560 kan je meteen vergeten. Xmega's zijn exclusief en duur....
...Daarnaast is Bidib technisch veel moderner en krachtiger...
Hoewel ik de XMega's heerlijke, goed doordachte MCU's vind, zijn ze allesbehalve modern. Dat hebben we wel gemerkt tijdens de chip-crisis....
In plaats van krachtiger en moderner zou ik eerder de term "over-engineered" willen gebruiken. Het grootse probleem naar mijn mening is, dat je óf van 0 beginnen moet, óf je hele bestaande installatie moet vervangen. En laat dat nou net iets zijn, dat nou niet echt tot acceptatie voert. Een ander merk heeft onder andere als motto: "COMPATIBILITY is ESSENTIAL" ;) :P
...Maar zeggen dat Loconet alles al kan ..... ;) ...
LocoNet kan in principe alles. Er is geen technische beperking. Maar terecht opgemerkt: De specs zijn Half-Open en de IP-eigenaar is niet altijd bereid veranderingen door te voeren. ( en dan zeg ik het denk ik nog netjes ;) )
...maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie)...
Ook dat is iets dat de BiDib community graag tegen LocoNet aanvoert. Niets is echter minder waar. Bas gaf al aan hoe het wel zit. Stokpaardje is dan altijd, dat LocoNet te weinig bandbreedte zou hebben om RailCom data ( die met 250 kbps ) uit de decoders komt, te transporteren. Nu, als je even één moment langer conceptueel nadenkt, is het helemaal niet slim om alle RailCom data door te geven: Die data in de detector comprimeren en omzetten in conceptuele berichten, is naar mijn mening de weg die je zou moeten gaan. Zo heeft de DR5088RC en ook de nog te verschijnen YD6016LN-RC voor alle gangbare data die momenteel onder RailCom gedefinieerd is, keurige, conceptuele berichten. En dat alles via 1 OpCode in Loconet... Gaat uitstekend, zonder de bus vol te blèren ;)
Ik heb het OPC_MULTI_SENSE bericht formaat uitgepuzzeld door gewoon te proberen, loks met andere adressen, andere ingang en kijken wat er verandert, zoveel bytes zijn het niet, dat puzzel je zo uit. Heb wel contact gehad met Digitrax over de NDA, maar toen ik vroeg hoe dat samen ging met open source software toen kreeg ik geen reactie meer.... Toen ben ik het maar gaan reverse engineeren, als ze dat niet oke vinden dan hoor ik dat wel, kunnen we dan verder praten.
OPC_MULTI_SENSE valt idd onde NDA, maar OPC_MULTI_SENSE_LONG kun je zo bij mij opvragen :) ( helaas is die OPCODE dus door Digitrax verworpen, omdat "men" zelf geen RailCom heeft en het niet relevant vindt voor de eigen markt :'(
De DR5088RC ondersteund ook nog OPC_MULTI_SENSE_LONG, daar zit veel meer RailCom info in.
Nou ja, ik zou het niet direct RailCom info noemen. Het is eerder een abstractie van wat RailCom zo allemaal aan bits en bytes uit een decoder laat komen ;)
voorbeeld:
- Decoder (loc) komt sectie X binnen
- Decoder (loc) verlaat sectie X
- Decoder meldt actuele snelheid
- Decoder meldt Quality of Service
- Decoder antwoord op POM-read
etc. etc. Door dit "comprimeren" en afbeelden op conceptuele berichten, is het voor b.v. jou met TrainTastic veel eenvoudiger om de door RailCom veroorzaakte gegevens te verwerken op een zinvolle manier.
@Karst bij de YD70xx doe je dus wat speciaals met de OPC_IMM_PACKET als het DCCext is, dat is wel een mooie feature :) Wat doe je dan met de repeat count van OPC_IMM_PACKET?
Die wordt vervangen door het aantal in de centrale ingestelde wissel-commando herhalingen.
De speciale behandeling was/is nodig, omdat andere protocollen wel een specifiek commando voor DCCext hebben. En omdat "mijn" centrales opgebouwd zijn rond een conceptuele, event-driven, kernel, was dat niet zo heel ingewikkeld.
Zo... lang antwoord, maar leuke discussie (y)
Grtzz,
Karst
-
Kan je via de global railcom detector ook horen dat decoders hun 'rijpakketjes' hebben ontvangen met het doel dat je niet hetzelfde pakketje 10~20x hoeft te herhalen om een snelle responstijd te garanderen. Ik denk als elke decoder en tevens accessoire decoder hun commando's kunnen bevestigen (al is dat met een enkele bit), dat het 'dcc plafond' aanzienlijk verhoogd kan worden :)
Ik las dat ooit op dccwiki, maar ik heb nooit onderzocht of de centrales die we hebben dit ook daadwerkelijk doen of niet.
With the help of RailCom ...
Any commands which are received can be acknowledged by the decoder, increasing the operational reliability and bandwidth of the DCC System, since commands that have already been acknowledged will not require repetition.
Het grootse probleem naar mijn mening is, dat je óf van 0 beginnen moet, óf je hele bestaande installatie moet vervangen
Refereer je hier naar software of hardware of beide? ::)
Mvg,
Bas
-
Kan je via de global railcom detector ook horen dat decoders hun 'rijpakketjes' hebben ontvangen met het doel dat je niet hetzelfde pakketje 10~20x hoeft te herhalen om een snelle responstijd te garanderen. Ik denk als elke decoder en tevens accessoire decoder hun commando's kunnen bevestigen (al is dat met een enkele bit), dat het 'dcc plafond' aanzienlijk verhoogd kan worden :)
In theorie is dat inderdaad mogelijk, alleen moet er dan een verbinding zijn tussen alle "Global" detectors en de centrale. Immers als er een Booster in het spel is ( die dan zijn eigen "Global" moet hebben ) "ziet" de Global van de centrale de berichten in de booster sectie niet.
Verder is het leuk, maar wat als er een stroomonderbreking is naar de decoder toe. Wat gaat die dan doen ? Onthouden wat er het laatst gestuurd is ? Overigens is een slim geprogrammeerde refresh-stack zodanig ingericht, dat veranderingen direkt aan de kop van de queue komen en dus nauwelijk ( enkele millisecoden ) vertraging ondervinden. Het DCC-plafond wordt alleen zichtbaar/merkbaar als er vele, vele commando's quasi tegelijkertijd afgevuurd worden door b.v. besturingssoftware.
Refereer je hier naar software of hardware of beide? ::)
In eerste instantie de hardware. Software ( besturing bedoel je ? ) heeft meestal wel een optie andere protocollen te begrijpen.
Grtzz,
Karst
-
Ik las het op op BNLS een keer van mr Dombug dat een ecosII soms wisselpakketjes niet op de baan wilde zetten. Het bleek dat die ecos te druk bezig was met treinpakketjes. Die kon betrouwbaar maar 7 trein simultaan laten rijden te samen met accessoires. Toen alle wissels op een 2e centrale gingen, kon er naar het schijnt 14 trein probleemloos rijden. Daarom bedacht ik me, als elke laatste decoder gewoon zegt: acknowledged. Dat de mensen met grote banen meer trein met minder problemen kunnen laten rijden. Als er 5 treinen tegelijk moet afremmen van iTrain, zou het enorm schelen of je pakketjes nu blind 20x uitstuurt of dat ze na de 1e keer al ge'ackt worden. Alleen ik zal zelf nooit zo'n grote baan hebben dat ik dit probleem 'mag' ervaren :'(
alleen moet er dan een verbinding zijn tussen alle "Global" detectors en de centrale.
Je boosters hebben toch loconet :P.
Verder is het leuk, maar wat als er een stroomonderbreking is naar de decoder toe
Gewoon verder gaan wanneer zijn cyclisch herhaalde instructie weer voorbij komt (en je rails poetsen om te voorkomen dat ze uitvallen in de eerste plaats ;D)
Maar je zegt hier iets interessants. Als een trein een x aantal keer op rij geen pakketjes ackt, dan kan je centrale en daarmee iTrain oid weten dat die trein is uitgevallen. Een mobile/central station gaat ook knipperen als je je mFx lok van je baan plukt.
In eerste instantie de hardware.
Ik weet niet met welk pakket je werkt. Maar ik doe bijvoorbeeld in KiCad veel met hierarchische sheets werken en ik kan daarbij stukken board recyclen. Dat + mijn geliefde 'replicate layout' en 'place footprint' plugins zijn geweldig. Maar ik mis eigenlijk design blocks. Ik heb dit verder uitgedacht. Als je op voorhand rondom bijvoorbeeld een uProcesser, en bijvoorbeeld een Loconet circuit een beetje ruimte reserverveert. Dan kan je in 5 minuten tijd van een pcb ontwerp ff de microprocessor swappen. Je moet er alleen er voor zorgen dat de voor-geroute printsporen bij je nieuwe uProcessor blok op dezelfde plaats eindigen als de oude. Daarvoor zou ik dan een dummy connector(s) gebruiken op vaste locatie(s).
Met zelfde wijze kan je een loconet terugmelder bijvoorbeeld in no time omzetten naar de BiDib equivalent. Dit moet je dus allemaal bedenken voordat je begint..... Ik had dit echt veel eerder moeten bedenken ::)
Ik was zo wel ongeveer een uur bezig met een loconet current sense terugmelder. Toen die klaar was, volgde de OPTO variant 10 minuten later. Dat zal je vast ook wel hebben?
Ik ga iig weer weekend vieren, morgen weer papadag :angel:
Mvg,
Bas
-
Je boosters hebben toch loconet :P.
Juist dit soort info wil je niet via een besturings bus rond pompen... ;) :P
Gewoon verder gaan wanneer zijn cyclisch herhaalde instructie weer voorbij komt (en je rails poetsen om te voorkomen dat ze uitvallen in de eerste plaats ;D)
Die komt dus niet meer wanneer je eenmaal een ACK hebt gehad. Althans dat is het voordeel dat voorgespiegeld wordt ;)
Maar je zegt hier iets interessants. Als een trein een x aantal keer op rij geen pakketjes ackt, dan kan je centrale en daarmee iTrain oid weten dat die trein is uitgevallen. Een mobile/central station gaat ook knipperen als je je mFx lok van je baan plukt.
Dat kan met de DR5088RC methode ook. Die meldt dan gewoon "Decoder heeft Sectie verlaten". En als iTrain hem niet zelf heeft weggestuurd, kun je aannemen dat er een probleempje opgetreden is ;)
Ik weet niet met welk pakket je werkt. Maar ik doe bijvoorbeeld in KiCad veel met hierarchische sheets werken en ik kan daarbij stukken board recyclen. Dat + mijn geliefde 'replicate layout' en 'place footprint' plugins zijn geweldig. Maar ik mis eigenlijk design blocks. Ik heb dit verder uitgedacht. Als je op voorhand rondom bijvoorbeeld een uProcesser, en bijvoorbeeld een Loconet circuit een beetje ruimte reserverveert. Dan kan je in 5 minuten tijd van een pcb ontwerp ff de microprocessor swappen. Je moet er alleen er voor zorgen dat de voor-geroute printsporen bij je nieuwe uProcessor blok op dezelfde plaats eindigen als de oude. Daarvoor zou ik dan een dummy connector(s) gebruiken op vaste locatie(s).
Met zelfde wijze kan je een loconet terugmelder bijvoorbeeld in no time omzetten naar de BiDib equivalent. Dit moet je dus allemaal bedenken voordat je begint..... Ik had dit echt veel eerder moeten bedenken ::)
Interessant, maar ik heb denk ik je vraag niet/verkeerd begrepen ;) Ik bedoelde wanneer je als EIND gebruiker wilt overstappen op BiDiB ;) En ja, een ieder "sane" ontwikkelaar doet het op die manier. Om van de YD6016LN de YD6016RB te maken kostte zonder het routen ook maar een kwartiertje of zo. :P
Grtzz en weekend-ze,
Karst
-
Ik bedoelde wanneer je als EIND gebruiker wilt overstappen op BiDiB
Oops :-X die had ik niet door :-[
-
Het grootse probleem naar mijn mening is, dat je óf van 0 beginnen moet, óf je hele bestaande installatie moet vervangen. En laat dat nou net iets zijn, dat nou niet echt tot acceptatie voert. Een ander merk heeft onder andere als motto: "COMPATIBILITY is ESSENTIAL"
Dat ben ik met je eens. Als techneut vind ik Bidib prachtig, maar om mijn bestaande spullen weg te doen en helemaal opnieuw te beginnen, is niet realistisch. Ik haal wel graag ideeën weg bij Bidib, omdat Wolfgang Kufer op electronica gebied toch veel meer weet dan ik. Je ziet ook precies wat er in de Bidib hard en software zit, en in die zin is het wel weer een heel open systeem. Maar Bidib in een Arduino omgeving gebruiken, of omzetten naar een andere processor, is weer niet triviaal (CRC, DMA, ...), dus in die zin is Bidib vrij gesloten.
Maar het is maar net wat je onder de term "Open" verstaat. Persoonlijk vind ik Z21, XpressNet, WiThrottle allemaal behoorlijk Open: goede, publieke specificaties, die voor iedereeen zonder restricties te gebruiken zijn
Ook daar ben ik het helemaal mee eens. Vraag aan Karst: is er binnen de rail community geen interesse om van XpressNet / Z21 / ... een RCN te maken? Of willen de fabrikanten graag zelf de controlle houden?
Overigens, ik had Lenz ook gevraagd of ze het extended accessory command van plan zijn te implementeren. Hierbij het antwoord:
Nach Rückfrage bei unserer Entwicklungsabteilung kann ich Ihnen mitteilen, das wir dies planen, aber leider noch keinen Termin nennen können.
Groet, Aiko