Buskopplerprojekt Probleme!

[demmy]

Hi zusammen,

ich habe aktuell ein riesen Projekt am laufen. Und zwar bin ich gerade dabei einen Buskoppler zu entwickeln. Das heißt ich habe einen Atmega1284p mit 2 USART auf der einen Seite und einige Atmega8 auf der anderen Seite. Der Atmega1284P stellt den Buskoppler dar, welcher einmal über RS485 (als Master) mit beliebig vielen Atmega8 kommuniziert. Gleichzeitig stellt er die Daten dann gebündelt auf einer weiteren RS485-Schnittstelle bereit (als Slave), welche von einem PC abgeholt werden. Die an den Koppler angeschlossenen Karten sind verschiedenste Ein- und Ausgänge für unterschiedliche Steuerungsaufgaben. Die Karten können beliebig kombiniert werden und kommunizieren alle über ein festes Telegramm.

Das ganze Sieht dann so aus:


Jetzt zu meinem Problem:
Nach dem Einschalten der Spannungsversorgung, "Scannt" der Koppler alle Teilnehmer ab die an die 2. UART angeschlossen sind. Die Adresse bekommen die
Karten über den Steckplatz auf dem Rackbus. Alle gefundenen Teilnehmer werden dann Zyklisch (frei laufend) abgefragt.
Es ist nur so, wenn ich den RS485-RS232 wandler, den ich zur Telegrammdiagnose immer mitlaufen lasse nicht gesteckt habe, dann findet er meistens die Teilnehmer nicht, nach etlichen Versuchen nicht. Stecke ich den Wandler wieder auf, dann findet er die Karten sofort, ohne Probleme. Als Treiber Bausteine verwende ich die MAX485! Woran kann dieses verhalten liegen? Ist das irgendwie ein Hardwareproblem?

Und ein weiteres Problem:
Wenn der Rackbus läuft, also die Atmegas dauernd Daten untereinander austauschen, und ich schalte am PC die Software eine, welche zyklisch die gebündelten Daten vom Atmega1284p abholt, dann stoppt plötzlich der Rackbus. Ich kann mir das einfach nicht erklären. ich verwende für beide Schnittstellen jeweils die HardwareUART des Atmega und Sende die Daten im Hintergrund über den Puffer in Bascom. Die beiden Programmteile der beiden Busse laufen auch völlig getrennt voneinander (frei laufend). Hat jemand von euch schon mal zwei Schnittstellen gleichzeitig verwendet und so ein Problem gehabt? Ich habe irgendwie das Gefühl das ist ein Softwareproblem. Gibt es irgendwelche Speicherbereiche die sich beide UARTS teilen?

Ich hoffe ich konnte ein wenig euer Interesse wecken und Ihr habt Lust mir zu helfen mein Problem zu lösen. Ich bin echt am Verzweifeln, ich weiß nicht wonach ich noch suchen soll. Bei ernstgemeinten Hilfeangeboten stelle ich gerne Schaltpläne und Programme zur Verfügung.

[peterfido]

Um ein Hardwareproblem auszuschließem / zu erkennen benötigen wir den Hardwareaufbau. Inkl. was, wo wie geerdet ist und alle Masseverbindungen.
Für die Softwareanalyse das Programm. Der1284P kann nicht zwei Programmteile voneinander unabhängig abarbeiten. Wenn er mit einem beschäftigt ist, steht das andere.

Die Hilfeangebote sind immer ernst gemeint. Das Weglassen von Informationen (Aufbau / komplettes Programm) demotiviert viele Helfer.

[shedepe]

Dein erstes Problem hört sich nach falschen / fehlenden Abschlusswiderständen an.
Zum zweiten Problem kann ich mich nur meinem Vorposter anschließen.
Der Atmega kann nur eine Sache gleichzeitig machen. Wenn du Daten in 2 Schnittstellen reinschiebst / liest, dann arbeitet die UART Hardware komponente zwar asynchron zur CPU aber die CPU muss immer noch die Daten reinschieben.

[demmy]

Hi Leute,

vielen Dank zunächst mal für euer Interesse.

Also, das ist schon klar das die Daten noch in die UART geschrieben werden müssen und das das nacheinander erfolgt! Es ist so, das ich die Daten Asynchron im Puffer empfange, wenn die Daten da sind Diese auswerte und dann wieder neue Daten in den Ausgangspuffer schreibe. Beides mache ich aber unabhängig voneinander von den beiden UARTS.

Mit den Abschlusswiderständen war das so gedacht. Der eine sitzt fix auf der Platine des Atmega1284p und der andere wird am Ende auf den Rackbus aufgesteckt.

Anbei hab ich euch jetzt mal 2 Schaltpläne und die 2 Bascom Programme dazu hochgeladen. Das eine ist die des Kopplers und eine Digitale Eingangskarte dazu.

Die Restlichen Karten sind von der Buskommunikation immer gleich aufgebaut.
Wäre der Schaltplan des Racks noch interessant?

Viele Grüße

- - - Aktualisiert - - -

So hier noch der Schaltplan der Rack-Platine und die ganzen Platinenlayouts.

[peterfido]

Auf den ersten Blick fällt mir nur auf, dass Du die Interrupts schon zulässt, bevor die Konfiguration durch ist. Bei mir ist das so ziemlich der letzte Schritt kurz vor der Mainloop.

Edit:
100 ms finde ich arg kurz. Wenn auf dem PC kein Echtzeitlinux läuft, kann da schon ein Timeout kommen. Der PC könnte den BK so auslasten, dass der seiner Arbeit nicht mehr nachkommt. Wie ist da der Abfragezyklus und was für ein Programm werkelt da? Wieso holt der PC Daten ab und sagt nicht einfach nur "Ich bin da" und wenn es was zu verschicken gibt, dann schickt der BK das rüber bzw. der BK schickt einfach und wenn vom PC ein Ack kommt, dann weiß der BK dass die Daten agekommen sind.

[demmy]

Hi,

also der PC ist zum BK hin ja der Master und der stößt den Bus an, der PC fragt anhand einer Konfiguration beim BK an und der BK antwortet. Ist die Antwort da, fragt er Ihn direkt wieder an (wenn er der einzige Teilnehmer am Bus ist). Das funktioniert ca im 2ms Takt / pro Teilnehmer. Aber das läuft komischerweise ohne Probleme!!!

Ich habe das BK Programm so angelegt das beide Buskommunikationen in der Hauptschleife abgearbeitet werden ohne Interrupts. Deswegen lasse ich alle Daten erst mal in die Puffer laufen und werte dann die Puffer in der Laufzeit aus. So, hab ich mir gedacht, werden beide Bussegmente ohne Unterbrechung abgearbeitet und das Programm wartet nicht irgendwo. Somit wollte ich die schnellstmögliche Buszykluszeit rausholen. Dann sind die Prozessdaten immer aktuell.

Welche 100ms meinst du denn genau wenn ich Fragen darf?

Kann mein Kommunikationsporblem auf dem Rackbus evtl. was damit zu tun haben, das ich den RS485 nicht galvanisch getrennt habe?

- - - Aktualisiert - - -

Achso noch zu deiner Frage, das ganze soll in etwa so sein, das auf dem PC eine Art PLC läuft, und die BK sind die IO's für die PLC. Das bedeutet wiederum wenn in der PLC ein Ausgang gesetzt wird, dann muss er auch schnellstmöglich geschaltet werden, oder wenn sich der Status eines Eingangs wechselt, dann muss das auch schnellstmöglich in der PLC ankommen. Und dafür wollte ich einen ganz simplen Master-Slave Bus mit Ringabfrage aufbauen. Da kann ich leider nicht warten bis einer de Busteilnehmer meint etwas zu sagen zu haben, sondern die werden alle nacheinander nach ihrem Status gefragt!