Wumpus

Zum Aufbau eines RS485-Busses könnte man gut einen T-Adapter gebrauchen. Mir schwebt etwas in der Form einer kleinen Platine vor, mit zweimal "Wago 3-Wire Terminal Block" (https://www.tinkerforge.com/en/shop/accessories/connectors/wago-3-wire-terminal-block.html) zum Durchschleifen des Busses und einmal "3 Pole Grey Connector Header" (https://www.tinkerforge.com/en/shop/accessories/connectors/3-pole-grey-connector-header.html) zum Anschluss des Stacks/RS485-Extension. Am besten sollte das ganze so konstruiert sein, dass es geschickt in einen Kabelkanal eingebaut werden kann.

Danke, dann habe ich die falschen Kits erwischt.

Gerade mal wieder mit der neuen Lieferung ein paar Bricks zusammengesteckt und da fällt mir auf, dass die kleinen Abstandsbolzen nicht mehr passen (sind zu lang). Die Wifi 2.0 Extension und auch der Servo Brick lassen sich damit nicht mehr auf meine Master Bricks (Version 1.1 und 2.0) schrauben. Dieses betrifft die kurzen Bolzen, die auf beiden Seiten nur noch Innengewinde haben. Meine alten kurzen Bolten, die auf einer Seite noch einen Stift mit Gewinde haben, passen (habe aber leider keine mehr übrig). Es fehlt nicht viel (vielleicht ein halber Millimeter), aber gerade soviel, dass die Verbindung nicht mehr einklickt. Geht das noch irgendwem so? Liegt das an den Sommertemperaturen?

Hat sich gerade aufgelöst: Ich habe prophylaktisch die Firmware erneut auf das Dual Relay Bricklet geflasht. Danach funktioniert es...

Nachtrag: Mit den Shell-Bindings das gleiche Verhalten. Brickd: 2.2.2, aktuelle Firmware, Java Bindings 2.1.6 und 2.1.7, Shell Bindings 2.1.2 brickd.log Debug sieht wie folgt aus: 2016-01-19 10:31:26.985639 <D> <event|event_linux.c:161> EPoll returned 1 event source(s) as ready 2016-01-19 10:31:26.985669 <D> <event|event.c:392> Handling generic event source (handle: 22, received-events: 0x0001) 2016-01-19 10:31:26.985699 <D> <client.c:340> Creating client from plain-socket (handle: 23) 2016-01-19 10:31:26.985718 <D> <event|event.c:221> Added generic event source (handle: 23, events: 0x0001) at index 9 2016-01-19 10:31:26.985726 <I> <network.c:373> Added new client (N: 127.0.0.1:52871, T: plain-socket, H: 23, A: disabled) 2016-01-19 10:31:26.985731 <D> <event|event_linux.c:174> Handled all ready event sources 2016-01-19 10:31:26.985736 <D> <event|event_linux.c:142> Starting to epoll on 10 event source(s) 2016-01-19 10:31:26.986362 <D> <event|event_linux.c:161> EPoll returned 1 event source(s) as ready 2016-01-19 10:31:26.986380 <D> <event|event.c:392> Handling generic event source (handle: 23, received-events: 0x0001) 2016-01-19 10:31:26.986393 <D> <packet|client.c:282> Received request (U: XXX, L: 10, F: 6, S: 2, R: 0) from client (N: 127.0.0.1:52871, T: plain-socket, H: 23, A: disabled) 2016-01-19 10:31:26.986401 <D> <packet|hardware.c:124> Dispatching request (U: XXX, L: 10, F: 6, S: 2, R: 0) to 1 stack(s) 2016-01-19 10:31:26.986453 <D> <packet|usb_transfer.c:280> Submitted write transfer 0x12641d0 for 10 bytes to Master Brick [XXXXXX] 2016-01-19 10:31:26.986471 <D> <packet|stack.c:133> Sent request to Master Brick [XXXXXX] 2016-01-19 10:31:26.986489 <D> <event|event_linux.c:174> Handled all ready event sources 2016-01-19 10:31:26.986505 <D> <event|event_linux.c:142> Starting to epoll on 10 event source(s) 2016-01-19 10:31:26.986512 <D> <event|event_linux.c:161> EPoll returned 1 event source(s) as ready 2016-01-19 10:31:26.986516 <D> <event|event.c:392> Handling USB event source (handle: 21, received-events: 0x0004) 2016-01-19 10:31:26.986534 <D> <packet|usb_transfer.c:122> Write transfer 0x12641d0 returned successfully from Master Brick [XXXXXX] 2016-01-19 10:31:26.986541 <D> <event|event_linux.c:174> Handled all ready event sources 2016-01-19 10:31:26.986545 <D> <event|event_linux.c:142> Starting to epoll on 10 event source(s) 2016-01-19 10:31:26.987204 <D> <event|event_linux.c:161> EPoll returned 1 event source(s) as ready 2016-01-19 10:31:26.987229 <D> <event|event.c:392> Handling generic event source (handle: 23, received-events: 0x0001) 2016-01-19 10:31:26.987265 <I> <client.c:220> Client (N: 127.0.0.1:52871, T: plain-socket, H: 23, A: disabled) disconnected by peer 2016-01-19 10:31:26.987277 <D> <event|event_linux.c:174> Handled all ready event sources 2016-01-19 10:31:26.987290 <D> <network.c:415> Removing disconnected client (N: 127.0.0.1:52871, T: plain-socket, H: 23, A: disabled) 2016-01-19 10:31:26.987309 <D> <event|event.c:354> Marked generic event source (handle: 23, events: 0x0001) as removed at index 9 2016-01-19 10:31:26.987385 <D> <event|event.c:372> Removed generic event source (handle: 23, events: 0x0001) at index 9 2016-01-19 10:31:26.987391 <D> <event|event_linux.c:142> Starting to epoll on 9 event source(s) Könnt ihr bitte mal schauen?

Hallo zusammen, das Java Beispiel für den im Sekundentakt wechselnden Relay-Zustand funktioniert einwandfrei. Wenn ich jetzt das setState(true, true) gegen setSelectedState(1, true) (natürlich äquivalent für false) austausche, zeigt das Relay keinerlei Reaktion. Gleiches Problem bei Verwendung von OpenHAB, das ja auch auf den Java Bindings basiert und bei Zustandswechseln ebenfalls setSelectedState anspricht. Auch hier keinerlei Reaktion des Bricklets. Edit: Mit Wireshark sehe ich Nachrichten vom Typ '06' rausgehen, die Nachrichten haben die Länge 10.

Da es hier offenbar primär darum geht einen Gegenstand hin und her zu bewegen: TinkerMotion-Kit

Sieht prima aus! In Kobination mit dem LCD fänd ich den Joystick auch ganz elegant. Das hätte dann auch abseits der Wetterstation etwas von einem professionellen Bedienpult.

War bei mir mit der allerersten offiziellen 2.0 Version auch nach dem Flash so (Auto-Reset lief ins Leere).

Mir kommt allerdings gerade noch ein anderer wirrer Gedanke in den Sinn: Wäre es möglich, dass beim Flashen am Servo-Brick ein anderer Code ausgeführt wird und dieser irgendwelche Bits oder Worte verdreht hat, so dass für den Master ein ungültiges Symbol beim Lesen/Einbinden entsteht?

Habe gerade meine Master auf 2.0.1 geflasht und auch noch testweise beim Flashen/Verify für die Bricklets die Sleeps im Brickv etwas hochgedreht, aber das "böse" Dual-Relay Bricklet läuft leider immer noch nicht. Was kann ich noch tun/debuggen?

Zwischendurch mal etwas Positives: Mit der von borg beschriebenen Methode (Bricklet erst anstecken, wenn man im Reiter "Bricklet" beim Flashen ist) habe ich heute den Joystick neu flashen können. Danach wird er nun wieder einwandfrei erkannt. Mit dem Dual-Relay komme ich leider nicht weiter...

Flashen am Servo-Brick funktioniert. Ich habe jetzt mal am Servo die UID vom "bösen" Dual-Relay Bricklet verändert, den Brick stromlos gemacht, den brickv beendet und neu gestartet und dann den Servo Brick mit "bösem" Dual-Relay wieder angeschlossen. Bricklet wird erkannt und hat die neue UID. Nur am Master Brick wird das Bricklet immer noch nicht gefunden... Nachtrag: Am Master, an dem das "böse" Dual-Relay nicht erkannt wird, mit einem "guten" Dual-Relay Bricklet am selben Port/selbes Kabel die UID erfolgreich geändert und ausgelesen. @borg: Vorgehensweise durchprobiert, aber ohne Erfolg. Bricklet UID kann nicht gelesen/geschrieben werden. @Loetkolben: Bricks: Servo, Master HW 1.1 (FW 1.x), Master HW 1.1 (FW 2.0), Master HW 2.0 (FW 2.0) Noch interessant: Nach dem Hinweis von Loetkolben habe ich mir die beiden Dual-Relay Bricklets nochmals genauer angeschaut. Beim "guten" sind andere Relays drauf (größere Bauhöhe/Volumen). Platine ist jeweils Revision 1.1. Ausserdem beobachtet, dass beim Reset-Knopf drücken am Master, die beiden LEDs vom "guten" Dual-Relay kurz aufblitzen, wogegen beim "bösen" Bricklet nichts zu sehen ist, beim Anstecken des USB-Kabels aber schon.

Ja, habe ich natürlich probiert, aber Werte ungleich 1 führen wieder zur Fehlermeldung. Kabellängen habe ich verschiedene durchprobiert, und ich bin jetzt bei 15cm. An der Stromversorgung sollte es auch nicht liegen, denn ich habe auch bereits mit Step-Down zusätzlich probiert. Weiterhin habe ich jetzt auch noch probiert, das "böse" Dual-Relay Bricklet an einem Master 1.0 zurück auf Protokoll 1.0.x zu flashen, was aber leider genauso fehlgeschlagen ist, wie dort nochmals die UID zu schreiben.

Witzig: Lese ich die UID vom "bösen" Dual-Relay Bricklet aus, erhalte ich den Wert "1". Drücke ich dann auf "Save" und schreibe den Wert "1" zurück, erhalte ich die Meldung "Successfully wrote UID". Am Servo-Brick ist allerdings nach wie vor die richtige UID auslesbar...

@batti: Richtig wiedergegeben, wobei ich jetzt einfach mal den Fall "böser Joystick" aussen vor gelassen habe. Der verhält sich leicht anders von der Problematik. @borg: Ich habe gerade sowohl mit der brickv Version im Downloadbereich (source zip) probiert, als auch aus dem Git die neueste Version ausgecheckt. Beide verhalten sich so wie es vorher auch schon war. Fehlermeldung ist stets bei schreibenden Operationen (UID save/FW save) "Verification failed". UID lesen liefert immer "1" zurück."böses" Dual-Relay wird nur am Servobrick erkannt und funktioniert dort einwandfrei... PS: Unter drei verschiedenen Betriebssystemen getestet (Ubuntu x64, Gentoo x86, WindowsXP)

Habe ich gemacht, ich kann aber weder die UID auslesen, noch eine neue UID schreiben. Flashen bricht mit Verification failed ab. Jetzt wird es aber noch merkwürdiger; Das Dual-Relay Bricklet kann ich am Servo-Brick (solo) völlig sauber betreiben. UID lesen, erfolgreich flashen, Schalten, etc., nur an den Mastern geht es nicht mehr/immer noch nicht. Es liegt nicht am Port oder Kabel, weil ich ein weiteres anderes Dual-Relay Bricklet mit selbem Kabel am selben Port des Master Bricks einwandfrei betreiben kann. Ebenso funktioniert das "kaputte" Bricklet, wenn ich mit einem anderen Dual-Relay den Stack hochfahre und dann im laufenden Betrieb das Bricklet gegen das "kaputte" Dual-Relay austausche. Flashen und UID lesen/schreiben geht dann allerdings immer noch nicht... PS: Man kann nicht im Reiter Bricklet bleiben, da der Reiter ausgraut, wenn man das Brick vom USB abzieht.

Die beiden von mir beschriebenen Fälle sind vollständig separart zu sehen: - kaputtes Dual-Relay Bricklet - kaputtes Joystick Bricklet Die beiden stecke ich niemals zusammen an, weil sie einzeln schon Probleme bereiten. Erstmalig aufgetreten nach "erfolgreichem" Flashen auf 2.0.

Dual-Relay und Joystick machen Probleme: - Dual-Relay angesteckt: Master wird in brickv angezeigt, Dual-Relay nicht, UID vom DR lässt sich nicht auslesen Steckt man zum Booten ein anderes Dual-Relay an und tauscht es im Betrieb, dann funktioniert das Dual-Relay (im Sinne von: man kann schalten). - Joystick angesteckt: Stack wird nicht in brickv erkannt, nachträglich angesteckt kann man allerdings die UID auslesen; Habe leider kein zweites Joystick Bricklet für weitere Tests Beide lassen sich nicht mehr flashen ("Verification Error" zu Beginn der Verification-Phase). Ich habe mehrere Fotos gemacht und keine verbogenen Pins gefunden. Die aktuell verwendeten Kabel habe ich mit einer Reihe von anderen Bricklets getestet und für gut befunden.

Extra gerade mit der Digicam zur Sicherheit nochmal ein Macro-Foto vom Stecker gemacht, sieht alles sauber aus. Ich habe ja noch einige Kabel in Verdacht. Musste schon einige aussortieren (auch welche, die ich vorher noch nie in Gebrauch hatte). Jetzt habe ich allerdings ein Kabel in Verwenung, das mit einer ganzen Reihe von anderen Bricklets keine Probleme macht. Ja, Master sicherheitshalber erneut geflasht, sowohl mit Hardware Revision 1.0 als auch 2.0 probiert. Master taucht auch mit Dual-Relay im brickv auf, mit Joystick allerdings nicht. Neu flashen auf oben beschriebene Weise funktioniert nicht => Verification failed (bricht quasi schon zu Beginn der Verification ab). Zusätzlich auch noch mit manuell Auswahl einer Firmwaredatei probiert => kein Erfolg Nein => "Could not write UID: Verification failed"

Mir sind jetzt schon zwei Bicklets (ein Joystick und ein Dual Relay) nach dem Flashen auf 2.0 gestorben. Das Flashen selbst lief sauber durch, nach dem Reset allerdings werden im besten Fall die Bricklets nicht gefunden, oder aber der Stack hängt sich komplett weg und wird nach dem Reset/Anstecken an USB oder Hochfahren mit WIFI nicht mehr gefunden (keine Elemente im brickv/Linux sichtbar). Das Dual Relay funktioniert prinzipiell noch, wenn ich den Stack mit einem anderen Dual-Relay hochfahre und dann im laufenden Betrieb gegen das "kaputte" austausche (was man eigentlich ja nicht machen sollte). Die gleiche Methode angewandt, um die Bricklets nochmals zu flashen hat auch nicht geholfen. Hier zeigt sich allerdings noch ein kleiner Unterschied: - Beim Joystick Bricklet läuft Flash/Verify ohne Fehler durch, UID lässt sich mit Load auslesen - beim Dual-Relay läuft das Flashen durch, aber das Verify wirft den Fehler "Verification error", UID lässt sich nicht auslesen (liefert 1 zurück) Was kann ich noch tun?

Und wie?

Anstatt Steckverbindung könnte man auch eine Nut/Feder-Verbindungen machen. So ließen sich die Teile dann zusammen schieben. Wenn die Verbindung konisch zuläuft, also die Feder am langen Ende breiter wird, dann fällt die Verbindung auch nicht auseinander.

Vielen Dank für den Hinweis! Bei mir wurde bisher beim Einstecken des Masters kein entsprechendes Device angelegt. Ich habe jetzt den Master unter Windows geflasht, dann wieder Linux gestartet und diesmal bei angeschlossenem Brick erase/reset gedrückt und siehe da: /dev/ttyACM* wurde angelegt.

Das Flashen selbst ja, aber das Brick muss ja am USB erstmal erkannt werden. Für das TTY Device benötigt man den sam-ba Treiber...