Jump to content

Wumpus

Members
  • Gesamte Inhalte

    85
  • Benutzer seit

  • Letzter Besuch

Wumpus's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Wumpus

    RS485-Bus T-Adapter

    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.
  2. Danke, dann habe ich die falschen Kits erwischt.
  3. Wumpus

    Abstandsbolzen und Bricks

    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?
  4. Hat sich gerade aufgelöst: Ich habe prophylaktisch die Firmware erneut auf das Dual Relay Bricklet geflasht. Danach funktioniert es...
  5. 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?
  6. 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.
  7. Da es hier offenbar primär darum geht einen Gegenstand hin und her zu bewegen: TinkerMotion-Kit
  8. 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.
  9. War bei mir mit der allerersten offiziellen 2.0 Version auch nach dem Flash so (Auto-Reset lief ins Leere).
  10. 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?
  11. 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?
  12. 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...
  13. 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.
  14. 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.
  15. 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...
×
×
  • Neu erstellen...