[Python] linux -- Die Verbindung zwischen brickd und master funktioniert nicht mehr

[carsten040]

Ich verwende debian/GNU/linux und habe den Master mit einem Relais Bricklet und einen Temperatur Bricklet verbunden. Alle Komponenten sind softwaremäßig auf dem aktuellsten Stand. Alles wird mit python gesteuert bis irgendwann die Verbindung mit einem timeout abbricht. Ein erneutes starten meines Programms hilft nicht. Auch ein Neustart des brickd bewirkt nichts und die Liste im brickv bleibt leer.

In /var/log/syslog und /var/log/messages gibt es keine passende Meldung für den Zeitraum.

 

Nur wenn ich das USB Kabel abziehe und neu verbinde gibt es wieder eine Verbindung zwischen Master und brickd.

 

Grüße,

 

C

 

Ich habe eine ähnliches System auf einem zweiten Rechner laufen, bei dem gibt es das Problem auch ...

 

Noch jemand mit so einem Problem.

[photron]

Das Brick Daemon Log ist unter /var/log/brickd.log zu finden. Schau mal was da drin steht.

 

Dann kannst du noch per dmesg schauen was der Kernel über USB Geräte zu sagen hat. Wenn erst USB ab- und anstecken hilft, hängt es vielleicht mit USB zusammen.

 

Ist der Brick direkt per USB an den PC angeschlossen, oder ist da noch ein Hub dazwischen? Was für ein USB Kabel verwendest du?

 

Gibt es ein Muster wann der Brick verschwindet? Fällt es z.B. mit dem Schalten des Dual Relay Bricklets zusammen?

 

[carsten040]

Ich habe nicht in das log geschaut, da ich den im --debug mode hatte laufen lassen. Da gab es den folgenden output (sorry wenn es etwas mehr ist, habe mal mehr genommen, dass die Muster sichtbar werden ...)

 

2013-03-01 12:46:47.862940 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 7
2013-03-01 12:46:47.863022 <D> <transfer.c:72> Write transfer 0x20aa710 returned successfully from Master Brick [6krz2t]
2013-03-01 12:46:47.863074 <D> <event_posix.c:238> Handled all ready event sources
2013-03-01 12:46:47.863115 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-01 12:46:50.361688 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-01 12:46:50.361811 <D> <event_posix.c:223> Handling generic event source (handle: 16, received events: 1) at index 9
2013-03-01 12:46:50.361905 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 10, R: 0) from client (socket: 16, peer: 127.0.0.1)
2013-03-01 12:46:50.361984 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 10, R: 0) to 1 Brick(s)
2013-03-01 12:46:50.362102 <D> <transfer.c:232> Submitted write transfer 0x20aa710 for 10 bytes to Master Brick [6krz2t]
2013-03-01 12:46:50.362171 <D> <brick.c:503> Sent request to Master Brick [6krz2t]
2013-03-01 12:46:50.362229 <D> <event_posix.c:238> Handled all ready event sources
2013-03-01 12:46:50.362290 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-01 12:46:50.362424 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-01 12:46:50.362485 <D> <event_posix.c:223> Handling generic event source (handle: 16, received events: 1) at index 9
2013-03-01 12:46:50.362571 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 11, R: 0) from client (socket: 16, peer: 127.0.0.1)
2013-03-01 12:46:50.362644 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 11, R: 0) to 1 Brick(s)
2013-03-01 12:46:50.362743 <D> <transfer.c:232> Submitted write transfer 0x20aa788 for 10 bytes to Master Brick [6krz2t]
2013-03-01 12:46:50.362804 <D> <brick.c:503> Sent request to Master Brick [6krz2t]
2013-03-01 12:46:50.362861 <D> <event_posix.c:238> Handled all ready event sources
2013-03-01 12:46:50.362923 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-01 12:46:50.367796 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-01 12:46:50.367906 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 7
2013-03-01 12:46:50.368013 <D> <transfer.c:72> Write transfer 0x20aa710 returned successfully from Master Brick [6krz2t]
2013-03-01 12:46:50.368088 <D> <event_posix.c:238> Handled all ready event sources
2013-03-01 12:46:50.368153 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-01 12:46:50.368230 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-01 12:46:50.368293 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 7
2013-03-01 12:46:50.368388 <D> <transfer.c:72> Write transfer 0x20aa788 returned successfully from Master Brick [6krz2t]
2013-03-01 12:46:50.368452 <D> <event_posix.c:238> Handled all ready event sources
2013-03-01 12:46:50.368515 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-01 12:46:50.384751 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-01 12:46:50.384885 <D> <event_posix.c:223> Handling generic event source (handle: 16, received events: 1) at index 9
2013-03-01 12:46:50.384939 <I> <client.c:65> Client (socket: 16, peer: 127.0.0.1) disconnected by peer
2013-03-01 12:46:50.384986 <D> <event.c:164> Marked generic event source (handle: 16, events: 1) as removed at index 9
2013-03-01 12:46:50.385159 <D> <event_posix.c:238> Handled all ready event sources
2013-03-01 12:46:50.385206 <D> <event.c:189> Removed generic event source (handle: 16, events: 1) at index 9
2013-03-01 12:46:50.385248 <D> <event_posix.c:177> Starting to poll on 9 event source(s)

Nachdem er 'abgestürzt' war, habe ich brickd nochmals gestartet, so dass jemand vielleicht schon den Fehler sehen kann. Den Master hatte ich nicht abgezogen (übrigens verwende ich das USB-Kabel das mitgeliefert wurde)...

# brickd --debug
2013-03-01 15:32:38.135967 <I> <main_linux.c:385> Brick Daemon 2.0.3 started
2013-03-01 15:32:38.136228 <D> <event.c:55> Initializing event subsystem
2013-03-01 15:32:38.136364 <D> <event.c:138> Added generic event source (handle: 4, events: 1) at index 0
2013-03-01 15:32:38.136485 <D> <usb.c:190> Initializing USB subsystem
2013-03-01 15:32:38.137098 <D> <event.c:138> Added USB event source (handle: 6, events: 1) at index 1
2013-03-01 15:32:38.137253 <D> <event.c:138> Added USB event source (handle: 8, events: 1) at index 2
2013-03-01 15:32:38.137354 <D> <usb.c:202> libusb can handle timeouts on its own
2013-03-01 15:32:38.142728 <D> <usb.c:124> Found new USB device (bus: 2, device: 10)
2013-03-01 15:32:38.142891 <D> <brick.c:134> Creating Brick from USB device (bus: 2, device: 10)
2013-03-01 15:32:38.143307 <D> <event.c:138> Added USB event source (handle: 9, events: 1) at index 3
2013-03-01 15:32:38.143449 <D> <event.c:138> Added USB event source (handle: 11, events: 1) at index 4
2013-03-01 15:32:38.148448 <D> <usb.c:173> Got told to add libusb pollfd (handle: 12, events: 4)
2013-03-01 15:32:38.148603 <D> <event.c:138> Added USB event source (handle: 12, events: 4) at index 5
2013-03-01 15:32:38.475807 <D> <transfer.c:232> Submitted read transfer 0x10b9c60 for 80 bytes to Master Brick [6krz2t]
2013-03-01 15:32:38.475921 <D> <transfer.c:232> Submitted read transfer 0x10b9cd8 for 80 bytes to Master Brick [6krz2t]
2013-03-01 15:32:38.475987 <D> <transfer.c:232> Submitted read transfer 0x10b9d50 for 80 bytes to Master Brick [6krz2t]
2013-03-01 15:32:38.476051 <D> <transfer.c:232> Submitted read transfer 0x10b9dc8 for 80 bytes to Master Brick [6krz2t]
2013-03-01 15:32:38.476114 <D> <transfer.c:232> Submitted read transfer 0x10b9e40 for 80 bytes to Master Brick [6krz2t]
2013-03-01 15:32:38.476209 <I> <usb.c:149> Added USB device (bus: 2, device: 10) at index 0: Master Brick [6krz2t]
2013-03-01 15:32:38.476756 <D> <udev.c:90> Initializing udev subsystem
2013-03-01 15:32:38.477203 <D> <event.c:138> Added generic event source (handle: 13, events: 1) at index 6
2013-03-01 15:32:38.477261 <D> <network.c:103> Initializing network subsystem
2013-03-01 15:32:38.477547 <D> <network.c:165> Started listening to '0.0.0.0' on port 4223
2013-03-01 15:32:38.477633 <D> <event.c:138> Added generic event source (handle: 14, events: 1) at index 7
2013-03-01 15:32:38.477704 <D> <event.c:213> Starting the event loop
2013-03-01 15:32:38.477767 <D> <event_posix.c:177> Starting to poll on 8 event source(s)

 

Der Brick hängt direkt am Rechner (ist in beiden Fällen ein Netbook). Wie gesagt verwende ich das 'Orginalkabel'. Ich habe kein Muster entdecken können. In einem Fall ist das auch erst nach über 24h geschahen, dann wider nach 3h usw ...

 

Dmesg zeigt wie das syslog auch keine Auffälligkeiten. Auch den folgenden Eintrag konnte ich zeitlich nicht eindeutig zuordnen:

[370337.308139] usb 2-1: reset full-speed USB device number 11 using uhci_hcd

Das ist auf jeden Fall der Master. Allerdings kam die Meldung zumindest in einem Fall deutlich (zwei Stunden) bevor meine Kiste aufgehört hat zu arbeiten ...

[photron]

Log

 

Für ein Log auf Debug Level ist das noch kurz. In dem Log sehe ich zwei Aufrufe der gleichen Setter Funktion (könnte set_state des Dual Relay sein). Dann wird die Socket Verbindung der IP Connection geschlossen. Nichts auffälliges, alles normal.

 

Das zweite Log ist auch normal, nichts auffälliges. Brick Daemon startet seine Subsysteme, findet den Master Brick, initialisiert ihn und wartet dann darauf, dass etwas passiert.

 

Das zweite Log zeigt, dass der Master Brick zumindest USB mässig noch funktioniert, zumindest soweit das er für Linux heile aussieht.

 

Interessant wäre jetzt wie ein Setter Aufruf im Log aussähe, nachdem der Brick nicht mehr reagiert. Ein normaler Aufruf sähe so aus:

 

2013-03-01 12:46:50.362571 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 11, R: 0) from client (socket: 16, peer: 127.0.0.1)
2013-03-01 12:46:50.362644 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 11, R: 0) to 1 Brick(s)
2013-03-01 12:46:50.362743 <D> <transfer.c:232> Submitted write transfer 0x20aa788 for 10 bytes to Master Brick [6krz2t]
2013-03-01 12:46:50.362804 <D> <brick.c:503> Sent request to Master Brick [6krz2t]
2013-03-01 12:46:50.362861 <D> <event_posix.c:238> Handled all ready event sources
2013-03-01 12:46:50.362923 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-01 12:46:50.367796 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-01 12:46:50.367906 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 7
2013-03-01 12:46:50.368013 <D> <transfer.c:72> Write transfer 0x20aa710 returned successfully from Master Brick [6krz2t]

 

[*]Der Setter Aufruf geht bei brickd ein (Got request from client).

[*]Wird an den Master Brick geschickt (Submitted write transfer to Master Brick)

[*]Der Write Transfer kommt erfolgreich zurück (Write transfer returned successfully from Master Brick)

Mich würde interessieren ob im 'abgestürzten' Zustand der Write Transfer in diesem Fall auch ohne Fehler zurück kommt.

 

USB Kabel

 

Die Frage nach dem Kabel, weil wir schon mal Probleme mit USB Kabeln ohne Ferrite Bead (der "Klumpen" hinter dem Mini-USB Stecker) hatten.

 

dmesg

 

In dmesg sollte das so aussehen

 

[229718.296121] usb 6-3: new full speed USB device number 64 using ohci_hcd

 

Linux findet ein neues USB Gerät (new full speed USB device).

 

[229718.936149] usb 6-3: reset full speed USB device number 64 using ohci_hcd

 

Kurz darauf wird brickd darüber informiert und führt einen Reset durch um das Gerät in einen definierten Zustand zu bringen (reset full speed USB device).

 

[230529.492792] usb 6-3: USB disconnect, device number 64

 

Und hier wurde das USB Gerät wieder abgezogen.

 

Dual Relay Bricklet

 

Wie häufig schaltest du das und was hängt da als geschalteten Last dran?

 

Wie lang sind die Bricklet Kabel die du verwendest?

[carsten040]

Komme erst Montag wieder zu meinem Aufbau. Kann dann noch ein bisschen dauern bis das Programm wieder abstürzt.

 

Last(en)

 

An dem einen Master schalte ich 12V / 6A. Geschaltet wird maximal 1 mal in 15s.

 

Kabel

 

Das Kabel zwischen Bricklet und Master ist kurz. Das kürzeste im shop, aus der Erinnerung würde ich sagen so um die 10cm, ich verifiziere das noch am Montag ...

[carsten040]

Log

Ich habe mal ein log aufgezeichnet als das Programm abgestürzt war und sich nicht wieder starten ließ. brickd hatte ich neu gestartet:

#brickd --debug
2013-03-04 13:43:10.790828 <I> <main_linux.c:385> Brick Daemon 2.0.3 started
2013-03-04 13:43:10.791316 <D> <event.c:55> Initializing event subsystem
2013-03-04 13:43:10.791622 <D> <event.c:138> Added generic event source (handle: 4, events: 1) at index 0
2013-03-04 13:43:10.791820 <D> <usb.c:190> Initializing USB subsystem
2013-03-04 13:43:10.792831 <D> <event.c:138> Added USB event source (handle: 6, events: 1) at index 1
2013-03-04 13:43:10.793019 <D> <event.c:138> Added USB event source (handle: 8, events: 1) at index 2
2013-03-04 13:43:10.793215 <D> <usb.c:202> libusb can handle timeouts on its own
2013-03-04 13:43:10.799825 <D> <usb.c:124> Found new USB device (bus: 2, device: 11)
2013-03-04 13:43:10.799993 <D> <brick.c:134> Creating Brick from USB device (bus: 2, device: 11)
2013-03-04 13:43:10.800415 <D> <event.c:138> Added USB event source (handle: 9, events: 1) at index 3
2013-03-04 13:43:10.800546 <D> <event.c:138> Added USB event source (handle: 11, events: 1) at index 4
2013-03-04 13:43:10.804392 <D> <usb.c:173> Got told to add libusb pollfd (handle: 12, events: 4)
2013-03-04 13:43:10.804525 <D> <event.c:138> Added USB event source (handle: 12, events: 4) at index 5
2013-03-04 13:43:11.071471 <D> <transfer.c:232> Submitted read transfer 0x71bc60 for 80 bytes to Master Brick [6krz2t]
2013-03-04 13:43:11.072377 <D> <transfer.c:232> Submitted read transfer 0x71bcd8 for 80 bytes to Master Brick [6krz2t]
2013-03-04 13:43:11.073447 <D> <transfer.c:232> Submitted read transfer 0x71bd50 for 80 bytes to Master Brick [6krz2t]
2013-03-04 13:43:11.074477 <D> <transfer.c:232> Submitted read transfer 0x71bdc8 for 80 bytes to Master Brick [6krz2t]
2013-03-04 13:43:11.075491 <D> <transfer.c:232> Submitted read transfer 0x71be40 for 80 bytes to Master Brick [6krz2t]
2013-03-04 13:43:11.076554 <I> <usb.c:149> Added USB device (bus: 2, device: 11) at index 0: Master Brick [6krz2t]
2013-03-04 13:43:11.077903 <D> <udev.c:90> Initializing udev subsystem
2013-03-04 13:43:11.078596 <D> <event.c:138> Added generic event source (handle: 13, events: 1) at index 6
2013-03-04 13:43:11.078826 <D> <network.c:103> Initializing network subsystem
2013-03-04 13:43:11.079380 <D> <network.c:165> Started listening to '0.0.0.0' on port 4223
2013-03-04 13:43:11.079645 <D> <event.c:138> Added generic event source (handle: 14, events: 1) at index 7
2013-03-04 13:43:11.079812 <D> <event.c:213> Starting the event loop
2013-03-04 13:43:11.079982 <D> <event_posix.c:177> Starting to poll on 8 event source(s)
2013-03-04 13:43:15.883751 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-04 13:43:15.883835 <D> <event_posix.c:223> Handling generic event source (handle: 14, received events: 1) at index 7
2013-03-04 13:43:15.883923 <D> <client.c:152> Creating client from socket (handle: 15)
2013-03-04 13:43:15.884007 <D> <event.c:138> Added generic event source (handle: 15, events: 1) at index 8
2013-03-04 13:43:15.884052 <I> <network.c:94> Added new client (socket: 15, peer: 127.0.0.1)
2013-03-04 13:43:15.884092 <D> <event_posix.c:238> Handled all ready event sources
2013-03-04 13:43:15.884131 <D> <event_posix.c:177> Starting to poll on 9 event source(s)
2013-03-04 13:43:15.886342 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-04 13:43:15.886427 <D> <event_posix.c:223> Handling generic event source (handle: 15, received events: 1) at index 8
2013-03-04 13:43:15.886495 <D> <client.c:108> Got request (U: 42220, L: 8, F: 1, S: 1, R: 1) from client (socket: 15, peer: 127.0.0.1)
2013-03-04 13:43:15.886564 <D> <client.c:137> Added pending request (U: 42220, L: 8, F: 1, S: 1) for client (socket: 15, peer: 127.0.0.1)
2013-03-04 13:43:15.886601 <D> <usb.c:332> Dispatching request (U: 42220, L: 8, F: 1, S: 1, R: 1) to 1 Brick(s)
2013-03-04 13:43:15.886626 <D> <usb.c:350> Broadcasting request because no Brick knows the UID
2013-03-04 13:43:15.886683 <D> <transfer.c:232> Submitted write transfer 0x71c3f0 for 8 bytes to Master Brick [6krz2t]
2013-03-04 13:43:15.886712 <D> <brick.c:500> Forced to sent request to Master Brick [6krz2t]
2013-03-04 13:43:15.886746 <D> <event_posix.c:238> Handled all ready event sources
2013-03-04 13:43:15.886771 <D> <event_posix.c:177> Starting to poll on 9 event source(s)
2013-03-04 13:43:15.888419 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-04 13:43:15.888495 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-04 13:43:15.888577 <D> <transfer.c:72> Write transfer 0x71c3f0 returned successfully from Master Brick [6krz2t]
2013-03-04 13:43:15.888623 <D> <event_posix.c:238> Handled all ready event sources
2013-03-04 13:43:15.888661 <D> <event_posix.c:177> Starting to poll on 9 event source(s)
2013-03-04 13:43:18.387015 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-04 13:43:18.387135 <D> <event_posix.c:223> Handling generic event source (handle: 15, received events: 1) at index 8
2013-03-04 13:43:18.387225 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 2, R: 0) from client (socket: 15, peer: 127.0.0.1)
2013-03-04 13:43:18.387299 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 2, R: 0) to 1 Brick(s)
2013-03-04 13:43:18.387371 <D> <usb.c:350> Broadcasting request because no Brick knows the UID
2013-03-04 13:43:18.387477 <D> <transfer.c:232> Submitted write transfer 0x71c3f0 for 10 bytes to Master Brick [6krz2t]
2013-03-04 13:43:18.387605 <D> <brick.c:500> Forced to sent request to Master Brick [6krz2t]
2013-03-04 13:43:18.387670 <D> <event_posix.c:238> Handled all ready event sources
2013-03-04 13:43:18.387726 <D> <event_posix.c:177> Starting to poll on 9 event source(s)
2013-03-04 13:43:18.387803 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-04 13:43:18.387865 <D> <event_posix.c:223> Handling generic event source (handle: 15, received events: 1) at index 8
2013-03-04 13:43:18.387953 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 3, R: 0) from client (socket: 15, peer: 127.0.0.1)
2013-03-04 13:43:18.388025 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 3, R: 0) to 1 Brick(s)
2013-03-04 13:43:18.388092 <D> <usb.c:350> Broadcasting request because no Brick knows the UID
2013-03-04 13:43:18.388177 <D> <transfer.c:232> Submitted write transfer 0x71c468 for 10 bytes to Master Brick [6krz2t]
2013-03-04 13:43:18.388243 <D> <brick.c:500> Forced to sent request to Master Brick [6krz2t]
2013-03-04 13:43:18.388309 <D> <event_posix.c:238> Handled all ready event sources
2013-03-04 13:43:18.388371 <D> <event_posix.c:177> Starting to poll on 9 event source(s)
2013-03-04 13:43:18.391895 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-04 13:43:18.392010 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-04 13:43:18.392123 <D> <transfer.c:72> Write transfer 0x71c3f0 returned successfully from Master Brick [6krz2t]
2013-03-04 13:43:18.392192 <D> <event_posix.c:238> Handled all ready event sources
2013-03-04 13:43:18.392250 <D> <event_posix.c:177> Starting to poll on 9 event source(s)
2013-03-04 13:43:18.407288 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-04 13:43:18.407379 <D> <event_posix.c:223> Handling generic event source (handle: 15, received events: 1) at index 8
2013-03-04 13:43:18.407436 <I> <client.c:65> Client (socket: 15, peer: 127.0.0.1) disconnected by peer
2013-03-04 13:43:18.407491 <D> <event.c:164> Marked generic event source (handle: 15, events: 1) as removed at index 8
2013-03-04 13:43:18.407743 <D> <event_posix.c:238> Handled all ready event sources
2013-03-04 13:43:18.407798 <D> <event.c:189> Removed generic event source (handle: 15, events: 1) at index 8
2013-03-04 13:43:18.407838 <D> <event_posix.c:177> Starting to poll on 8 event source(s)

Wie zuvor auch ist mein (python) Programm nach dem Neustart nach ca. 1s mit einem Timeout abgestürzt. Das sollte im Log zu finden sein.

2013-03-04 13:43:18.387953 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 3, R: 0) from client (socket: 15, peer: 127.0.0.1)
2013-03-04 13:43:18.388025 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 3, R: 0) to 1 Brick(s)
2013-03-04 13:43:18.388092 <D> <usb.c:350> Broadcasting request because no Brick knows the UID
2013-03-04 13:43:18.388177 <D> <transfer.c:232> Submitted write transfer 0x71c468 for 10 bytes to Master Brick [6krz2t]
2013-03-04 13:43:18.388243 <D> <brick.c:500> Forced to sent request to Master Brick [6krz2t]
2013-03-04 13:43:18.392123 <D> <transfer.c:72> Write transfer 0x71c3f0 returned successfully from Master Brick [6krz2t]
2013-03-04 13:43:18.407379 <D> <event_posix.c:223> Handling generic event source (handle: 15, received events: 1) at index 8

Das ist ein Ausschnitt des Logs von oben und hat zumindest die etwas merkwürdige Stelle "Broadcasting request because no Brick knows the UID" und direkt da drauf ein Forced to sent request. Sieht irgendwie falsch aus ...

 

USB Kabel

Ist mit Ferrite Bead.

 

dmesg

Zeigt alle Meldungen so wie Du sie vermerkt hast. Keine weitere Meldung vor, während oder nach dem Absturz, es sei denn ich ziehe das Kabel ...

 

aktiver USB Hub

Ich bin am überlegen ob ich nicht einen akiven Hub mal dazwischen klemme um zu sehen, ob es vielleicht an der Spannungsversorgung liegt.

[photron]

Log

 

Also, das Log nach dem brickd Neustart zeigt, dass brickd den Master Brick korrekt findet und initialisiert.

 

4sec später nimmt er die eingehende TCP Verbindung an. Dein Programm ruft einen Getter eines Bricklets auf. Brickd sendet die Anfrage korrekt an den Master Brick weiter. Der Write Transfer kommt ohne Fehler zurück, was für brickd bedeutet, dass die Anfrage korrekt an den Master Brick ausgeliefert wurde.

 

2,5sec später ruft dein Programm einen Setter auf einem anderen Bricklet auf. Auch diese Anfrage geht korrekt an den Master Brick raus.

 

Es ist noch keine Antwort auf den ersten Getter Aufruf angekommen und da mittlerweile 2,5sec vergangen sind wird jetzt in deinem Programm eine TimeoutException geworfen. Ich nehme an du behandelst diese nicht und dein Programm wird abgebrochen. Daher wird jetzt die TCP Verbindung zum brickd getrennt. Damit endet das Log.

 

Bezüglich "Broadcasting request because no Brick knows the UID", das ist okay. Brickd arbeitet wie ein Switch und lernt hinter welchem USB Gerät sich welche UIDs verbergen. Der Eintrag besagt einfach, das brickd noch nicht weiss hinter welchem USB Gerät sich die UID für diese Anfrage befindet und daher wird die Anfrage an alle geschickt. Verständlicher wäre wahrscheinlich "Broadcasting request because UID is currently unknown" als Logeintrag.

 

Von brickd Seite ist das alles vollkommen okay, es ist kein Neustart von brickd notwendig. Was da passiert ist, dass auf den Getter Aufruf keine Antwort innerhalb des Timeouts kommt. Dies scheint kein vereinzelte Timeout zu sein, denn sonst müsste dein Programm weiter funktionieren, wenn du des nach dem Abbruch neustartest. Es scheint als hätte der Master Brick aufgehört zu antworten. Das ist nicht normal.

 

USB

 

Da dmesg nichts besonderes zeigt ist es zumindest kein USB Problem, dass der Kernel erkennen könnte. Auch im brickd Log funktioniert USB normal.

 

Der aktive USB Hub ist einen Versuch wert. Das Dual Relay Bricklet braucht zum Schalten kurzzeitig mehr Strom (60mA). Möglicherweise geben das die USB Buchsen der Netbooks nicht her.

 

Last

 

Was ist das für ein Gerät das du da schaltest bei 12V/6A? Ein Motor, eine Lampe, etc?

 

Ich frage, weil es im Zusammenhang mit dem Dual Relay in seltenen Fällen EMV Probleme gab. Das also der Master Brick durch das Schalten gestört wird.

 

Es kann auch sein, dass unabhängig davon etwas in der Umgebung des Bricks ist was diesen gestört hat. Deswegen auch die Frage nach der Länge der Bricklet Kabel. Lange Kabel wirken als Antennen und fangen Störungen ein.

 

Als weitere Möglichkeit, die du neben dem aktiven USB Hub noch testen kannst ist den Master Brick zu schirmen, z.B. in einer Metalbox, oder auch einfach mit der ESD Tüte in der er verpackt war.

[carsten040]

USB-Hub

Ich habe den USB-Hub jetzt seit über 24h laufen und ich hatte bis jetzt noch keinen Ausfall. Werde den Aufbau über das Wochenende laufen lassen um zu sehen, ob er nochmal ausfällt. Aber bis jetzt sieht es gut aus.

 

Last

Die Last ist ein Heizwiederstand (Heizfolie 2x36W @ 12V) die aber nur auf eine Gesamtleistung von 30W runtergeregelt sind.

[carsten040]

USB-Hub

Leider doch nicht! Man soll nie den Tag vor dem Abend loben. Es hat länger gedauert aber dann ist er doch ausgestiegen. Die gleichen Symptome.

Wie schon vermutet hilft es auch nicht das Kabel von Hub aus dem Rechner zu ziehen und wieder einzustecken, da der Brick ja über das Netzteil vom Hub versorgt wird. Jetzt suche ich mal einen Schirm für den Brick ...

[batti]

• Hast du einen Master 2.0 oder was für einen hast du?
  
• Wenn das Problem auftauch, leuchtet dann zufällig die rote LED am Master?
  
• Wenn der Getter einen Timeout bekommt, kannst du dann noch nen setter aufrufen? bewirkt dieser dann noch etwas? Du könntest dies über ein 2. kleines Programm machen wenn das andere "abgestürzt" ist oder über nen try catch Block um die getter
  

 

[carsten040]

Schirm

Jetzt hatte ich erst einmal den Schirm angebracht (esd Folie in der der Brick verpackt war). Das hat leider nichts gebracht, das Ding ist nach ca. 14h wieder abgestürzt.

 

Ich habe die 2.0-Version des Master Bricks.

Interessanterweise habe ich in einer Messtation fast den gleichen Aufbau stehen (statt eines Temperatur-Bricklets habe ich ein Analog-In Bricklet), wo noch der alte Master ('alt' = Version 1.irgendwas) läuft. Seit drei Monaten ununterbrochen ohne Probleme (allerdings nicht an einem Netbook).

 

Das mit der roten LED probiere ich gerade aus.

 

Es kann sein, dass der Fehler in meinem aktuellen Testprogramm aufgetaucht ist als ich gerade daneben saß. Bei dem Testprogramm lese ich die Temperatur nicht aus. Mein Programm und Brickd haben es aber nicht geschafft die Relais zu schalten. Brickd ha, sich aber die Kommandos gemerkt (die Fehlermeldung habe ich vergessen, irgendwas war noch nicht freigegeben oder so). Ich hatte gehofft, dass er dann wieder in denselben Fehler läuft, aber nach ungefähr einer Minute ging es plötzlich wieder. Keine Ahnung ob das was damit zu tun hat, ich wollte es aber trotzdem erwähnen ...

Ich werde auf jeden Fall mal testen, ob ich die Relais noch schalten kann, ohne die Temperatur auszulesen ...

 

[carsten040]

rote LED leuchtet nicht.

 

Ich habe dann den lese-Schritt raus genommen und er läuft nicht mehr in den Timeout. Das Programm läuft fröhlich weiter allerdings schaltet das Relais auch nicht.

Ein Meldung im Log fällt auf die ich hier mal abschreibe ...

<brick.c:429> Could not find a free write transfer for Master Brick [6krz2t], put request into write queue (count: 95)

 

[carsten040]

UND DANN ...

Ich hatte das Programm und den Brickd einfach weiter laufen lassen und jetzt hat der Brickd auf einmal alle Befehle abgearbeitet (die noch im Speicher waren, also 256 den Rest hatte er schon verworfen).

 

Ich habe mal den wohl entscheidenden Teil des Log raus kopiert. zum Zeitpunkt 2013-03-12 14:07:49.713920 bekommt er einen write transfer zurück. Das hatte vorher nicht geklappt ...

2013-03-12 14:07:43.214059 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 5, R: 0) from client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:43.214134 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 5, R: 0) to 1 Brick(s)
2013-03-12 14:07:43.214205 <D> <usb.c:350> Broadcasting request because no Brick knows the UID
2013-03-12 14:07:43.214263 <W> <brick.c:473> Dropping 1 items from write queue array of Master Brick [6krz2t]
2013-03-12 14:07:43.214347 <I> <brick.c:492> Could not find a free write transfer for Master Brick [6krz2t], put request into write queue (count: 256)
2013-03-12 14:07:43.214412 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:43.214470 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:46.217386 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:46.217496 <D> <event_posix.c:223> Handling generic event source (handle: 16, received events: 1) at index 8
2013-03-12 14:07:46.217583 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 6, R: 0) from client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:46.217658 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 6, R: 0) to 1 Brick(s)
2013-03-12 14:07:46.217725 <D> <usb.c:350> Broadcasting request because no Brick knows the UID
2013-03-12 14:07:46.217783 <W> <brick.c:473> Dropping 1 items from write queue array of Master Brick [6krz2t]
2013-03-12 14:07:46.217863 <I> <brick.c:492> Could not find a free write transfer for Master Brick [6krz2t], put request into write queue (count: 256)
2013-03-12 14:07:46.217928 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:46.217984 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:49.220893 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:49.221003 <D> <event_posix.c:223> Handling generic event source (handle: 16, received events: 1) at index 8
2013-03-12 14:07:49.221091 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 7, R: 0) from client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:49.221164 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 7, R: 0) to 1 Brick(s)
2013-03-12 14:07:49.221232 <D> <usb.c:350> Broadcasting request because no Brick knows the UID
2013-03-12 14:07:49.221289 <W> <brick.c:473> Dropping 1 items from write queue array of Master Brick [6krz2t]
2013-03-12 14:07:49.221370 <I> <brick.c:492> Could not find a free write transfer for Master Brick [6krz2t], put request into write queue (count: 256)
2013-03-12 14:07:49.221436 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:49.221496 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:49.713713 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:49.713805 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-12 14:07:49.713920 <D> <transfer.c:72> Write transfer 0x21d2150 returned successfully from Master Brick [6krz2t]
2013-03-12 14:07:49.714013 <D> <transfer.c:232> Submitted write transfer 0x21d2150 for 10 bytes to Master Brick [6krz2t]
2013-03-12 14:07:49.714095 <D> <brick.c:121> Sent queued request (U: 36700, L: 10, F: 1, S: 8, R: 0) to Master Brick [6krz2t], 255 packets left in queue
2013-03-12 14:07:49.714149 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:49.714191 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:49.714259 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:49.714303 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-12 14:07:49.714391 <D> <transfer.c:72> Read transfer 0x21d19c0 returned successfully from Master Brick [6krz2t]
2013-03-12 14:07:49.714439 <D> <brick.c:85> Got response (U: 42220, L: 10, F: 1, S: 3, E: 0) from Master Brick [6krz2t]
2013-03-12 14:07:49.714502 <D> <network.c:260> Dispatching response (U: 42220, L: 10, F: 1, S: 3, E: 0) to 2 client(s)
2013-03-12 14:07:49.714552 <W> <network.c:278> Broadcasting response because no client has a matching pending request
2013-03-12 14:07:49.714704 <D> <client.c:232> Forced to sent response to client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:49.714833 <D> <client.c:232> Forced to sent response to client (socket: 15, peer: 127.0.0.1)
2013-03-12 14:07:49.714941 <D> <transfer.c:232> Submitted read transfer 0x21d19c0 for 80 bytes to Master Brick [6krz2t]
2013-03-12 14:07:49.715086 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:49.715156 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:49.715243 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:49.715304 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-12 14:07:49.715400 <D> <transfer.c:72> Read transfer 0x21d1a38 returned successfully from Master Brick [6krz2t]
2013-03-12 14:07:49.715485 <D> <brick.c:77> Got callback (U: 3501786161, L: 34, F: 253) from Master Brick [6krz2t]
2013-03-12 14:07:49.715585 <D> <network.c:246> Broadcasting callback (U: 3501786161, L: 34, F: 253) to 2 client(s)
2013-03-12 14:07:49.715706 <D> <client.c:232> Forced to sent response to client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:49.715822 <D> <client.c:232> Forced to sent response to client (socket: 15, peer: 127.0.0.1)
2013-03-12 14:07:49.715935 <D> <transfer.c:232> Submitted read transfer 0x21d1a38 for 80 bytes to Master Brick [6krz2t]
2013-03-12 14:07:49.716019 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:49.716086 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:49.716172 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:49.716236 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-12 14:07:49.716343 <D> <transfer.c:72> Read transfer 0x21d1ab0 returned successfully from Master Brick [6krz2t]
2013-03-12 14:07:49.716414 <D> <brick.c:77> Got callback (U: 36700, L: 34, F: 253) from Master Brick [6krz2t]
2013-03-12 14:07:49.716489 <D> <network.c:246> Broadcasting callback (U: 36700, L: 34, F: 253) to 2 client(s)
2013-03-12 14:07:49.716641 <D> <client.c:232> Forced to sent response to client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:49.716787 <D> <client.c:232> Forced to sent response to client (socket: 15, peer: 127.0.0.1)
2013-03-12 14:07:49.716901 <D> <transfer.c:232> Submitted read transfer 0x21d1ab0 for 80 bytes to Master Brick [6krz2t]
2013-03-12 14:07:49.716981 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:49.717046 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:49.717134 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:49.717202 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-12 14:07:49.717311 <D> <transfer.c:72> Read transfer 0x21d1b28 returned successfully from Master Brick [6krz2t]
2013-03-12 14:07:49.717389 <D> <brick.c:77> Got callback (U: 42220, L: 34, F: 253) from Master Brick [6krz2t]
2013-03-12 14:07:49.717458 <D> <network.c:246> Broadcasting callback (U: 42220, L: 34, F: 253) to 2 client(s)
2013-03-12 14:07:49.717611 <D> <client.c:232> Forced to sent response to client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:49.717742 <D> <client.c:232> Forced to sent response to client (socket: 15, peer: 127.0.0.1)
2013-03-12 14:07:49.717856 <D> <transfer.c:232> Submitted read transfer 0x21d1b28 for 80 bytes to Master Brick [6krz2t]
2013-03-12 14:07:49.717937 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:49.718007 <D> <event_posix.c:177> Starting to poll on 10 event source(s)
2013-03-12 14:07:49.718093 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready
2013-03-12 14:07:49.718161 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 5
2013-03-12 14:07:49.718268 <D> <transfer.c:72> Write transfer 0x21d21c8 returned successfully from Master Brick [6krz2t]
2013-03-12 14:07:49.718375 <D> <transfer.c:232> Submitted write transfer 0x21d21c8 for 10 bytes to Master Brick [6krz2t]
2013-03-12 14:07:49.718466 <D> <brick.c:121> Sent queued request (U: 36700, L: 10, F: 1, S: 9, R: 0) to Master Brick [6krz2t], 254 packets left in queue
2013-03-12 14:07:49.718544 <D> <event_posix.c:238> Handled all ready event sources
2013-03-12 14:07:49.718613 <D> <event_posix.c:177> Starting to poll on 10 event source(s)

 

Ich hoffe das hilft irgendwie!

[photron]

Okay, das ist komisch.

 

Wenn brickd Requests in die Write Queue packt, dann sind alle 5 Write Transfers für den Brick unterwegs. Das ist an sich schon nicht normal. Dass dann aber nach über 12min (256 Requests in der Queue + N verworfene Requests bei einem Request alle 3 Sekunden) wieder ein Write Transfer zurück kommt und wieder abgeschickt werden kann ist komisch.

 

Wurde denn dann die Queue schnell geleert, oder ging nur der eine Transfer raus und der dann nicht direkt wieder zurück?

 

Was auch noch komisch ist, ist das hier eine Getter Response des Temperatur Bricklets anzukommen scheint, wobei in den 6sec Log davor kein Request dafür rausgeht.

 

2013-03-12 14:07:49.714391 <D> <transfer.c:72> Read transfer 0x21d19c0 returned successfully from Master Brick [6krz2t]
2013-03-12 14:07:49.714439 <D> <brick.c:85> Got response (U: 42220, L: 10, F: 1, S: 3, E: 0) from Master Brick [6krz2t]
2013-03-12 14:07:49.714502 <D> <network.c:260> Dispatching response (U: 42220, L: 10, F: 1, S: 3, E: 0) to 2 client(s)
2013-03-12 14:07:49.714552 <W> <network.c:278> Broadcasting response because no client has a matching pending request
2013-03-12 14:07:49.714704 <D> <client.c:232> Forced to sent response to client (socket: 16, peer: 127.0.0.1)
2013-03-12 14:07:49.714833 <D> <client.c:232> Forced to sent response to client (socket: 15, peer: 127.0.0.1)

 

Danach gehen Enumerate Callbacks vom ganzen Stack (1 Brick, 2 Bricklets) ein. Leider kann ich aus dem Log nicht ersehen ob das vom Brick oder durch dein Programm/brickv getriggert wurde.

 

Das ist alles sehr suspekt muss ich sagen. Es sieht fast so aus als ob der Brick sich da für über 12min einfach entschieden hätte nichts zu tun um dann wieder zu funktionieren

 

Weitere Fragen

 

Hast du mal getestet ob das Problem auch auftritt, wenn du die Heizdecke nicht am Relais hast?

 

Kannst du mir deinen Hardwareaufbau (inklusive Kabellängen) exakt beschreiben und dein Python Script zukommen lassen, damit ich das hier mal nachstellen kann?

 

Der andere funktionierende Aufbau unterscheidete sich darin, dass er einen Maste Brick Hardware Version 1.x verwendet, ein Analog In Bricklet statt eines Temperature Bricklets und dass er an nicht an einem Netbook, sondern was hängt? Ansonsten tut er aber das gleiche und regelt eine Heizdecke?

[carsten040]

Er hat 0,5 s gebraucht um die queue zu leeren. Der Master hat auch versucht das Relais in der Geschwindigkeit zu schalten, zumindest hat es sich so angehört.

 

Ich habe davor auch keinen request mehr für die Temperatur losgeschickt. Das war noch das 'alte' Programm also von ca. 15 Minuten vorher. Brickv hatte ich laufen, habe aber nichts dran gemacht.

 

Ich habe jetzt die Versorgung abgeklemmt und lass die Kiste über Nacht laufen. Morgen schicke ich die Beschreibung von dem Aufbau und dann sehe ich auch, ob es ohne Netzteil auch passiert ...

 

Der funktionierende Aufbau hängt an einem größeren Notebook und schaltet (gleiche Schaltung, gleiche Versorgung) die Heizfolien 'ein' und aus.

[carsten040]

Heizfolie abgeklemmt

Ich hatte am Montag die Heizfolie abgeklemmt und habe die Kiste weiter laufen lassen (mit Temperaturmessung). Das verwendete Programm habe ich hier rein kopiert ...

 

#!/usr/bin/env python
# -*- coding: utf-8 -*-  

import sys
import time

HOST = "localhost"
PORT = 4223
UIDtemp = "dxW"
UIDrelay = "bUL"

from tinkerforge.ip_connection import IPConnection, Error
from tinkerforge.bricklet_dual_relay import DualRelay
from tinkerforge.bricklet_temperature import Temperature

if __name__ == "__main__":
ipcon = IPConnection() # Create IP connection
        
t = Temperature(UIDtemp, ipcon) # Create device object
dr = DualRelay(UIDrelay, ipcon) # Create device object

ipcon.connect(HOST, PORT) # Connect to brickd
# Don't use device before ipcon is connected

        # on an off times in s
        PWM_TIME   = 15.0
        pwmONtime  = 15.0

        ## Turn relays alternating on/off for 10 times with 1 second delay
relState = 0
        while 1:
                time.sleep(3)
                if relState % 2:
		tmp = t.get_temperature()/100.0
		print time.strftime("%d.%m.%Y %H:%M:%S  ", time.gmtime()) + "Setting True   %.2f" % (tmp) 
		#print time.strftime("%d.%m.%Y %H:%M:%S  ", time.gmtime()) + "Setting True "
                    	dr.set_state(True, False)
	    
                else:
		tmp = t.get_temperature()/100.0
		print time.strftime("%d.%m.%Y %H:%M:%S  ", time.gmtime()) + "Setting False  %.2f" % (tmp)
		#print time.strftime("%d.%m.%Y %H:%M:%S  ", time.gmtime()) + "Setting False "
                    	dr.set_state(False, False)
	relState += 1

 

Interessanterweise ist das Programm gerade wieder abgestürzt. Ich habe an der Schaltung nichts geändert, sondern nur einen USB-Stick in den Rechner gesteckt. Dabei ist das Programm abgestürzt und lässt sich auch nicht mehr starten. LED am Master ist weiter Blau.

 

Schaltung

Die Schaltung (für den aktuellen Test habe ich einfach die Kabel aus dem Netzteil entfernt) war wie Folgt:

Ich verwende ein elektronisches Peaktech Netzteil (Model 1885) als Versorgung, das ich auf ca. 9V und 6A eingestellt haben (Die Spannung wirkt hier begrenzend). Das + Kabel geht von dem Netzteil zum Relais (ca. 1m) an den Anschluss der defaultmäßig offen ist. Ein ebenso langes Kabel geht den selben Weg wieder zurück um dort dann mit einem Kabel des Heizwiderstands verbunden zu werden. Das andere Kabel des Heizwiderstands ist mit dem - Pol des Netzteils verbunden. Die Kabel zum Heizwiderstand sind ca. 1m lang. Heizwiderstand sind zwei parallel geschaltete Heizfolien von Reichelt a 36W bei 12V.

[photron]

Relais

Es ist also ohne Heizfolie 3 Tage gelaufen. Daraus mag man jetzt ableiten, dass da ein Zusammenhang ist.

 

Bei 6A Strom hast du da sicherlich Funkenbildung im Relais, welche den Master Brick stören könnte. Außerdem ist das durchaus eine Belastung für die Kontakte des Relais, wenn du es bei dieser Last alle 3 Sekunden schaltest.

 

Gibt es einen speziellen Grund warum du die Heizfolie statt mit 12V nur mit 9V betreibst? Bei höherer Spannung könnte der Strom bei gleicher Leistung verringert werden.

 

Ähnlich steht es mit der Verschaltung der Heizdecken. Wenn du sie in Reihe statt parallel schalten würdest, könntest du die Spannung verdoppeln und den Strom halbieren.

 

Noch mal zu den 6A: Laut Datenblatt des PeakTech 1885 kann das nur maximal 5A. Wie kommst du da auf 6A?

 

USB

Interessant ist die USB-Stick Sache. Ist das reproduzierbar? Das deute auf ein Problem mit der USB Versorgung des Netbooks hin. Dazu würde auch passen dass das Relais im Peak etwas mehr Strom braucht wenn es belastet geschaltet wird. Dadurch funktioniert es 3 Tage ohne Heizfolie. Mit Last kommt es dann aber eher über das Limit des Netbooks.

 

Dagegen spricht, dass dein Test mit einem extern versorgten USB Hub nichts gebracht hat. War die Versorgung des Hubs vielleicht zu schwach?

 

Du sagtest, du hättest einen sehr ähnlichen Aufbau an einem anderen Rechner laufen. Besteht die Chance den problematischen Aufbau mit diesem Rechner zu testen, um herauszufinden ob das Netbook das Problem ist?

[carsten040]

USB

Das mit dem Stick war nicht reproduzierbar. Der Master hängt immernoch über den Aktiven Hub am Rechner. Das Netzteil vom Hub kann 2A und sonst ist nichts an dem Hub. Die 3s waren nur für den Test. Sonst wird maximal all 15s je nach Bedarf geschaltet (höchstens 2 x pro Minute).

 

9V sind zur Reduktion der Leistung. Ich habe Heizfolien dran, 2 Stück parallel. Das Relais ist auf 10A spezifiziert (oder so) und bin in erster Näherung nicht davon ausgegangen, dass ich das tatsächlich länger nutze. Sonst hätte ich nur die Wahl die Dinger in Reihe zu schalten.

 

Sorry, dann war es das PeakTech 1890. Ich habe beide Typen einer geht von 0-40V 5A, der andere 0-20V 10A. Habs verwechselt :-(

 

Der andere Aufbau wird in einer entferneten Messstation eingesetzt und da komme ich nicht so einfach dran. Ich werde mal einen anderen Rechner einsetzen (geht erst ab Dienstag) und die Schaltung (wie die in der Messstation) auf ein Brett schrauben.

 

Kann es dran liegen, dass da trockene Luft ist und die Teile liegen auf einfach auf dem Tisch? Elektrostatische Entladung?

 

[photron]

Es könnte an elektrostatischer Entladung liegen, ja.

 

So langsam gehen mir allerdings die Ideen aus. Ich versuche das ganze mal zusammenzufassen:

 

• Also, das Problem tritt nach einiger Zeit auf wenn du den Aufbau einfach vor sich hin laufen lässt. Das Problem ist, dass der Master Brick nicht mehr antwortet und erst ein Druck auf den Reset Knopf oder Trennen der Stromversorgung das Problem behebt.
   
  
• Es ist auch einmal vorgekommen, dass sich der Master Brick wieder von selbst bekrabbelt hat nach 15min ohne Reaktion.
   
  
• Ein aktiver USB Hub scheint nicht zu helfen, womit eine möglicherweise zu schwache USB Stromversorgung durch das Netbook als Ursache wahrscheinlich nicht in Betracht kommt. Dennoch solltest du wenn möglich mal mit einen anderen Rechner testen.
   
  
• Andererseits hat das bloße Einstecken eines USB Sticks am Netbook (oder war das am aktiven USB Hub?) das Problem zumindest einmal ausgelöst, ist aber nicht reproduzierbar. Da es wahrscheinlich nicht mit der USB Stromversorgung zusammenhängt, liegt es dann vielleicht an statischer Aufladung deinerseits die beim Einstecken zum Aufbau hin entladen wurde?
   
  
• Du betreibst erfolgreich einen ähnlichen Aufbau, der diese Problem nicht aufweißt. Da schaltest du auch über ein Relais eine Heizfolie? Oder tut der funktionierende Aufbau etwas anderes?
   
  
• Schirmung per ESD Tüte hatte keine Wirkung. Jemandem hier im Forum der große Pumpen schaltet hat eine metallene Keksdose als Schirmung geholfen. Vielleicht ist eine andere Schirmung noch mal einen Versuch wert.
  

[carsten040]

Wie gesagt werde ich den Aufbau heute mal modifizieren indem ich die Schaltung auf einem Brett montiere was die ganze Kiste (etwas) unempfindlicher gegen elektrostatische Entladung machen sollte (so ist es auch in der Messstation aufgebaut). Vorher schiebe ich Die Programme nochmal auf einen Desktop und versuche es mit dem ...

 

• Das Problem tritt nach einiger Zeit auf, wenn ich den Aufbau einfach vor sich hin laufen lasse. Das Problem ist, dass der Master Brick nicht mehr antwortet und erst ein Druck auf den Reset Knopf oder Trennen der Stromversorgung das Problem behebt.
  
• Ich habe zweimal (nach einem Absturz) ein Programm laufen lassen, das nur die Relais schaltet, aber keine Daten abfragt. Beide Male hat sich der Brick irgendwann (unterschiedliche Zeiten / Anzahl der Schaltvorgänge) bekrabbelt.
  
• Ein aktiver Hub behebt das Problem nicht.
  
• Andererseits hat das bloße Einstecken eines USB Sticks direkt am Netbook das Problem zumindest einmal ausgelöst, ist aber nicht reproduzierbar. Die Theorie der statischen Aufladung hatte ich insoweit getestet, als ich mehrfach auf dem Flur hin- und hergelaufen bin und jeweils den Stick auf unterschiedliche Weise (erst Netbook berühren, Kontakt des Sticks beim einstecken berühren, usw.) eingesteckt habe. Dabei ist das Programm nicht nochmals abgestürzt.
  
• der Andere Aufbau ist insoweit identisch, als er die gleiche Funktion mit den gleichen Komponenten (gleiche Heizfolie, gleiche Versorgung, fast das gleiche Programm) durchführt. Das Programm ist etwas anders, da sich von der 1.X-Version zur 2.0-er Version das Ansprechen der Master etwas geändert hat. Außerdem verwende ich in dem einen Aufbau einen Analog input statt eines Temperatur-Bricklets.
  

Ich komme auf die Keksdose zurück, wenn die Maßnahmen oben keine Wirkung zeigen ...

[photron]

Das Programm ist etwas anders, da sich von der 1.X-Version zur 2.0-er Version das Ansprechen der Master etwas geändert hat.

 

Okay, du meintest also wirklich die Software Version. Ich hatte das als Hardware Version verstanden. Dann kannst du auch noch versuchen, den Aufbau auf Software Version 1.x downzugraden, um zu sehen ob das einen Unterschied macht.

[carsten040]

Sowohl Software als auch Hardware sind bei dem Aufbau in der Meßsation auf (jeweils einem) 1.X Stand.

[carsten040]

Möglicherweise gelöst

 

Ich kann es noch nicht genau sagen, aber die Schaltung läuft jetzt seit zwei Tagen durch.

 

• Ich habe den Rechner getauscht und es mit und ohne Hub versucht. -> Keine Besserung
  
• Ich habe den Temperatursensor von der Oberfläche genommen und neben die geheizte Platte gelegt -> Keine Besserung
  
• Ich habe das (lange) Kabel des Temperatursensors aufgewickelt und den Temperatursensor neben die Schaltung gelegt -> Erfolg!
  

 

Es scheint also so zu sein, dass der Schaltimpuls irgendwie über das Sensorkabel zum Master (oder zum T-Sensor-Bricklet) geleitet wird und dort die Störung auslöst. Hier scheint es also Problematisch, dass das Kabel zum Relais kurz ist, die Leitung zu Sensor lang und das das Kabel vom Relais zum Netzgerät ein Stück weit mehr oder weniger parallel zur Leitung zwischen T-Sensor-Bricklet und Master verläuft.

 

Das würde auch erklären warum die Schaltung in der Meßstation unempfindlicher ist, da in dem Fall die Kabel anders liegen.