Rätselhafte RS485 Modul Phänomene

[salvo]

Ich habe drei Master Bricks mit je einem RS485 Extension Modul verschaltet.

Die RS485 am USB Master ist als master geschaltet, die anderen beiden haben die Slave Adressen 2 und 3.

Mit dem Brickviewer kann ich nach dem Einschalten 2 Masterbricks sehen, der Dritte(Slave) bleibt verschwunden.

Wenn ich in der Adressliste des RS485 Masters immer nur einen Slave angeben findet sich auch immer genau dieser im brickViewer. Wenn ich  beide SlaveAdressen angebe, ist immer der Masterbrick zu sehen dessen Slave Adresse an erster Stelle in der Adressliste steht.

Daher würde ich ein HW oder Kommunikationsproblem ausschliessen.

Eher tippe ich auf einen Bug in der Firmrware oder im Protokoll. Irgendwie scheint die Erkennung der angeschlossenen Slaves nur vernünftig zu funktionieren wenn nicht mehr als ein Slave angeschlossen ist.

Ich wäre für eine Idee oder noch besser ein Abhilfe dankbar, denn so ist das Ganze noch nicht brauchbar.

 

 

 

[borg]

Welche Firmware Version haben die Master Bricks? Sind die Termination Schalter passend geschaltet?

[salvo]

Die Endgeräte sind jeweils terminiert, das "mittlere" nicht. SO wie es sein soll und ich habe die 60 Ohm über der RS485 Leitung gemessen.

Und wie gesagt: Das Gerät dass ich in der Adressliste des Masters angebe funktioniert auch. Gebe ich beide Slave Adressen ein, funktioniert das erste in der Liste, das zweite nicht.

 

ALle Master habe ich mit der neuesten Firmware vor ein paar Tagen geflashed. Mit der älteren Firmware geht die RS485 Extension ja eh nicht.

 

[Nic]

Hört sich für mich ev. nach der gleichen Baustelle wie für diesen Bug an:

http://www.tinkerunity.org/forum/index.php/topic,715.0.html

[borg]

@Nic: Das glaube ich nicht. Zum einen hab ich das mit RS485 getestet und zum anderen hat er ja die Slaves beide beim Master angegeben. Ist mir nicht ganz klar was da los ist.

 

@Salvo: Kannst du das ganze denn mit einem Teilnehmer einwandfrei nutzen oder gibt es da Timeouts o.ä.? Falls ja würde ich mal versuchen die Geschwindigkeit runterzustellen.

[borg]

So, hab das mal gerade nachgestellt (siehe Anhang).

 

Aufbau v.l.n.r.:

• Master mit RS485 Extension, versorgt über USB vom PC, konfiguriert als RS485 Master mit Slaves 2 und 3, Termination On (brickv1.jpg)
  
• Master mit RS485 Extension, versorgt über USB Power Supply, konfiguriert als RS485 Slave (Adresse 3) und Termination Off (brickv2.jpg)
  
• Master mit RS485 Extension, versorgt über USB Power Supply, konfiguriert als RS485 Slave (Adresse 2) und Termination On (brickv3.jpg)
  

 

Das funktioniert einwandfrei bei mir. Ist das jetzt so äquivalent zu deinem Aufbau? Wenn nicht, wie kann ichs nachstellen ?

 

Edit: Was mir da noch zu einfällt: Hast du auch die Slaves vor dem Master gestartet? Es gibt da kein "Hotplug".

[salvo]

Hallo Borg,

erst mal Danke dass Ihr Euch so schnell kümmert.

Ja die Konfiguration ist fast identisch wie von Dir beschrieben ausser dass ich die beiden Slaves per DC/DC versorge,  dass ich zwischen Master und 1 Slave ca. 50m Kabel (CAT5) verwende und der 2. Slave (Terminierung On) nochmal per 10 m langem (CAT5) Kabel (von 1. Slave aus gesehen) angeschlossen ist.

Ich habe mit verschiedenen Bitraten experimentiert aber das scheint keinen grossen Unterschied zu machen. Erst schien es als ob es mit 250KBs besser funktionierte, aber jetzt läuft die Kommunikation zwischen Master und 1. Slave wieder mit 1Mbbs und das geht auch. Problem ist der 2. Slave der nicht ansprechbar ist, wenn ich beide Slaves in der Adressliste des Masters angebe. Die Slaves schalte ich immer zuerst ein, dann den Master. (Das wäre noch ein gutes Feature wenn man im Master die Konfiguration noch mal anstossen koennte und nicht jedesmal ausschalten muss. Das mit dem Reset hätte auch den Effekt, aber dann crasht regelmäßig der Brick Daemon bei mir unter OpenSuse 12.1 und das ist dann auch keine gute Lösung). Hauptproblem für mich dass das Verhalten (geht, geht nicht) für mich a) nicht absolut reproduzierbar ist und allee Erklärungsansätze die ich bisher hatte mir nicht wirklich schlüssig erscheinen.

Peter

 

 

 

 

[borg]

Das mit dem Reset hätte auch den Effekt, aber dann crasht regelmäßig der Brick Daemon bei mir unter OpenSuse 12.1 und das ist dann auch keine gute Lösung).

Kannst du uns davon ein Log besorgen? In der config.py im brickd Order LOGGING_LEVEL auf logging.DEBUG setzen. Die Logfile liegt dann in /var/log/brickd

 

Hauptproblem für mich dass das Verhalten (geht, geht nicht) für mich a) nicht absolut reproduzierbar ist und allee Erklärungsansätze die ich bisher hatte mir nicht wirklich schlüssig erscheinen.

Peter

Also manchmal tauchen beide Slaves auf? Oder geht es nie? Wenn der zweite Slave manchmal auftaucht klingt es doch so als sei die Baudrate zu hoch eingestellt. Kannst du zum testen mal kürzere Kabel verwenden? Um zu gucken ob die Kabellänge hier bei dem Problem überhaupt relevant ist.

[salvo]

Hallo Borg,

ich habe einmal beide Slaves gesehen. Aber wie gesagt ich habe verschiedene Geschwindigkeiten probiert und das macht keinen reproduzierbaren Unterschied.

Das mit den kürzeren Kabeln werde ich demnächst mal ausprobieren, aber momentan bin ich etwas zu frustiert :-(

 

Der Brickd hört auf zu arbeiten wenn ich den USB Stecker abziehe. Wenn ich ihn neu starte funktioniert es wieder. Das Log habe ich angehängt. ich habe OpenSuse 12.1 im Einsatz und dne aktuellen brickd.

Vielleicht hilft es Euch ja..

brickd.log

[salvo]

Jetzt wird es dubios.

Nachdem ich die letzten Bindungs (1.18 glaube ich, vorher war es 1.17) gestern abend noch eingespielt habe geht es jetzt plötzlich. Nichts an der Hardware bzw. Verkablelung habe ich verändert. Ich werde die Sache jetzt mal längere Zeit laufen lassen und schauen ob es stabil bleibt.

Grübelnd,

Salvo

 

 

 

[borg]

Der Brickd hört auf zu arbeiten wenn ich den USB Stecker abziehe. Wenn ich ihn neu starte funktioniert es wieder. Das Log habe ich angehängt. ich habe OpenSuse 12.1 im Einsatz und dne aktuellen brickd.

Vielleicht hilft es Euch ja..

 

Das Log sieht soweit gut aus. Sagt er vielleicht beim starten von brickd das ihm gudev fehlt? Du brauchst python-gudev für die Hotplug Funktionalität.

[salvo]

Hm,

gudev habe ich installiert. Ich sehe auch keine Meldung. Wenn gudev fehlt, müßte der Daemon das doch auch im Log anzeigen...

-Salvo

 

[photron]

Wenn brickd gudev nicht importen kann dann steht "Could not import gudev. Disabling USB hotplug" im Log als Warning.

 

Du scheinst aber laut Log python-gudev zu haben, denn im Log steht ganz am Ende "Removed USB device". Dies wird ausgegeben wenn brickd von udev gesagt bekommt, dass ein USB Device entfernt wurde.

 

Sieht so aus, als würde udev also grundsätzlich funktionieren, aber es brickd nicht darüber informieren wenn ein USB Device dazugekommen ist. Fraglich ist jetzt warum das passiert. Ich würde die Ursache auf udevs Seite sehen.

[borg]

@salvo: Es gibt eine neue Firmware für den Master Brick, es gab in der Tat noch einen Bug bei niedrigen Baudraten! Ich gehe davon aus, dass die neu Firmware bei dir auch laufen wird : http://download.tinkerforge.com/firmwares/bricks/master/

[salvo]

Hm,

ich habe auf allem meinen drei Master bricks die neue Firmware geflashed.

Der erste Eindruck ist dass es eher noch instabiler geworden ist. Mit der vorherigen FW Version lief das Ganze meistens so ca. 20Stunden, bis die Kommunikation zusammenbrach und nur noch ein Reset geholfen hat.

Mit der neuen FW bringe ich nur nach mehrfachen Versuchen mit Powerdown/up einen Betrieb hin, der aber nicht lange anhält. Ich habe 500Kbs und 2000kbs probiert, das macht aber jetzt und auch mit der alten FW keinen reproduzierbaren Unterschied. Was mir auffallen ist dass das Led Geflacker an der Master Extension deutlich weniger geworden ist. Heisst das dass der RS485 Paketverkehr jetzt anders gestaltet ist ?.

 

Ich habe den Eindruck dass es in der Firmware Zustände gibt aus denen man nur mit einem Reset bzw. Powerdown wieder rauskommt. Kann man die Firmware nicht so gestalten dass z.B. durch Timeouts sichergestellt wird dass diese Hänger nicht passieren?

--Salvo

 

[borg]

Hmpf. Kann ich absolut nicht reproduzieren hier. Der eigentliche Pakettransfer ist nicht anders gestaltet, ich hab habe nur bei niedrigeren Frequenzen ein paar Timeouts erhöht. Wir haben schon einige RS485 Extensions verkauft und nur sehr wenig Problemschilderungen (eigentlich nur nur dieser Thread hier und der von wurststulle).

 

Daher gehe ich davon aus, dass es ein Problem ist, welches nur in einer bestimmten Konstellation auftritt. Welche Bricks/Bricklets hast du eigentlich an den Stacks?

 

Mir ist nicht klar was da stecken bleiben soll, ich werde mal einen Langzeittest mit sehr langem Kabel ausprobieren!

[salvo]

Ich habe insgesamt 10 Bricklets angeschlossen (3x Ambient Light, 4x Temperatur, 2 x IO4, 1 IR Distanzsensor), die alle 200 ms abgefragt werden.

Mir scheint mit der neuen FW auch die Enumeration viel länger zu dauern als mit der 1.22.

Auch im Brickviewer erscheinen die Masterbricks viel langsamer.

 

 

[salvo]

Ich habe wieder die 1.22 Firmware draufgemacht. Meiner Meinung nach hat die 1.23 ziemliche Macken und sie verhält sich auch ganz anders. Alleine an der Led ist das schon deutlich zu sehen. Alles funktioniert jetzt wieder wie vorher (wenn auch nicht wirklich zufriedenstellend, aber deutlich besser als die 1.23)

 

Schließlich hat die 1.23 auch 6KB (bei 74 K Programmlänge ist das schon recht viel) mehr als die V1.22, das ist m.E. mit ein paar Timeouteinstellungen nicht zu erklären.

-- Salvo

[borg]

Die längere Enumeration ist erwartet, an der Stelle hab ich die Timeouts hochgesetzt (d.h. ich warte bei niedriger RS485 Frequenz länger auf eine Antwort von den Slaves). Desweiteren wird am Anfang einmal mehr geblinkt. An der LED würde ich, wenn die gleiche Frequenz verwendet wird, keine Unterschiede erwarten.

 

Die größere Firmware kommt zustande weil in 1.2.3 schon ein Großteil der WIFI Extension Unterstützung mit drin ist .

 

Ich stelle am Wochenende mal genau deinen Aufbau nach (mit den Bricklets). Mal schauen ob es bei mir durchrennt.

[salvo]

Ok,danke,  dann ist die größere Programmlänge erklärt.

Mit Led Blinken meine ich nicht den Anfang sondern während des normalen Betriebes. Mit der V1.22 ist das Blinken schneller, eher so ein Flackern. bei der 1.23 ist es langsamer und es flackert weniger. Liegt villeicht an den größeren Timeouts...

Aber das wäre mir ja wurscht.

Die 1.23 kriege ich in der absolut gleichen HW konfiguration de facto nicht ans Laufen. Die Bricklets werden teilweise  erkannt (mal mehr, mal weniger) , aber auch nicht immer. Dann gibt es schnell immer häufiger Fehler bei der Abfrage, dann geht garnichts mehr. Dann muss alles resetted werden, dann beginnt das Spiel von vorne. bei der 1.22 läuft das Ganze meistens zwischen 10 und 30 Stunden durch ohne probleme, dann gibt es auch ab und an Hänger. Vielleicht liegt es ja daran dass bei mir wegen der größeren leitungslänge mehr Fehler auftreten die sich dann anders auswirken. Aber wie gesagt, es macht praktisch (in Sachen Hänger) keinen unterschied ob ich 500 oder 2000 Kbps Datenrate einstelle.

 

 

 

 

[AuronX]

Die größere Firmware kommt zustande weil in 1.2.3 schon ein Großteil der WIFI Extension Unterstützung mit drin ist .

 

drin heißt es gibt die entsprechenden Klassen und Strukturen, aber es wurde nichts am bisherigen Produktivcode geändert?

 

Oder sind schon einige Sachen aus der WiFi-Unterstützung in die Firmware "geleaked"? (Ich gehe davon aus, dass die WiFi-Unterstützung nicht nur ein Plugin ist das ihr reinsteckt und fertig, sondern, dass es auch im alt-Code zu Änderungen kommen wird; deswegen die Frage)

[borg]

Also ich denke das nichts vom WIFI Code ausgeführt wird, solange keine Extension mit Extension ID 3 auf einem Master sitzt: https://github.com/Tinkerforge/master-brick/commit/14047de5ff336550dbb607a43407bf20daab4bfa

 

Die größte Änderung ist das hier (in der bricklib): https://github.com/Tinkerforge/bricklib/commit/5a106ec891fee1713ab44ed9a8d36be463010de7

 

Ich hab für das Auslesen aus dem EEPROM und schreiben ins Flash von den Bricklet Plugins die Buffer Größe vergrößert und locks umgesetzt, damit das schneller geht. Zusätzlich hab ich beim Master das blinken am Anfang um 1 erhöht und die Timeouts bei RS485 dynamisch an die Baudrate angepasst. Mit diesen Änderungen konnte ich bei keiner Baudrate mehr Probleme erzeugen (vorher konnte ich Probleme bei niedrigen Baudraten reproduzieren).

 

Am Wochenende lasse ich mal ein RS485 Aufbau mit den ganzen Sensoren die salvo nutzt durchlaufen, mal schauen ob ich das dann reproduzieren kann.

[borg]

Hab jetzt hier einen großen Aufbau: 3x RS485, 12 Bricklets, 3 Master, 3 weitere Bricks. Ich hab es einmal geschafft einen der Stacks zum absturz zu bringen, er konnte dann erst wieder nach einem neustart gefunden werden! Mal schauen ob ich es hinkriege ein Programm zu schreiben welches den Absturz triggern kann.

 

Melde mich wieder wenn ich Neuigkeiten hab!

[salvo]

Hallo Borg,

prima, dass sich das Problem halbwegs reproduzierbaren läßt. Viel Erfolg bei der weiteren Suche !

--Salvo

[borg]

Gibt jetzt eine Master Brick Firmware Version 1.2.4. Ich hab jetzt mit dem Aufbau im Anhang getestet, 5 Bricks und 10 Bricklets.

 

Ich lasse den Aufbau mit JTAG Debugger und Logic Analyzer usw. erstmal hier für eine Woche oder so liegen, falls es noch irgendwelche Probleme gibt bitte einmal beschreiben wie ich meine Aufbau abändern muss um das Problem nachzustellen .

 

Getestet hab ich mit 9600 Baud, 19200 Baud, 1 MBaud und 2 MBaud.