www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS 485 Lenz X-Bus


Autor: Josef Öttl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.
Ich bin auf der Suche für die Steuerung eines Weichenstellpultes über
Tasten für meine Gartenbahn die mit einer Lenz-Digital Plus Steuerung
und Zimo Weichendecoder gesteuert wird.  Problem ist die umständliche
Bedienung über die Handsteuergeräte. Eine PC-Steuerung möchte ich
grundsätzlich nicht verwenden. Mein Wunsch wäre eine Tastensteuerung
auf die Eingängne eines Microcontrollers der über den X-Bus (RS485) die
entsprechenden Schaltbefahle an die Zentrale weitergibt. Hat jemand so
etwas bereits realisiert?.

Mit freundlichen Grüssen
J. Öttl

Autor: plitzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Josef,

nein, realisiert habe ich soetwas noch nicht, aber es geistert mir
bereits seit längerem im Kopf herum. Ich habe bereits einen eigenen
Handregler "geplant" und prinzipiell ist ein Weichenkeyboard an einer
Lenz-Zentrale da ja auch nicht viel anders. Grundlage für die Software
müsste dabei das von Lenz recht ordentlich dokumentierte
XPressNet-Protokoll sein. Dort kann man recht gut erkennen, mit welchen
Befehlen die Zentrale die Handregler abfragt usw. Ist ein ganzes Stück
Arbeit, aber keine Hexerei. Leider habe ich bisher noch keine
Lenz-Zentrale zur Verfügung (die Dinger sind ja nicht gerade billig,
auch nicht gebraucht) und so existiert das Ganze bisher nur auf dem
Paier und in meinem Kopf. Ich habe auch schon daran gedacht, eine
Zentrale für DCC selbst zu programmieren, aber das ist bisher auch
ersteinmal nur eine Idee (wer eine "fertige" Lösung kennt...).

Jörg

Autor: josef Öttl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Plitzi. Erstmal vielen dank für die Rückantwort. Grundsätzlich
dürfte es keine allzu grossen Ürobleme geben so etwas zu realisieren,
da ja nur in eine Richtung gesendet wird. wie du ja anmerkst, ist das
x-bus Protokoll sehr gut dokumentiert. Man könnte die schaltbefehle ja
auch mit einem oszi
rausbekommen. sich ändernde Parameter sind ja letztendlich nur die
Weichenadresse. Leider habe ich kein Oszilloskop und keine Ahnung, wie
ich eine RS485 Busverbindung realisieren kann. Treiberbaustein usw.
max485 ist klar. Mein Gedanke geht hier Richtung Atmel Atmega. Mit
diesem MC kenne ich mich etwas aus. Wo aber der RS485 Bus angeschlossen
wird (RXD/TXD) ist mir nicht klar, da diese Anschlüsse ja bereits zur
Programmierung benötigt werden. oder sehe ich das falsch. Diesbezüglich
sind meine Hardwarekenntnisse etwas dürftig.

Gruss Josef

Autor: plitzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal meinen Entwurf für einen Handregler als XPressNet-Gerät
angehängt (gibt es bisher nur auf Papier). Dort ist die Realisierung
der RS485 zu erkennen. Als Weichenstellpult würde das Poti entfallen.
Das Protokoll an sich braucht man aber nicht "abzulauschen" da es ja
dokumentiert ist. Ich habe aber wie gesagt bisher noch keine Zeit und
Gelegenheit gehabt, das Ganze ernsthaft anzugehen. Aber vielleicht
hilft Dir ja der Schaltplan schon mal weiter;)

Jörg

Autor: josef Öttl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg.
Danke für die prompten Antworten und für Deinen Entwurf. Ich werde mir
das mal in Ruhe anschauen.

Josef

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine andere Möglichkeit wäre die Verwendung des Lenz Interface LI100
(gebraucht preiswert, da bereits zwei Nachfolger existieren), welches
die Umsetzung von RS-232 auf RS-485 schon erledigt. µC macht die
Tastenabfragen und sendet an der seriellen Schnittstelle (und bekommt
dann auch die Rückmeldung als Broadcast).

Thomas

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo topla,
habe ich mir auch schon überlegt. Ich habe ein Interface. Modern wie
ich bin, aber in der usb-Ausführung. Ich habe meinem Atmega32 deshalb
einen max 485 spendiert und vesuche momentan in Bascom die paar Befehle
zum Schalten meiner Weichen der Zentrale beizubringen. Eigenartigerweise
funktioniert das Ganze an meiner Compact. Die Zentrale LVZ100 bringt mir
jedoch immer die Fehlermeldung "Transfer Error" obwohl die
Schaltbefehle am LS100 ankommen. Mir fällt nur auf, das die LED am
LS100 nicht mehr ausgeht. Teste ich das ganze mit der Handsteuerung,
sehe ich, dass die Bus-LED am LS100 solange brennt, bis ich die Taste
wieder loslasse. Am Atmel-Display sehe ich,
dass beim Loslassen sofort eine anderer Befehl kommt.
Beispiel:
Senden Weiche 1 - ein (Taste gedrückt) - Code 52 00 89 DB
Taste losslassen: 52 00 81 D3
anschl. sehe ich eigentlich nur noch das Polling der RS485 Adressen.
Offensichtlich ist es ein Timing-Problem zwischen Atmel und Lenz
Zentrale. In der englische Beschreibung des Protokolles sehe ich nicht
genau, wie das Handling zwischen Empfang und Senden ausschauen muss.
Eventuell liegt es jedoch auch meinen beschränken Englischkennissen.

Josef

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich beschäftige mich gerade mit der Weiterentwicklung des LW100 und
habe da gerade mal über den Code für den XBUS-Verkehr geschaut. Deine
Fehlermeldung scheint die Ursache in einer fehlerhaften Prüfsumme zu
haben, zumindest sagt das die Doku. Entzerre doch mal die Sendefolge,
also beim Sendeinterrupt eine kleine Zeitschleife (NOP) einfügen und
auch das Umschalten auf Sendebetrieb nicht zu schnell erledigen. Das
LW100 ist da ziemlich umständlich programmiert und es geht gemütlich zu
(DS80C320 mit 4MHz). Den zweiten Befehl, also das Ausschalten des
LS100-Ausgangs beim Loslassen der Taste, sendest Du aber auch an die
Zentrale? Sonst bleibt die LED an, da die Zentrale weitersendet
(DCC-Seite).

Thomas

einen RS-485-Sniffer müsste ich auch mal bauen....
Da fällt mir noch ein:
Siehst Du denn dann auch die Rückmeldung (Broadcast) von der Zentrale,
mit der die Stellung der Weiche am LS100 rückgemeldet wird? Sollte
keine Weiche am LS100 sein (bzw. der RS-Bus nicht angeschlossen sein),
dann könnte eventuell auch das die Ursache der Fehlermeldung sein.
Rückmeldung sollte auch bei Handbetätigung der Weiche kommen.

Autor: guenter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo topla
Hallo Josef

welche Baudrate habt ist definiert ?
Lenz sendet / verarbeitet normalerweise  mit 19200 Baud

ein gutes Selbstbau-Projekt (mit Lenz-xPresnet 3.0) gibt es hier

http://www.macurb.de

Günter

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo guenter,

laut Lenz xpressnet specification arbeitet der rs485 mit
62500 bps , 1 Startbit, 9 Datenbits, 1 Stopbit, kein Parity bit. Das
neunte Bit wird von der Zentrale als Adressbit verwendet. Ist dieses
Bit gesetzt, wissen die Slaves, das empfangene Byte ist eine Adresse.
In Bascom ist der Initbefehl für den Uart:
$baud = 62500 'UART-Baudrate: 62500 Baud
Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 ,
Databits = 9 , Clockpol = 0

Mit dieser Einstellung kann ich den RS485 über den Uart auch
einwandfrei abhorchen.
Bascom Befehl:
Inputbin T1
If T1 = &H52 Then Goto Call52
&H52 kommt als 1. Byte (Headerbyte) von einem Handsteuergerät wenn eine
Weiche zu schalten ist.
19200 Baud verwendet Lenz zwischen Interface LI100 und PC Schnittstelle
auf der RS232 Seite.
Ich kennen die macurb Seite. Bisher habe ich jedoch kein
Zugangspasswort für den geschützen Bereich um mir nähere Infos zu
holen.

Gruss Josef

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo tobla,
ich freue mich ja unheimlich, dass mein Thread jetzt doch noch mehrere
freaks aufgeweckt hat. Dachte schon das meine Probleme keinen
interessieren. Aber jetzt zu deiner Frage:
Bei gedrückter Taste am LH30 oder LH100 sendet das Gerät für Weiche 1
den Befehl Code 52 00 89 DB
Lasse ich die Taste los kommt: 52 00 81 D3
War die Weiche bereits in diese Richtung gestellt, kommen anschl. nur
noch Adressbytes zwischen 0x41 und 0x5F (offensichtlich Pollbytes der
Zentrale). War die Weiche noch nicht in diese Richtung gestellt, sendet
offensichtlich die Zentrale sofort nach dem Befehl
52 00 89 DB die Bytefolge A0 42 00 01 oder ... 02 als Feedback zurück.
Das Senden des Aus-Befehles habe ich auch schon versucht. Bringt
vermutlich aber nichts, solange der Einbefehl nicht fehlerfrei (keine
Meldung Übertragungsfehler) ankommt. Ich vermute, dass das Timing beim
Senden meines Atmels nicht stimmt. Versuche mit verschiedenen Wartezeit
nach dem Umschalten auf Senden sowie zurück auf Empfang brachten bisher
keinen Erfolg.

Gruss Josef

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag an Tabla:
RS Rückmeldbus habe ich nicht verdrahtet. Weichenrückmeldungen über den
RS-Bus kommen nicht bei Handschaltung der Weiche, da keine Endschalter
montiert (LGB Weichen mit Zimo Weichendecoder).

Autor: Jörg Plitz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich richtig gelesen habe, programmierst Du das Ganze mit BASCOM und
es gibt offensichtlich ein Problem am Ende des Telegramms, welches Du
über RS485 aussendest. Dann würde ich mal "nachsehen", wann! BASCOM
den RS485-Treiber wieder zurück auf Empfangen schaltet. Das darf
natürlich erst passieren, wenn wirklich alle Bytes aus der UART rauß
sind und nicht, wenn das letzte Byte in den UART-Puffer geschrieben
wurde. Mit Assembler würde ich dazu den TX-Complete-Interrupt
verwenden. Aber wie das in BASCOM gelöst ist, kann ich nicht sagen. Ist
aber einen "Gucker" wert, oder?

Ansosnten finde ich den Ansatz mit dem Zwischengeschalteten LI100 doch
eher umständlich, wenn man es nicht schon liegen hat. Ein
Befehlsprotokoll muß man so oder so implementieren.

Jörg

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An Timingfehler glaube ich dann nicht mehr. Hast Du für Deinen
Controller eine eindeutige Adresse am XBUS vergeben? Nicht, daß es da
Kollisionen mit dem Handregler gibt. Ist das Paritybit im Header
richtig gesetzt (Bit 7)? Ist das Errorbyte richtig zusammengebaut (XOR
ohne Headerbyte)? Antwortet Dein Controller auf das dem Fehler folgende
Acknowledge-Request richtig?

Thomas

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas und Jörg,
danke für eure wirklich hilfreichen Infos. Ich habe gestern nochmals
mit den Zeiten des Umschaltens zwischen senden und empfangen
rumprobiert. Es funktioniert inzwischen. Meine Vermutung war schon
richtig, dass es am Timing liegt. Bascom verhält sich hier
offensichtlich etwas ungenau, was das Setzen von Wartezeiten mit den
Befehlen waitus= mikrosek), waitms = (mSek bzw. wait = (sek) anbelangt.
Ich habe jetzt nach Umschalten des Sendepins eine Wartezeit von 5
mikrosek und nach dem Senden meines Schaltbefehles eine Wartezeit von
100 ms eingefügt bevor ich wieder zurück auf Empfang schalte. Anschl.
sende ich den Befehl für Taste losgelassen auf die gleiche Weise.
Übrigens gibt es auf der Seite
http://projects.jusme.com/cgi-bin/projects/index.pl eine sehr gute
Dokumentation in Assembler. Leider aber nur für den PIC.

Nochmals vielen Dank für Eure Hilfe
Josef

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann herzlichen Glückwunschh! Das sind so die Gemeinheiten der
Hochsprachen, ich bleibe lieber beim Assembler. Da ich persönlich
Zeitschleifen als Rechenzeitvernichtung nicht so mag, war ich davon
ausgegangen, daß Du eine Interruptsteuerung für die Umschaltung
verwendest (also den Sendeinterrupt bzw. das entsprechende Flag
auswertest).

Thomas

Autor: guenter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo josef

>laut Lenz xpressnet specification arbeitet der rs485 mit
>2500 bps , 1 Startbit, 9 Datenbits, 1 Stopbit, kein Parity bit. Das
>neunte Bit wird von der Zentrale als Adressbit verwendet. Ist dieses
>Bit gesetzt, wissen die Slaves, das empfangene Byte ist eine Adresse.
>In Bascom ist der Initbefehl für den Uart:
>$baud = 62500 'UART-Baudrate: 62500 Baud
>Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 ,
>Databits = 9 , Clockpol = 0

>Mit dieser Einstellung kann ich den RS485 über den Uart auch
>einwandfrei abhorchen.
>Bascom Befehl:
>Inputbin T1
>If T1 = &H52 Then Goto Call52
>&H52 kommt als 1. Byte (Headerbyte) von einem Handsteuergerät wenn
>eine
>Weiche zu schalten ist.
>19200 Baud verwendet Lenz zwischen Interface LI100 und PC
>Schnittstelle
>auf der RS232 Seite.
>Ich kennen die macurb Seite. Bisher habe ich jedoch kein
>Zugangspasswort für den geschützen Bereich um mir nähere Infos zu
>holen.

>Gruss Josef

Ja, du hast Recht;
ich hab das verwechselt...:-(

Aber eine andere Frage:

in einem früherem Beitrag wurde von einem RS485-Sniffler gesprochen
Gibt es da schon einen ('fertigen') Lösungsansatz zum Nachbauen ??

Gruß
Günter

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi, hab mich grad mal reingelesen, hört sich interessant an das thema!
jedoch ist mir eine kleinigkeit in dem schema von jörg (plitzi) noch
unklar. der max481 wird doch mit 12V versorgt, oder? der eingezeichnete
spannungsregler liefert doch aber keine 12V sonder die "typischen" 5V
oder?

Vielleicht hab ich ja auch etwas falsch verstanden, bin noch ziemlich
neu auf dem gebiet...

mfg david

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MAX481 braucht 5V Betriebsspannung, siehe
http://pdfserv.maxim-ic.com/en/ds/MAX1487-MAX491.pdf .

Gruß Thomas

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo x-pressnet Gemeinde,
es ist ja interessant, wir sich inzwischen alles hier beteiligt.
Offensichtlich beschäftigen sich doch einige mit den Geheimnisses der
Lenz-Digitalsteuerung. Normalerweise muss ich mein Programm nochmals
umschreiben, da ich momentan die Auswertung des 9. Bits noch nicht
berücksichtige. Ich horche hier nur auf das Byte P+0x40+GA und gehe
davon aus, das es nicht nochmals in irgendeiner Bytefolge der Zentrale
gesendet wird. Um das Adressbyte auswerten zu können, muss beim Atmel
zuerst das 9. Bit gelesen werden (Ucsrb.rxb8)
und anschl. das Register Udr ausgelesen werden. Ich lese momentan nur
mit Inputbin var. Hier kann ich das 9. Bit nicht mehr auswerten, da es
bereits gelöscht ist, wenn ich mit inputvar arbeite. Aber ich habe ja
noch den ganzen Winter Zeit, das zu ändern.

Josef

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter,
für meine Weichensteuerung war für mich damals nur die Bytefolge der
Weichenschaltbefehle interessant. Diese beginnen immer mit 0x52 anschl.
folgen ein Adressbyte, ein Datenbyte und ein x-Or Byte. ich habe in
Bascom hierzu einfach in einer Schleife mit Inputbin V1 auf Hex(52)
gewartet. Das Absetzen der Schaltbefehle habe ich mit meiner
Handsteuerung LH30 vorgenommen.
War es 0x52 habe ich anschl. mit Inputbin V2,V3,V4 die restlichen Bytes
gelesen und mir das Ergebnis auf dem LCD für alle von mir verwendeten
Weichen (1-16) angeschaut. Diese Befehlsfolge sende ich jetzt zum
Schalten meiner Weichen. Byteweisen sniffen war nicht möglich, da die
Zentrale dauernd sendet (z.B. Geräteadressen 1..31) und das LCD-Display
hier zu langsam bzw. zu wenig Platz bietet. Hier müsste man einen Atmel
mit 2 Uarts verwenden und die Ausgabe über RS232 an den PC sendet und
dann im Terminalprogramm anschauen.

Gruss Josef

Autor: Frysk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Plitzi,
Könntest du bitte deine Entwurf für einen Handregler auch als JPG oder
PNG anhängen?

Vielen dank Frysk

Autor: Jörg Plitz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, ich war eine Weile "offline" (bin noch so ein altmodischer
Modemnutzer). Aber siehe Anhang! Das Ganze ist eigentlich nichts weiter
als ein Entwurf für eine Mikrocontroller (hier ATMega8) mit LCD,
zahlreichen Tasten, einem Analogeingang für ein Schiebepoti und als
kleine Besonderheit halt einen RS485-Treiber an der UART.

@Josef: Das Sniffen der XPressNet-Kommunikation kann man (einen
einfachen RS485->RS232 Adapter vorausgesetzt) doch gleich mit dem PC
erledigen. Für den Adapter reicht eventuell auch ein einzelner OPV, der
seine Versorgungsspannung aus der seriellen Schnittstelle bezieht.

Jörg

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da geht aber immer das neunte Bit verschütt. Ich habe das mit einem
Experimentierboard mit einem DS80C320 gemacht. Wird ein gesetztes 9.
Bit erkannt, gibt es vor der Übertragung einen 0Dh 0Ah
(Zeilenschaltung) an das Terminalprogramm.. Die PC-seitige
Übertragungsrate muß aber etwas größer sein als 62.500. Die vorhandene
PCI-RS485-Karte habe ich noch nicht zum Laufen bekommen.

Thomas

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi, hatte mich neulich schonmal kurz zu dem thema geäußert und habe
jetzt bald vor (spätestens nach weihnachten) mich mal intensiver mit
dem hier besprochenen thema auseinanderzusetzen und mal erste
erfahrungen zu sammeln.
jörg (plitzi) hat damals geschrieben, das sein schema bisher nur auf
dem papier existiert. gibt es denn inzwischen etwas neues, haben schon
andere mitglieder die schaltung auf diese (oder auch ähnliche) art und
weise aufgebaut?
was ich bisher noch nirgends gefunden hab, wieviel strom kann
eigentlich der X-Bus von der Lenz-Zentrale liefern, ich will sie
nämlich nicht schrotten und lieber auf nummer sicher gehen...

mfg david

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Solange es keine Software (und das ist nicht trivial) dafür gibt, macht
ein Nachbau einer auf dem Papier existierenden Schaltung wohl keinen
Sinn und Erfahrungen sammeln sich auch schlecht....

Thomas

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi, habe mich jetzt auch mit meinem atmel (atmega8515) und einem max485
hingesetzt und versucht mit der zentrale (lz100, version 3.2) zu
kommunizieren.
doch seit ein paar tagen bin ich am verzweifeln, ich komme nicht
weiter, ich schaffe es nicht befehle an die zentrale zu senden, dass
diese die auch "annimmt". als beispiel wollte ich "0x80 0x80"
(nothalt) senden. ich warte, bis der atmel als handregler mit der
adresse 1 angesprochen wird. das funktioniert auch, dann ziehe ich
einen pin am atmel auf high um dem max 485 in den senden-modus zu
schalten. dann sende ich "0x80 0x80" und lege erst wenn die
txcomplete -flag im UCSRA gesetzt ist, den pin der mit dem max 485
verbunden ist wieder auf low. hab mir das ganze mit einem digitalen
2-kanal oszi angeschaut. das timing scheint zu passen, der pin ist auf
high, erst dann sened ich über das uart und dann erst geht der pin
wieder auf low.

einstellungen fürs uart:
baudrate: 62500
1 startbit
9 datenbits
1 stopbit
kein parity

wenn jemand eine idee hat, wo das problem liegen könnte, würd ich mich
über hilfe freuen. oder falls jemand einen codeschnipsel hat, dann wäre
es such wenn, wenn den jemand posten könnte, ich arbeite mit
assembler...

danke schon einmal im voraus!
david

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Du hast keinen Handregler mit Adresse 1 angeschlossen.
2. Baue eine Verzögerung zwischen Empfangsinterrupt und Umschalten auf
Senden von etwa 10 Microsekunden ein.

Thomas

Autor: fmco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: David (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
schonmal danke für die tipps, hat leider auch keine abilfe geschafft.
hier mein sourcecode, der als beispiel 0x80 0x80 (Nothalt) senden soll.
Mit dem Oszi geprüft, funktioniert auch alles im entsprechenden
Zeitfenster, jedoch geht die Zentrale nicht in den Zustand "Notaus".

Nach einmaligem Senden von 0x80 0x80 scheint die Zentrale den
Handregler nicht mehr anzusprechen, er sendet nicht mehr, auch nicht
nach Reset. Erst wenn ich die Lenz-Zentrale neu starte (Strom weg und
wieder dran) kann ich wieder einmal mit dem Controller senden, erst
dann scheint er also wieder angesprochen zu werden. Woran könnte das
liegen?

Lässt man die Zeile "ldi send, 0" in "transmit:" weg, sendet der
Controller ununterbrochen 0x80 0x80. Dann geht die Zentrale
komischerweise in den Modus "Notaus".

Nocheinmal zum Verständnis:
Die Zentrale eröffnet für jeden Handregler ein Transmission-Window,
indem der Handregler etwas senden muss. Ich warte also, bis der
Controller angesprochen wird, hat hier im Beispiel die Adresse "1"
und sende dann etwas. Dannach gehe ich wieder in den Receive-Modus um
wieder für den Empfang bereit zu sein.
Habe ich noch etwas vergessen, war es das oder fehlt irgendwas???

Vielen Dank für eure Mühen, so langsam wird das Fehlersuchen nervig
;-).

Frohe Weihnachten...
David

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab ich vorhin vergessen, hier noch eine erläuterung:

PORT A ist nur zu Debug-Zwecken da, er wird bei jedem Aufruf von
"rx_complete" getoggelt.

PORT C ist mit dem Max 485 verbunden und schaltet ihn auf Senden oder
Empfangen.

vielen danke...

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe es zwar mehr mit dem 8051-Assembler und bin jetzt zu faul,
Deinen Quelltext bis ins Detail zu ergründen, aber Folgendes ist mir
aufgefallen:
1. "normal inquiry" kommt mit gesetztem 9. Bit, mir scheint, Du
wertest das nie aus. Ev. interpretierst Du ein "normales" Datenbyte
auf dem Bus als Adresse. Das daraufhin folgende Senden geht in die
Hose.
2. entzerre das mal zeitlich, ich glaube, daß das Timing ganz schön
sportlich ist (umschalten in Sendebetrieb nach Empfang Callbyte)
3. Ohne ldi send,0 ballerst Du ja ohne Punkt und Komma 80h auf den
XBUS, irgendwann erwischt Du dann auch mal ein Window und die Zentrale
reagiert.
Kann eigentlich elektrisch was passieren, wenn die RS-485-Treiber
gegeneinander antreten? Gut ist es bestimmt nicht.


Thomas

Autor: Jörg Plitz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Obwohl ich softwareseitig noch keine Erfahrungen am realen Gerät sammeln
konnte (immer noch keine Zentrale und wenig Zeit :( ), lese ich hier
weiter sehr interessiert mit. Ich habe mir auch einmal den Quellkode
des Testprogramms angesehen und dazu die diversen Dokumentationen von
Lenz überflogen.

Die Umschaltung des RS485-Treibers scheint in Ordnung (erst nach dem
TXC und nicht bereits nach dem UDRE!).
Der Befehl für das Not-Aus ist auch korrekt (kein XOR-byte vergessen
oder so).
Was mir noch einfällt ist die Problematik 9-bit-UART. Bei Lenz steht,
dass die Zentrale die Adresse des Hand-Reglers als solche markiert,
indem sie das Adressbyte mit gesetztem Bit 9 sendet und die
nachfolgenden Daten immer mit Bit 9 = 0 (damit lässt sich in den uCs
mit Multiprozessorkommunikatios-UART, z.B. 8051 oder die neueren AVRs
die Adresse schön filtern). Dieses 9.Bit wird aber im Programm gar
nicht ausgewertet (wurde aber von Thomas schon moniert). Dieses 9.Bit
wird aber natürlich empfangen und steht im UCSRB als RXB8 zur Verfügung
und sollte auch ausgewertet werden. Dazu muss in der rc_complete-ISR das
UCSRB und darin das RXB8-Bit gelesen werden, BEVOR  man das UDR abholt
und auf die eigentliche Adresse vergleicht. Ist RXB8=0 war es keine
Adresse und man kann sich weiter Auswertungen und Aktionen sparen (aber
nicht das lesen des UDR, sonst wird der IRQ nicht gelöscht!). Siehe auch
Datenblatt des m8515 Seite 143/144. Einfacher geht es wie bereits
erwähnt mit dem MPCM (Datenblatt Seite 150).

Auch beim Senden sollte man sicherstellen, dass wie verlangt mit Bit9=0
gesendet wird (ist aber wohl in dem Testprogramm zufällig? gegeben, da
TXB8 nie angefasst wird und nach einem RESET =0 ist).

Ich hoffe, ich konnte einen neuen Denkanstoß geben.

Jörg

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Umschaltung des RS485-Treibers scheint in Ordnung (erst nach dem
TXC und nicht bereits nach dem UDRE!).
Ist wohl wahr, aber es ist nicht gesagt, daß die Zentrale bei der
Umschaltung genau so schnell ist. Das LW100 z.B. legt eine Pause (u.a.
eine Zeitschleife!) von 10 µs ein und damit geht es. Ausschließen würde
ich diesen Punkt nicht so ohne Weiteres.

Thomas

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lenz-X-Bus Gemeinde,
ich möchte mich mal wieder zu meinen alten Forumbeitrag melden. Hatte 
heuer wenig Zeit um mich mit meiner Selbstbau-Weichensteuerung zu 
beschäftigen.
Inzwischen habe ich mir mein Stellpult fräsen lassen und die Verbindung 
zum Atmel fertiggestellt. Gab am Anfang einige Probleme mit der 
Ansteuerung des Displays (blau/weiss-20*4) mit Bascom und natürlich 
wieder Probleme mit dem Timing auf dem RS485-Bus. Inzwischen läuft aber 
alles wie ich mir das vorgestellt habe. David schrieb mal, dass er 
ebenfalls Probleme hatte, die Zentrale fehlerfrei zu adressieren. Ich 
hatte ebenfalls lange die gleichen Probleme. Hatte dann mit Lenz mal 
einen freundlichen, kurzen e-mail Kontakt und bekam dann eine recht 
aufschlußreiche Beschreibung, wie das Handling genau mit angeschlossenen 
Geräten ausschaut. Seit befolgenden der Hinweise bei 
Fehlerübertragungen,
funktioniert der ganze Ablauf auch ohne Assambler- und Interrupt 
Programmierung. Sollte einer Interesse haben, kann ich inzwischen 
weiterhelfen.

Gruss Josef

Autor: topla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Josef,

das interessiert mich sehr, könntest Du mir die Beschreibung von Lenz 
bitte zukommen lassen?

Gruß Thomas

Autor: Reinhard Pölzleithner (carnival)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

oben im Thread wurde der Selbstbau einer DCC-Zentrale angesprochen.
Mich würd interessieren ob dies noch weiterverfolgt wurde.

Reinhard

Autor: Josef Öttl (josef-muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
Du muß dich zuerst im Forum anmelden. Als Gast funktioniert der direkte 
Kontakt nicht.

Josef

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@josef: Hab ich doch gleich gemacht...

@carnival: War eigentlich nur ein Handregler im Gespräch und ist hier 
nicht über das Stadium Schaltplan hinausgekommen. Eine DCC-Zentrale 
selbst bauen ist angesichts des Angebots von gebrauchten Lenz LZ100 und 
Roco-Lokmäusen (für kleinere Ansprüche) im Sinne von Einsparungen kaum 
sinnvoll.


Thomas

Autor: Thomas Riesen (gastrodus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lenz-Fans

Hat denn schon jemand eine lauffähige Hardware mit Software (am liebsten 
auf Bascom-Basis) am Laufen?

Oder hat ev. schon mal jamand von euch versucht einem LI100F über die 
serielle Schnittstelle Kommandos zu schicken? Eigentlich möchte ja auch 
ich nur ein paar Weichen vom AVR aus stellen, ob das nun direkt über 
RS485 oder über das LI100F geschieht, spielt mir keine Rolle.

Das LI100F möchte aber scheinbar eine saubere CTS/RTS Signalisation, 
welche mir Schweirigkeiten macht. Hat da schon jemand mit Bascom 
Erfahrung?

Schon mal vielen Dank und Grüsse aus der Schweiz
Thomas

Autor: Thomas P. (topla)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja und nein,

ich habe einen Nachbau der Lenz-Module LW120 und LW130 mit einer 
Erweiterung durch Aufsatzmodule für meine Modellbahn entwickelt. Gedacht 
sind diese Module für den Anschluß an das Lenz-Stellwerk LW100, um daran 
ein Gleisbildstellpult zu betreiben. Diese Module funktionieren 
einwandfrei am GZIO-Bus des LW100. Da das auch nur ein RS-485-Bus ist 
(allerdings nur mit 9600 bps), habe ich eine Bestückungsvariante 
vorgesehen, die den Anschluß an den XBus ermöglicht. Die Modulbestückung 
ist fast identisch, lediglich der Quarz ist 4,000 MHz statt 3,6864 MHz 
und die Brücken werden durch Filter ersetzt. Ein lebendes Exemplar 
dieser Variante gibt es noch nicht. Software existiert im Ansatz, 
allerdings hat mich ein Totalverlust meines USB-Sticks da etwas 
zurückgeworfen. Prozessor ist allerdings ein AT89C4051 und programmiert 
wird in Assembler statt BASCOM.

Viele Grüße
Thomas

Autor: Alexander Vogel (alex321)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Bin neu hier, interessant. Habe das gleiche Problem(mir selbst 
gestellt). also: wie weit ist die Lösung den nun Fortgeschritten, oder 
kann man die erwähnten Daten (von Lenz) noch haben? Alex

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. fertig
2. Ist die XBus-Doku von Lenz. Wenn Du deine email-Adresse hier 
hinterlässt,schicke ich Dir das mal zu.

Gruß
Thomas

Autor: Ilon Lapin (hoook)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, könntest du mir die Doku vielleicht auch zukommen lassen? Das 
wäre sehr nett, ich bin da auch gerade am experimentieren und habe noch 
ein paar Problemchen..........

Viele Grüße
Ilon

Autor: Heiko Herholz (heikoh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte auch die X-Bus Doku haben. Das wäre sehr nett.

Viele Grüße,

Heiko

Autor: Lars R. (larsr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Nach ein bisschen googeln fand ich das:

http://www.lenz.com/manuals/xpressnet/xpressnet.pdf

Gruß, Lars

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo!
ich habe eine frage:
hat jemand die hex Datei von Fahrregler4_20040409.sch.

gruß Thomas

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich weiß der Thread ist schon etwas älter und vielleicht macht hier 
niemand wer was, trotzdem probiere ich es, da das Thema sehr interessant 
ist.


Ich möchte auch über Schalter meine DCC Decoder ansprechen, so wie es 
hier beschrieben ist.
Ich verwende die Roco Mulitmaus mit Verstärker

@Josef: Du hast weiter oben geschrieben, dass du diese Kommunikation mit 
AVR schon erreicht hast.
Bist du gewillt den Code dafür preis zu geben?
Ich bin selbst kein so guter C-Programmierer um das alles von 0 weg zu 
programmieren.

Vielleicht gibt es ja noch jemanden der hier noch aktiv dabei ist.

mfg
Ralf

Autor: Robokalle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

hier mal ein Link mit C-source.

https://sites.google.com/site/dcctrains/rs-bus-feed

Ich selbst bin auf der suche nach den Code für Bascom.

Ziel:
Weichendecoder mit Belegtmelder (nicht die Weichstellung) für 
Modulanlage.
Man braucht manchmal nur 1-2 Weichen und/oder 1-4 Belegtmelder pro 
Modul.

Gruss Robokalle

Autor: AVR Amateur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Obwohl der Thread schon etwas Älter ist hoffe ich darauf
das hier vielleicht noch jemand mit liest.

Ich möchte auch mein Multimaus-System um ein eigenes Stellpult
und die anbindung an einen Rechner erweitern.

Ich Programmiere in Bascom und habe den Code fürs
Empfangen und Senden auf dem Xpressnet mittlerweile fertig.
Ich benutze einen Atmega162 da ich für die Rechneranbindung
die zweite Uart benötige.

Wie gesagt funktioniert die Kommunikation mit der Multimaus
und dem PC mittlerweile problemlos, bin momentan jedoch noch
auf der Suche nach einer geeigneten Tastenanbindung und
Auswertung.

Hat sich von euch vielleicht schon einmal jemand mit dem Thema
Tastenerweiterung mit vielen externen Tasten
beschäftigt damit ich einen Denkanstoss bekomme.

Gruß
Günter

Autor: Thomas Riesen (gastrodus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter

Wau, super, wenn du einen lauffähigen Code auf Bascom-Basis hingekriegt
hast. Da blieb ich leider, auch wegen Zeitmangel, in den Anfängen
stecken.

Ich beschäftige mich aber recht viel mit LCD's und Touchscreens diverser
Bauarten. Die lassen sich beide recht gut in Bascom bedienen. Hier mal
ein Beispiel
http://www.ebay.ch/itm/ws/eBayISAPI.dll?ViewItem&i...

Ich wäre an deinem Code sehr interessiert, vielleicht können wir ja da
beim User-Interface was sharen....

Viele Grüsse
Thomas

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR Amateur schrieb im Beitrag #2819250:
> Hat sich von euch vielleicht schon einmal jemand mit dem Thema
> Tastenerweiterung mit vielen externen Tasten
> beschäftigt damit ich einen Denkanstoss bekomme.

Beitrag "Re: RS 485 Lenz X-Bus"

Mit Aufsatzboard können 32 Taster ausgewertet werden, der 74HC165 ist 
dafür gut geeignet. Eine andere Lösung wird dort verfolgt:

http://usuaris.tinet.cat/fmco/download/XbusTCO_manual.pdf

Gruß
Thomas

Autor: AVR Amateur (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zu Topla

Leider sind mir 32 Tasten etwas zu wenig und bei der Lösung der Spanier 
(soweit ich das sehe) pollt der AVR die Taster.
Ich stelle mir eher eine Lösung auf Interrupt- Basis vor.
Momentan bin mit mehreren 74HC147 am Basteln. Ich habe mir auch schon 
mal gedanken über eine Anbindung der Tasten über mehrer Attiny2313 
gemacht, da ich von denen noch einige von der Entwicklung auf der DCC 
Seite herumliegen habe. Auf der DCC Seite habe ich mir auch eine 
modulare Lösung mit mehreren Tiny's2313 ausgedacht(Grundplatine 
DCC-Empfang dazu mehrere Aufsätze für verschiedene Aufgaben z.B. 
Servoaufsatz, Relaisaufsatz, reiner Schaltaufsatz im angehängten Bild 
als Beispiel mal zu sehen Links Servoaufsatz Mitte DCC-Decoder Rechts 
"stehend" Beide zusammengesteckt)so eine ähnliche Lösung nur zum 
anreiehen immer weiterer Tastenmodule hätte ich auch gerne für die
Tasten.

Zu Thomas Riesen
Ich habe kein Problem dir mal meinen Code weiterzugeben, möchte ihn nur 
nicht hier öffentlich einstellen. Zum einen ist der Code momentan 
komplett unkommentiert zum anderen verbreite ich ungern noch nicht 
fertige Anwendungen.
Ich könnte ihn dir mal mailen, Wie komme ich an deine Adresse?

Gruß Günter

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR Amateur schrieb im Beitrag #2820667:
> Zu Topla
>
> Leider sind mir 32 Tasten etwas zu wenig und bei der Lösung der Spanier
> (soweit ich das sehe) pollt der AVR die Taster.

Das war nur ein Beispiel anhand einer fertigen Lösung. Von diesen 
Modulen können auch mehrere eingesetzt werden. Es hindert Dich auch 
niemand daran, noch mehr 74HC165 zusammen zu schalten, wird halt das 
Schieberegister länger oder es gibt mehrere parallele Stränge.

> Ich stelle mir eher eine Lösung auf Interrupt- Basis vor.

Tasten und Interrupt sind keine sehr gute Idee, aber dazu gibt es hier 
dutzende Beiträge.

> Momentan bin mit mehreren 74HC147 am Basteln. Ich habe mir auch schon
> mal gedanken über eine Anbindung der Tasten über mehrer Attiny2313
> gemacht, da ich von denen noch einige von der Entwicklung auf der DCC
> Seite herumliegen habe.

Müssen die 2313 unbedingt verbraucht werden?
Da langweilt sich doch schon einer zu Tode, das bisschen Schieberegister 
einlesen und auswerten und bei Bedarf mal den XBus bedienen ist doch 
keine Herausforderung.

Thomas

Autor: AVR Amateur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Topla

Zuerstmal Danke für deine Antworten.

So wie ich das sehe läuft es mit den 165en auf einen SPI Bus raus.
Wie ist das mit den Leitungslängen?
Und mit Schieberegistern könnte ich ja auch gleich einen S88 Bus
implementieren welcher ja soweit ich das in verschiedenen Foren
gelesen habe auch immer mal wieder probleme verursachen soll.

Obwohl ein S88 Bus sowieso keine schlechte Idee wäre (Rückmeldung an den 
PC)
sollte ich vielleicht mal überdenken.
Bisher hatte ich mir nur eine einfache Lösung zum Schalten 
verschiendener
Antriebe (z.B. Servos,Magnetartikel,LED's)von externem Stellpult oder 
vom PC aus vorgestellt. Die geschalteten Artikel werden ja als 
Rückantwort wieder auf dem Xpressnet ausgegeben. Ich dachte mir dann 
ähnlich dem Weichenstellungs - Symbol der Multimaus die Schaltstellungen 
wieder auf dem PC auszugeben (Ich weiß keine echte Rückmeldung).


Gruß Günter

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR Amateur schrieb im Beitrag #2823287:

> So wie ich das sehe läuft es mit den 165en auf einen SPI Bus raus.
> Wie ist das mit den Leitungslängen?

Ja, ist SPI. Die Leitunglängen sollten keine Rolle spielen. Da Du ja ein 
Schaltpult (das wird ja nicht gerade mehrere Quadratmeter haben) bauen 
willst, sitzen die Schieberegister in der Nähe des Prozessors und die 
Leitungen von den Schaltern zu den Schieberegistern sind unkritisch. 
Entprellen macht man in Software.

> Und mit Schieberegistern könnte ich ja auch gleich einen S88 Bus
> implementieren welcher ja soweit ich das in verschiedenen Foren
> gelesen habe auch immer mal wieder probleme verursachen soll.

Und was hat das jetzt mit XBus-Eingabegeräten zu tun?? S88 kann Probleme 
machen, wenn die Module über die ganze Anlage verteilt sind und die 
SPI-Leitungen in der Nähe von stromführenden Leitungen liegen.

Thomas

Autor: AVR Amateur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Topla

Du hast natürlich recht mit "was hat das mit Xbus-Eingabegeräten zu tun"
Ich dachte nur auch S88 ist im Grunde genommen ein SPI Bus welchen ich
dann auch zur Tasteneingabe verwenden könnte.

Natürlich ist mein Stellpult nicht enorm groß ist eher klein es gibt
aber mehrere davon welche einen Abstand von 1-2 Meter haben.
Muß dann halt mehrere "Nur Eingabegeräte Basis Tiny2313" bauen, sollte 
kein
Problem sein da mir zur Platinenherstellung ein Fräsplotter zur
Verfügung steht und für meine kleine Anlage die RS485 beschränkung auf 
31 Geräte auch vollkommen ausreicht.
Ich danke dir jedenfalls für deine schnelle Hilfe hat mir jetzt sehr 
weiter geholfen, manchmal ist man halt zu sehr auf seinen ersten 
Gedankengang eingefahren, und beginne direkt mal mit der Erweiterung 
mittels 74HC165.

Gruß Günter

Autor: Thomas Riesen (gastrodus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Günter

Wie erwähnt, wäre ich an deinem Code sehr interessiert. Über die
"Bedingungen" könnten wir ja noch diskutieren. Bei der Ansteuerung
des X-Bus habe ich hauptsächlich noch Timing-Probleme, hier wäre ich
für deine Hilfe in Form des Codes sehr dankbar.

Ich selber verwende das TCO von Paco, dem Spanier. Hier kann man ja
auch verschiedene Adressen verwenden, so dass mehrere TCO's eingesetzt
werden können. Das TCO funktioniert wirklich sehr zuverlässig, auch
die Rückmeldung in den Traincontroller klappt super. Etwas mehr dazu
siehst du auf meiner Homepage www.riesens.ch

Freundliche Grüsse
Thomas

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich klink mich mal kurz dazwischen und frage:

Habt Ihr ne Protokollspezifikation?

hab mal gegoogelt, aber nix aufschlussreiches gefunden ...

evtl. ein Link?

Autor: spontan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Google doch mal nach:

dcc protocol

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er sucht nicht das DCC-Protokoll, sondern das vom XBus. Alles was man 
braucht, steht da drin:
http://www.digital-plus.de/pdf/XpressNet%20und%20U...
und da:
http://www.digital-plus.de/pdf/xpressnet_li101f.pdf

Thomas

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Riesen schrieb:
> Bei der Ansteuerung
> des X-Bus habe ich hauptsächlich noch Timing-Probleme,

Da gibt es so gut wie nichts Zeitkritisches. Du darfst nur nach dem 
Token nicht zu lange warten, sonst spricht die Zentrale die nächste 
Busadresse an. Lenz-Equipment legt eine kleine Pause von 10µs vor dem 
Senden ein, wenn Du zu schnell bist, wird die Zentrale "überfahren" und 
das Telegramm verstümmelt.

Thomas

Edit: Bei Entwicklungen für den XBus hat sich bei mir dieses Gerät 
bewährt:
http://www.opendcc.de/elektronik/dcc_sniffer/xp_sn...

Autor: Thomas Riesen (gastrodus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas (topla)

Vielen Dank! Ja nun, ich werde mich da wieder mal dahinter machen.
OpenDCC kenne ich gut, habe da die Zentrale und Weichendecoder
nachgebaut. Wo hast du den Sniffer denn her? Platine selbst geätzt?
Du hast da nicht ev. noch eine Platine übrig oder sogar ein Fertigteil?

Arbeitest du auch mit Bascom?

Grüsse aus der Schweiz
Thomas

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Riesen schrieb:
> Wo hast du den Sniffer denn her? Platine selbst geätzt?
> Du hast da nicht ev. noch eine Platine übrig oder sogar ein Fertigteil?

Ist schon länger her; ich habe die Schaltung und das Programm von 
Wolfgang Kufer genommen und modifiziert. Die USB-Anbindung läuft wimre 
über einen FT245 und das Zeug für die XBus-Seite ist mit auf der 
Platine, die in ein Pactec-CNL-Gehäuse passt. Ob da noch was über ist, 
weiß ich nicht (bin 500km von zu Hause weg).
edit: Die Platine ist industriell gefertigt, zweiseitig, 
durchkontaktiert mit Lötstopp.

> Arbeitest du auch mit Bascom?

Nein, bin in Assembler unterwegs. Gescheiterte Versuche mit C haben mich 
immer zum Assembler zurückgetrieben.

Thomas

Autor: AVR Amateur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen
Oben genannter Link zur Xpressnet Spezification ist für
Xpressnet V3.6 soweit ich weiß unterstützt die Multimaus aber nur
V3 deshalb arbeite ich mit dieser Spezification.

http://www.lenzusa.com/1newsite1/Manuals/xpressnet.pdf

Gruß Günter

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmmm ... hab mir das mal angeschaut ... ist ansich nicht so wild ... 
doof nur, die Übertragung 9n1 auf 62,5 kBaud. Ohne Gateaway geht da nix, 
aber das lässt sich recht human zusammenstricken.

Hab gerade sowas ähnliches gemacht für Infrarotkommunikation,
das Ardurinoboard ist ne Möglichkeit, geht aber auch problemlos n 
kleiner ATTiny2313.
Auf der PC-seite würde sich n FTDI-chip anbieten, würde da zum 
Breakoutboard von Sparkfun greifen, schön kompakt, recht günstig.
Dann einmal die Hardware-UART RX an den FTDI, TX an den RS485-Baustein,
dazu ne Software-UART, da RX an den rs485, TX an den USB ...
baudratenquarz an dem Ding und gut ist, kann man auf Punktraster 
zusammenlöten.
Vom Programm her einfach die Hardware-Uart über Ringpuffer laufen lassen 
und die Protokollverarbeitung und Software-UART in der Mainloop.

Interessantes Ding :)

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Sniffer kann deutlich mehr und braucht für die Steuerung durch den 
PC sowieso einen µC mit entweder 2 seriellen Schnittstellen oder eben, 
wie ich das gelöst habe, PC-seitig einen FT245 (parallel angebunden). 
Weiß nicht, ob ein 2313 das reisst.

Thomas

Autor: Günter S. (avr_amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas (gastrodus)

Habe mich soeben mal im Forum angemeldet las mir doch
mal eine Nachricht mit Mail adresse zukommen dann kann
ich dir den Code schicken.

Bin gerade mal dabei den Schaltplan zu Zeichnen und
den Code etwas zu kommentieren kann aus Zeitmangel
aber noch 1-2 Tage dauern.

Gruß
Günter

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich versuche auch in Bascom etwas zu bewegen.
Allerdings passiert nicht das was ich möchte ^^
Controller ist ein Mega644.

Ich lese mit dem UART-IRQ zuerst das 9. Bit aus und danach hole ich das 
Byte mit Inputbin ab.

Soweit so gut ...

Danach vergleich ich meine interne Adresse (0x40 + 1, also 0x41) und 
lasse mir die empfangene Adresse auf PortB ausgeben (STK500 LEDs).
Die Ausgabe erfolg nur wenn das gelesene Byte gleich der Adresse ist.

Aaaaber:

Die Adresse : 0100 0001 (0x41)
PortB LEDs  : 0100 0010 (0x42)


Waaaarum wenn's doch angeblich gleich ist?


@AVR Amateur:
Du schreibst oben dass Du lauffähigen Bascom Code hast.
Könntest Du mir da vielleicht ein paar Teile davon schicken?
Mir würde der Empfang des Callbytes und die Senderoutine (vereinfacht) 
reichen.
Wäre echt super von Dir :)


Danke schonmal!

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> Waaaarum wenn's doch angeblich gleich ist?

Weil Du einen Fehler in Zeile 42 Deines Codings hast.

Thomas

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt fängt das wieder an ...
Muss man wirklich Code anhängen damit auch jeder versteht dass
if Gelesen = &H41 then
  PortB = not Gelesen       'STK500 LEDs invertiert

etwas falsches anzeig obwohl es ja nicht sein kann?

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Dein tolles Programm niemals nie nicht die Ursache für die 
Fehlfunktion sein kann, dann melde den Fehler im Prozessor oder im 
BASCOM an den jeweiligen Hersteller.
Ich bin raus hier, such' Deine Fehler selber.

Thomas

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> Ich lese mit dem UART-IRQ zuerst das 9. Bit aus und danach hole ich das
> Byte mit Inputbin ab.

Inputbin? Wieso denn das? Du verdonnerst Deinen µC dazu Ewigkeiten in 
dem Interrupt zu hängen. wofür?

Nee, ohne Code kann man Dir nicht helfen, leider.

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas P. schrieb:
> Der Sniffer kann deutlich mehr und braucht für die Steuerung durch den
> PC sowieso einen µC mit entweder 2 seriellen Schnittstellen oder eben,
> wie ich das gelöst habe, PC-seitig einen FT245 (parallel angebunden).
> Weiß nicht, ob ein 2313 das reisst.
>
> Thomas

für 62,5 kBaud? Nee, PC-seitig wird auf 115,2 kBaud eingestellt und gut 
ist, doch, das sollte der 2313 locker schaffen.

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fhutdhb Ufzjjuz schrieb:
> für 62,5 kBaud? Nee, PC-seitig wird auf 115,2 kBaud eingestellt und gut
> ist, doch, das sollte der 2313 locker schaffen.

Mag sein, aber sicher bin ich mir da nicht. 115,2kbd reichen aus, das 
stimmt.
Auf dem Sniffer laufen ja auch zusätzlich noch Filterfunktionen, ein 
Zeitstempel wird hinzugesetzt und die Daten wahlweise auch in Klartext 
ausgegeben.

Thomas

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas P. schrieb:
> Fhutdhb Ufzjjuz schrieb:
>> für 62,5 kBaud? Nee, PC-seitig wird auf 115,2 kBaud eingestellt und gut
>> ist, doch, das sollte der 2313 locker schaffen.
>
> Auf dem Sniffer laufen ja auch zusätzlich noch Filterfunktionen, ein
> Zeitstempel wird hinzugesetzt und die Daten wahlweise auch in Klartext
> ausgegeben.

Das kann man dann am PC stricken mit nem kleinen VB-Progrämmchen ... ob 
man die Protokolldekodierung im Sniffer macht oder sich n kleines 
Terminalprogramm zusammenklickt macht vom Aufwand her wenig unterschied.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

es scheint nun alles zu funktionieren ...
Das Ganze ist natürlich erstmal ganz vereinfacht und vielleicht auch 
etwas seltsam aber es geht.
Ich erwische nun auch bei automatischen Senden das Callbyte und das 
dadurch gegebene Zeitfenster.

Mein LED Problem an PortB konnte ich nur durch einen Controllertausch 
beheben.

Habt ihr vielleicht Verbesserungsvorschläge für den Empfang oder kann 
man das so lassen?


LG Michael

$regfile = "m644def.dat"
$crystal = 8000000
$hwstack = 64
$swstack = 64
$framesize = 64


const Adresse = 1

'UART für RS485
$baud = 62500
Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 9 , Clockpol = 0
'Verbindung zum PC
Open "Comd.7: 19200 , 8 , n , 1" For Output As #2


'Automatisches Senden/Empfangen Umschaltung für RS485
Config Print0 = Portd.6 , Mode = Set
Config Portd.6 = Output


'LEDs
Config Portb = Output

'Taster
Config Pind.2 = Input
Config Pind.3 = Input
Portd.2 = 1
Portd.3 = 1


'IRQs
On Urxc Check
Enable Urxc
Enable Interrupts



Dim Neun As Bit
Dim Gelesen As Byte
Dim Adressbyte As Byte
Dim Bytes(3) As Byte



Adressbyte = &H40 + Adresse
Neun = 0


'LEDs aus
Portb = 255


Do

  'Weiche stellen
  If Pind.2 = 0 and gelesen = Adressbyte and Neun = 1 Then
    Waitus 10
    Printbin &H52 ; &H00 ; &H88 ; &HDA ;
  End If

  'Weiche stellen
  If Pind.3 = 0 and gelesen = Adressbyte and Neun = 1 Then
    Waitus 10
    Printbin &H52 ; &H00 ; &H89 ; &HDB ;
  End If

  'Weichenkommandos zum PC übertragen
  If Gelesen = &H52 Then
    Inputbin Bytes(1) 'restliche Bytes lesen
    Print #2 , Hex(gelesen) ; " " ; Hex(bytes(1)) ; " " ; Hex(bytes(2)) ; " " ; Hex(bytes(3))
    Gelesen = 0
  End If

Loop



Check:
  Neun = ucsr0b.rxb80
  Gelesen = UDR
Return



End

Autor: Thomas Riesen (gastrodus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael

Das sieht ja übersichtlich, fast einfach aus. Klappt das mit dem UART
auch mit andern AVR's? Wie hast du den MAX485 angeschlossen?

Dankende Grüsse
Thomas

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach dir einen Schaltplan wegen dem Max485. (bin noch am arbeiten)
Ob es auch bei anderen Avr's geht, nunja, zumindest beim 1284p geht's 
auch.
Etwas kleineres habe ich in Erwartung meines Grafikdisplays usw. 
garnicht erst versucht.

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch der Schaltplan für den Max485.
Die Leitung an PortD.6 kann natürlich an jeden anderen Pin gelegt 
werden.
Muss dann nur in der Config von Print0 geändert werden.

LG
Michael

Autor: Thomas Riesen (gastrodus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael

Vielen Dank! Ich bin nun am Herausfinden, der UART auch bei einem
ATmega8 oder ATmega328 geeignet ist.

Grüsse aus der Schweiz
Thomas

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Riesen schrieb:
> Vielen Dank! Ich bin nun am Herausfinden, der UART auch bei einem
> ATmega8 oder ATmega328 geeignet ist.

Warum nicht, alle 9-Bit-fähigen Uarts können eingesetzt werden. Ein 
AT89C4051 tut es auch seit langem.

Thomas

Autor: Günter S. (avr_amateur)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Aus Zeitgründen habe ich es leider versäumt mich mal wieder im
Forum umzusehen.

Ich bin gerade dabei die Elektronik für meine Stellpulte 
fertigzustellen.
Basis ist nun ein Atmega8 mit 2x "SPI In" 1x für die Tasteneingabe
1x für die Rückmeldung.
Des weiteren 1x "SPI Out" für die LED's (Weichenstellung,Belegtmeldung) 
im Stellpult.

Ein 16x2 Display zur Anzeige der Xpressnet-Codes ist auch schon 
eingebunden.
Momentan läuft es nur im Elektronik Simulator.

Was noch fehlt:
Momantan fehlt mir noch die Fehlerauswertung des Ringpuffers bei
evtuellem Überlauf. Die Xpressnet-Adresse muß auch noch manuell
vergeben werden mit der automatischen Vergabe von Xpressnet-Adressen
habe ich mich noch nicht befasst.
Und weil ich die Pins am AVR gerade noch frei habe möchte ich zu 
Testzwecken noch einen I²C Bus einfügen.
Da es nur ein Stellpult werden soll fehlt hier die Anbindung zum PC.
Auch bin ich noch nicht ganz schlüssig ob ich zur Umschaltung der
Weichen oder Signale nur eine Taste verwenden soll, da hierbei
auf eine echte Rückmeldung zum Vergleich wohin geschaltet werden
soll auf keinen Fall verzichtet werden kann.

Hallo Thomas(Riesen)
Schaltplan und Code geht dir sobald ich soweit bin per Mail zu.

Hallo Michael
Schick mir mal ne Mail dann bekommst du auch Post.

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
10nF alleine am 7805 sind zu wenig, da fehlt noch n fetter Elko,
Abblockkondensatoren sind Fehlanzeige (an µC und Max), n ISP mach ich 
auch auf jede
Leiterplatte, ist ätzend den µC für jede Änderung aushebeln zu müssen.
Was machen D2 und D3?

Autor: Günter S. (avr_amateur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Fhutdhb Ufzjjuz

Der Schaltplan ist nur ein Auszug aus dem Simulationsprogramm
und noch nicht für das Platinenlayout gedacht.

Als Spannungsversorgung verwende ich ein ausgedientes
PC - Netzteil, Glättung ist von daher normalerweise
nicht notwendig. Bei Verwendung eines Modellbahntrafos
muß natürlich noch ein Glättungselko rein.

Die Dioden sind Freilaufdioden, hab ich wohl mal so gesehen.
ISP Buchse wird in der entgültigen Version natürlich vorhanden sein.
Abblockkondensatoren werden natürlich auch eingefügt aber wie du
im Schaltplan erkennen kannst fehlen an den IC die Versorgungspins.

Hab ich glatt vergessen U7 (4N28) ist für eine DCC implementation
vorgesehen.

Gruß
Günter

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Günter S. schrieb:
> Glättung ist von daher normalerweise
> nicht notwendig

hinterm 7805? Doch, auf alle Fälle. Und ne Reversediode über den 7805er 
zudem.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.