Dreiwegeweichen und BiDiB

[TF50]

Hallo,

ich bin neu bei WinDigipet. Habe allerdings Erfahrung mit digitalen Steuerungen. Ich entwickle meine Elektronik einschl. Firmware selbst und benutze BiDiB als Protokoll.

Nun folgende Frage: Für Dreiwegeweichen werden 2 Dekoderadressen bei den Magnetartikeln eingetragen. Man erwartet, dass diese auch beim Stellen benutzt werden.

Das scheint aber WinDigipet nicht so umzusetzen. In meinem BiDiB Datalogger stellt sich das Stellen als 3-Begriffiger Magnetartikel dar.
Auszug aus DataLog:
Master-> MSG_ACCESSORY_SET:        06 05 00 14 38 00 00  -> erster Antrieb Begriff 0
Master-> MSG_ACCESSORY_SET:        06 05 00 14 38 00 01  -> erster Antrieb Begriff 1
Master-> MSG_ACCESSORY_SET:        06 05 00 14 38 00 02  -> erster Antrieb Begriff 2

Die vorletzte Ziffer ist die Dekoderadresse und die letzte Ziffer der Begriff. Auf Grund der Einstellungen (Anhang) hätte ich deshalb folgende BiDiB Befehle erwartet:
Master-> MSG_ACCESSORY_SET:        06 05 00 14 38 00 00 -> erster Antrieb gerade
Master-> MSG_ACCESSORY_SET:        06 05 00 14 38 00 01 -> erster Antrieb abzweig
Master-> MSG_ACCESSORY_SET:        06 05 00 14 38 01 00 -> zweiter Antrieb gerade
Master-> MSG_ACCESSORY_SET:        06 05 00 14 38 01 01 -> zweiter Antrieb abzweig

Dreiwegeweichen haben im Normalfall zwei unabhänige Antriebe.
Wo liegt der Fehler?
 
sorry hatte ich vergessen. Die Frage können eigentlich nur die WinDigipet Entwickler beantworten.

[ottochen (Thomas)]

Hallo,

darf ich Dir die Frage auch beantworten, lass einfach die zweite Adresse weg :-) dann funktioniert es! Habe ich auch so mehrfach in Benutzung. Du erstellt ein Accessorie mit 3 Begriffen.. links gerade rechts..

[TF50]

Hallo,

Danke für den Vorschlag. Aber das was Du beschreibts ist ja genau das Problem. Ob mit einer Adresse oder zwei Adressen. Es werden immer 3-begriffige Magnetartikel angesprochen. Das hatte ich versucht mit dem Protokollauszug zu verdeutlichen. Das habe ich meinen Dekodern auch noch nicht beigebracht. Aus meiner Sicht sollte das auch nicht notwendig sein. Wenn zwei Adressen eingetragen werden können, hofft man, dass auch zwei Adressen benutzt werden.

Warum nur 3-begriffige Magnetartikel angesprochen werden und nicht wie suggeriert zwei Adressen benutzt werden, können nun mal nur die Entwickler beantworten.

Gruß

Thomas

[Markus Herzog]

Hallo Thomas,

das Formular ist ja erstmal generell (es folgen zwar schon je nach System Anpassungen, aber das hat irgendwann ein Limit). Und für die allermeisten Protokolle braucht man auch zwei Adressen. So auch wenn man via BiDiB und DCC-Zubehördekoder ansteuert.

Aber wenn man die Betriebsart Accessory verwendet, dann wird genau ein Accessory verwendet mit den Aspects 1-x. Je nachdem wieviele Begriffe das Objekt nunmal hat.

Zitat BiDiB-Protokoll:

Weichen und Signale (allg. Objekt) haben einen 'Begriff' (=Aspect), den sie darstellen können oder auf den sie schalten können. Typische Weichen haben z.B. 'gerade' und 'Abzweig', aber im Sinne dieser Norm fallen auch Mehrwegweichen, Drehscheiben und Schiebebühnen unter den Begriff Weiche. Bei einer Drehscheibe ist der 'Begriff' dann der jeweilige Abgang.

Und eine Dreiwegweiche hat dann die Begriffe 1-3 (bzw. 0-2). Eine Kreuzung die Begriffe 1-4.

So auch seinerzeit mal mit Wolfgang Kufer als BiDiB-Author besprochen. Ein Accessory soll komplett den Zubehörartikel mit allen Zuständen abbilden und dies nicht auf mehrere verteilt werden.

Grüße
Markus

[TF50]

Hallo Markus,

danke für die Erläuterungen. Ich kenne die Definitionen von BiDiB. Die kann ich aber in diesem Zusammenhang so richtig nicht nachvollziehen.

1. Drehscheiben und ähnliches sind Objekte mit einem Antrieb und mehr als zwei Stellungen. Dort ist die Mehrbegriffigkeit angebracht und notwendig.

2. Weichen aller Art (Dreiwege-, Doppelkreuzungsweichen) sind zweibegriffige Magnetartikel, die aus einem (einfache Weichen) oder mehr als einem unabhängigen Antrieb bestehen. Hier jeweils zwei Begriffe pro Antrieb. Das ist der grundlegende Unterschied. Deshalb sollten man diese auch über ihre Adressen ansprechen können. Das sollte die Grundoption bei allen Protokollen sein.

3. Natürlich kann man man, bei einem konfortablen System wie BiDiB, diese Funktionen auch logisch zu einem Magnetartikel mit mehreren Begriffen binden und die Konfiguration in den Node verlegen. Gewöhliche BidiB Weichendekoder sprechen im Grundzustand pro Adresse einen Antrieb an.
Die nächste Frage stellt sich bei der Rückmeldung. Meine Weichendekoder sind mit einer echten Positionsrückmeldung versehen, die auch an Win-Digipet weitergegeben wird. Wie kann ich die, bei nur einer Adresse, in Win-Digipet konfigurieren. Darauf möchte ich wegen der größeren Sicherheit nicht verzichten.

Der Vorteil der einfachen 2-Adressvariante ist die Möglichkeit der Konfiguration an einer Stelle, hier Win-Digipet.
Andernfalls muß man dem BiDiB-Node per CV beibringen, dass er zwei Ausgänge zu einem Magnetartikel zusammenbinden soll. Also die Konfiguration schon an zwei Stellen. Bei Ausfall und Wechsel eines Nodes, das soll ja vorkommen, ist dann der Fehler schon vorprogrammiert.

CV Programmierung habe ich in Win-Diogipet noch nicht gefunden. Das kann aber an mir liegen. Im Moment habe ich mich erst 4 Wochen intensiv mit der Demo beschäftigt und heute die Vollversion bekommen.

Vielleicht kann man ja über die 2-Adressvariante auch für BiDiB mal nachdenken.

Gruß

Thomas

[ottochen (Thomas)]

Hallo Thomas,

ich bin bei mir wie folgt vorgegangen:

3 Macros erstellen jeweils mit den beiden zusammenschalteten Antrieben
und das ganze dann als Accessorie hinterlegt mit 3 Stellungen... incl der
Endlagenerkennung von der OneControl funktioniert das ganze hervorragend.
Dann die entsprechende Adresse einstellen und die Weiche macht was sie soll!

Wenn Du möchtest, mache ich Dir auch noch einen Screenshot aus meiner Konfiguration!

Weichen aller Art (Dreiwege-, Doppelkreuzungsweichen) sind zweibegriffige Magnetartikel, die aus einem (einfache Weichen) oder mehr als einem unabhängigen Antrieb bestehen. Hier jeweils zwei Begriffe pro Antrieb. Das ist der grundlegende Unterschied.

Meine Fleischmann DWW müssen immer beide Antriebe geschaltet werden... um die richtige Stellung zu haben!

[Dieter Trudel]

Hallo, Thomas,

leider waren vor mir 2 schneller, und nun ist mein Beitrag weg, weil ich die Warnung nicht ernst genommen hatte.
Also nochmal.
Es stimmt eben nicht, dass die DWW ein 2-begr. MA ist. Sie hat 3 Zustände=Aspekte. Die einfachen DCC-Decoder beherrschen aber nur 2 Zustände. Um die DWW, DKW u. a. zu schalten, müssen eben auch in WDP 2 Adressen angegeben werden, die die DCC-Decoder ja auch real haben.
Meines Wissens sind aber auch in DCC echte Acc.-decoder definiert.
Du hast nun ein modernes Digitalsystem, dass nicht mehr mit dem Klimmzug, einen 3-begr. MA mit 2 Adressen zu bedienen, arbeiten muss. Du kannst und solltest das auch nutzen. Du kannst in WDP zwar die BiDiB-Makros und sogar die ports ansprechen, das ist aber nicht im Sinne von BiDiB, wenn manchmal auch sehr bequem.

Du definierst deine 3 Makros für R, G, L und testest diese. Es ist dabei noch zu beachten, dass du für die einzelnen Begriffe die richtige Schaltreihenfolge wählst, damit sich die Zungen nicht behindern (Z. B. Bei DWW-Profigleis von Fleischmann).

Im nächsten Schritt definierst du dein accessory: R = 0, G = 1, L =2 und testest es. Die Reihenfolge ist wichtig (Thomas hat es oben wohl anders angegeben) und kann in WDP nicht geändert werden bei Benutzung als 3-begr. MA. Diese acc.-nummer trägst du nun als erste und einzige Decoderadresse ein. Achtung: 0..19 bei BiDiB entspricht 1..20 bei WDP.

Nun sollte die DWW bei dir ebenso wie bei mir funktionieren.

Nun dein Problem mit der Rückmeldung. Auch hier muss ich sagen, du hast ein modernes Digitalsystem. Ich gehe mal von einer Onecontrol aus als Schaltdecoder. Dort hast du 16 GPIO's, die im Normalfall als Eingang defniert sind. Auf diese Eingänge legst du nun deine Stellungsmelder und verarbeitest die Information in deinen Makros. Die positive Rückmeldung des BiDiB-Knotens an WDP erfolgt nur, wenn deine Stellungsrückmelder die richtige Stellung anzeigen. Du brauchst doch dafür nicht die Stellungsrückmeldung von WDP bemühen.
Genau das ist doch einer der fundamentalen Vorteile des bidirektionalen Systems, dass zu jedem Aktionsbefehl eine Rückmeldung über den Erfolg gesendet wird. Du kannst das übrigens gut im Wizzard an dem grünen Haken bzw. dem roten Ausrufezeichen bei Abarbeitung des accessories beobachten.

[TF50]

Hallo Thomas,

nochmals dank für Deine Bemühungen. Deine Vorschläge lösen nicht das Problem.

1. Die BiDiB Definitionen verlangen nicht, dass normale Weichendekoder Macros beherrschen müssen. Diese sind aber notwendig um deine Vorschläge umzusetzen.

Die Konfiguration des zu schaltenden Objektes (ob das Objekt mit Magnetantrieb, Servo, Stepper, Lichtsignal, Formsignal usw. kontrolliert wird) obliegt dem Dekoderhersteller ...

2. Ein Steuerprogramm sollte aber auch die minimal Forderungen, die ein Standard vorgibt, bedienen.

3. Ich kenne die Möglichkeiten der BiDiBone Module.  Die sind mir aber viel zu teuer. Deshalb entwickle ich meine Module selbst. Für mich kostet ein kompletter Dekoder vom BE-Preis die hälfte eines BiDiBone Moduls. Der Rest ist eben Hobby. Wenn man ca 100 Weichen bedienen muß und über 300 Rückmeldekontakte hat, die  Signale noch gar nicht mitgerechnet, ist das ein entscheidendes Argument.


Und noch eine Antwort auf Dieters Post. Was ist modern? Modern ist kein Standard.

MfG

Thomas 

[Dieter Trudel]

Hallo, Thomas,
ich wollte dir keineswegs auf den Schlips treten. Aber eine Dikussion über modern scheint mir doch nicht angemessen.
Ich hatte dein Profil in Sachen Eigenentwicklung schon gelesen. Sorry, ich konnte nicht ahnen, dass du, die sicher zulässige Minimalvariante, benutzt. Bei mir ist auch alles Eigenbau, oder besser Nachbau der Produkte eines exzellenten Entwicklerteams. Und damit bin ich recht glücklich.

[TF50]

Hallo Dieter,

das liegt wohl am Fußball nebenbei. Auch ich wollte Dir nicht zu nahe treten. Ich profitiere genau wie Du von diesem Team. Zumindest im reinen Interface-Teil.

MfG

Thomas

[ottochen (Thomas)]

Hallo Thomas,
dann zeichne dein Gleisbild ein klein wenig um,so das es 2 einzelne Weichen sind... dann funktioniert auch Deine Ansteuerung..

[TF50]

Hallo Thomas,

unglaublich, wie viele Gedanken Du Dir machst. Danke.

Auf diesen vorübergehenden workaround bin ich auch schon gekommen.

Vielleicht noch einige Bemerkungen zu mir. Ich bin schon seit 2007 Mitglied in diesem Forum, hatte nur meine Anmeldedaten nicht gleich gefunden, weil ich Win-Digipet damals nicht lange benutzt habe.

Seit 2012 entwickle ich für BiDiB, allerdings nur aus Spass an der Freude. Bis jetzt habe ich eine andere Steuersoftware benutzt, die mich im Fahrverhalten aber nicht mehr befriedigt hat. Deshalb hatte ich mich wieder an Win-Digipet erinnert. Im Schaltverhalten gab es mit der anderen Software keinerlei Probleme.  Nach ausgiebigen Tests des Fahrverhaltens mit der Demo, war ich überzeugt, den finanziellen Ruin in Kauf zu nehmen und Win-Digipet zu beschaffen. Natürlich nur mit Einverständnis des Finanzministers. Und nun habe ich Probleme, die ich vorher nicht hatte.

Deshalb meine Hartnäckigkeit.

MfG

Thomas

[Markus Herzog]

Hallo Thomas,

2. Ein Steuerprogramm sollte aber auch die minimal Forderungen, die ein Standard vorgibt, bedienen.

Und was wird da nicht bedient?

Werde aber die Sache Accessory gerne mal mit Wolfgang Kufer diskutieren, würde mich aber wundern wenn ich die Protokollintention da falsch verstanden hätte:
http://www.bidib.org/protokoll/bidib_general.html
Schau mal die Namen unter 1.2 und 1.3.

Grüße
Markus

[BBII]

Guten Tag,

die Grundidee bei den Accessory-Befehlen: es gibt _ein_ Objekt, welches dem Fahrweg zugeordnet ist. Dieses Objekt ist im einfachsten Fall eine Weiche oder ein zweibegriffiges Signal, kann aber auch mehr Begriffe haben: Dreiwegweiche, Drehscheibe, 8-begriffiges Signal. Aber immer ist an dieser Stelle _ein_ Objekt.

Das macht auch Sinn, weil dieses Objekt nur einen Zustand einnehmen kann. Würde man so ein Objekt auf mehrere Instanzen aufteilen, dann können sich undefinierte oder sogar gefährliche Zustände ergeben: z.B. bei manchen Dreiwegweichen oder DKWs muß die Schaltreihenfolge genau eingehalten werden, sonst gibt es Kurzschluß über die Backenschienen. All diese lokalen Probleme sollen bitte auch lokal gelöst werden und deshalb wurde die Definition in BiDiB so angelegt. Auch würde sich eine Positionsabfrage (welcher Begriff wird gerade dargestellt, wo steht die Scheibe?) schwierig gestalten. Auch kann man via Accessory-Parametern einstellen, ob der Begriff beim Aus-Einschalten von der Hardware wieder eingestellt wird.

2. Weichen aller Art (Dreiwege-, Doppelkreuzungsweichen) sind zweibegriffige Magnetartikel

Eben nicht. Eine Dreiwegweiche hat drei Stellungen: links, gerade, rechts, diese schließen sich gegenseitig aus. Ob diese drei Stellungen mit 2 Spulen, Stellmotor (FallerCar-Weiche) oder wie auch immer realisiert sind, spielt beim (Fahrweg-)Objekt Weiche keine Rolle.

Die nächste Frage stellt sich bei der Rückmeldung. Meine Weichendekoder sind mit einer echten Positionsrückmeldung versehen, die auch an Win-Digipet weitergegeben wird. Wie kann ich die, bei nur einer Adresse, in Win-Digipet konfigurieren. Darauf möchte ich wegen der größeren Sicherheit nicht verzichten.

Aber hier kommt doch gerade der Vorteil des _einen_ Objektes zum Zug: Nur der Accessory-Dekoder hat Kenntnis darüber, wie er die Lage auswerten kann: sind das Hallmagnete, endgeschaltete Spulen, Kameraüberwachung und Bildvergleich - egal, es entsteht _ein_ Begriff: so steht die Weiche jetzt.

Ich bin absolut dagegen, diese saubere Definition aufzuweichen und in wdp irgendwie doch wieder zwei oder mehr Schaltvorgänge zu definieren, die logisch auf ein Accessory-Objekt zusammenlaufen.

Ich entwickle meine Elektronik einschl. Firmware selbst und benutze BiDiB als Protokoll.

Ich würde darum bitten, sich auch an die Lizenzbedingungen zu halten. Zum einen geht um Sicherstellung der Kollisionsfreiheit von UniqueIDs, zum anderen auch um solche Themen wie hier. Das Protokoll definiert und erklärt ein bestimmtes Verhalten von Accessory, Gleisausgabe, Belegtmeldern usw. Alle Beteiligten vertrauen darauf, das die jeweiligen Kommunikationspartner (PC, Handregler, Analyseprogramme, usw.)  von den gleichen Dingen reden und auch das Gleiche darunter verstehen. Sollten dabei Fragen, Unklarheiten oder weitere Anforderungen entstehen, sind wir gerne bereit, das Für und Wider zu besprechen, abzuwägen und auch Anpassungen vorzunehmen.

Mit freundlichen Grüßen

Wolfgang Kufer, www.bidib.org

[Markus Herzog]

Hallo Wolfgang,

danke für die Stellungsnahme. Dann habe ich das ja richtig verstanden.

Und dann bleibt es bei Accessorys genauso wie es ist.

Grüße
Markus