XMEGA und MODBUS Bug??

Hallo Mathias,

leider habe ich aktuell nicht viel Zeit um das ganze mit meiner XMEGA-Steuerung zu testen.

Der RS485 SerCtrlPin, bitte mal während der Kommunikation Messen, ob dieser umschaltet nachdem die Daten vom PC angekommen sind und er eigentlich antworten müsste.
Ohne diese Umschaltung kann der RS485 Baustein nicht antworten, hier kannst Du mit einen Analyser vor dem RS485 Baustein testen ob die Daten Grundsätzlich bis zum Baustein gehen würden.
Evtl liegt es ja wirklich nur an diesen PortPin SerCtrl.

Wenn dieser nicht umschaltet kann es eine der folgenden Gründe haben:
1. Fehler in der PortPin Einstellung (Doppelt oder Bug im XMEGA-Treiber)
2. Die Daten kommen nicht richtig an (Checksum) oder er hat eine andere Adresse, die RS485
wird zwar die Daten erhalten, aber in diesem Fall nicht antworten.
3. Baudraten/Ser-Daten Fehler, aber dann dürften die Daten nicht vom PC ankommen.

Wenn es immer noch der Alte Bug ist, wird der SerCtrlPin nicht umgeschaltet Mit dem Oszi siehst Du aber die Daten, die der XMEGA senden will

Aber ich gehe davon aus, das AVRA erst überprüft, ob die Adresse und die Checksum ok sind, bevor die Daten in den ModBuff gehen.

Evtl. wirklich mal als ASCII testen, wenn das läuft, kannst Du sicher sein, das Deine Hardware ok ist.

Wenn es die Port Pin Umschaltung ist, evtl. mal per Hand im Programm selbst ansteuern, SerCtrlPin auf einen freien Port legen und die Steuerung per Hand übernehmen (Programm)

1.Daten erhalten...
2.SerCtrlPin für Antwort umschalten...
3.Antworten...
4.SerCtrlPin für Empfangen umschalten...
5. Daten empfangen...
6. gehe zu 1

Arbeitest Du mit Tasks und Processen?

Gruß
Thorsten

Hallo

Habe genau das gleiche Problem mit Xmega128A4AU. Ich gebrauche den Usart im RS485 (Modbus RTU Master) Mode. Der Pin lässt sich nur durch negatief und positief (im define) umschalten. In realtime läuft nichts.

Hoffe da gibt es bald eine Lösung. Muss wohl im Augenblick alles selber umschalten und die Packetlänge vorher berechnen und dann mit timer arbeiten. Nicht so elegant.

Grüsse
Richard

Hallo Rolf,

hatte Avra nicht irgendwas mit dem Inter. vom 3,5Char Frame erzählt?



Thorsten

Hallo rolf,

das mit dem 3.5 CharTime ist für eine Funktion des RTU unbedingt nötig!

Damit wird im Modbus-Protokoll-Frame der Start und das Ende festgelegt und ist somit abhängig von der Baudrate.

Diese Wartezeit ist genau 3,5 Zeichen lang. Umso höher die Baudrate umso kürzer ist somit diese Zeit.

Der Aufbau ist in etwa so:

Start: Wartezeit 3,5 Chars
Adresse: 1 Byte
Funktion: 1 Byte
Daten: x.... Bytes
ChkSum: 2 Byte
Ende: Wartezeit 3,5 Chars

Solange die Daten innerhalb eines Telegramms gesendet werden, darf max. eine Zeit von 1,5 Chars in der Übertragung vergehen, sollte die Zeit überschritten werden, dann wird das Telegramm als ungültug erklärt.

Im Prinzip passiert folgendes beim RTU-Slave, er hört die ganze Zeit nur mit... sollte seine Adresse gesendet werden, antwortet er.
Aber nicht sofort, sondern er schaltet erst auf senden, wenn mind. 3,5Chars an Zeit vergangen sind und keine Daten mehr kommen.

Im Prinzip ist dieses 3,5Chars-Timing genau der Punkt wo der Empfang/Senden umgeschaltet werden muß und genau das scheint hier im Treiber nicht mehr zu laufen.

Wenn ich Avra richtig verstanden habe, hattest Du das beim AVR auch schon eingebaut: "...3.5 chars frame end detection implemented by Rolf for MEGA AVR..." Und das fehlt wohl jetzt in Funktion beim XMEGA.


Thorsten