PaulPaulaner Geschrieben July 21, 2020 at 15:20 Share Geschrieben July 21, 2020 at 15:20 Hallo zusammen, habe ein Phänomen in meinem Projekt. Ich habe eine Hat Brick auf einem Raspberry PI 3b+ an der Brick sind 3 x Industrial Dual Relais angeschlossen und einmal der Indust. Digital In 4 fach Es funktioniert alles wunderbar und dann wenn der Eingang zum x-ten Mal geschaltet wird, gehen alle Staus LEDs an den Bricklets aus bis neu gestartet wird also Spannung weg und wieder ran. Hat jemand vielleicht einen Tip? Netzteil 24V / 0.63A Output Danke schon mal vorab. Grüße Paul Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 22, 2020 at 09:54 Share Geschrieben July 22, 2020 at 09:54 Was schaltest du denn mit den Industrial Dual Relais? Hast du da induktive Lasten dran, aber z.B. keine Freilaufdiode, Varistor oder Snubber verbaut? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 22, 2020 at 11:45 Autor Share Geschrieben July 22, 2020 at 11:45 Im Moment werden nur LEDs mit Vorwiderstand geschaltet. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 22, 2020 at 12:58 Share Geschrieben July 22, 2020 at 12:58 Tritt das Problem auch auf, wenn an den Relaisausgängen nichts angeschlossen ist? Wie häufig tritt das Problem auf? Eher alle 10 oder eher alle 1000 Schaltvorgänge? Wie werden die LEDs mit Strom versorgt? Auch über das 24V Netzteil? Wenn ja, wie viel Leistung nehmen die LEDs auf? Bricht vielleicht durch das Schalten der LEDs die Spannung des Netzteils zusammen? Geht auch das Raspberry Pi mit aus? In welcher zeitlichen Folge und mit welcher Frequenz werden die Relais geschaltet? Werden die abwechselnd oder alle gleichzeitig geschaltet? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 22, 2020 at 14:57 Autor Share Geschrieben July 22, 2020 at 14:57 es wird alles über das selbe Netzteil gespeist. Raspberry bleibt an. Hab mir das mit dem Oszi mal angeschaut, da sind wenn man den Eingang schaltet Einbrüche/Überschwinger zu sehen. Mit den Relais etwas größer bis auf 21/27V. Werde ein 2tes Netzteil für die Beschaltung nutzen und nochmals testen. Danke und Grüße Paul Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 23, 2020 at 15:13 Share Geschrieben July 23, 2020 at 15:13 Woran machst du fest, dass das Raspberry Pi an bleibt? Das Raspberry Pi wird aber über den HAT Brick versorgt, oder versorgst du das Raspberry Pi unabhängig vom HAT? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 27, 2020 at 08:28 Autor Share Geschrieben July 27, 2020 at 08:28 Hallo Photron, Raspberry resetet auch, hab nur gesehen das die Powerled am PI leuchtet, die Tinkerforge Devices aber alle dunkel sind. Das hat mit dem Inputdevice glaub nichts zu tun. Bei einem anderen Aufbau nur mit den DualRelais ist mir aufgefallen das wenn mehrere Relais-Bricks gleichzeitig geschaltet werden, dass ganze abschmiert. Man sieht die Status LED für die Relais kurz noch aufblitzen bevor alles dunkel wird. Habe mal das Oszi an die CH 2 Versorgung (ca. 20V) und die CH 1 => 5V Ausgang Anschluß A auf der Hat Brick. Man sieht auf dem Bild, dass die Versorgungsspg. OK ist die 5V aber wegbrechen. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 27, 2020 at 08:43 Autor Share Geschrieben July 27, 2020 at 08:43 An den Relais ist nichts angeschlossen Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 27, 2020 at 09:41 Share Geschrieben July 27, 2020 at 09:41 Es wundert mich, dass du das 24V Netzteil mit 20V misst. Kannst du ein Foto vom Gesamtaufbau zeigen? Die 5V für die Bricklets und das Raspberry Pi können vom HAT Brick geschaltet werden. Die 3 großen Kondensatoren neben der micro USB Buchse auf dem HAT bilden die Ausgangskapazität des 5V Reglers. Könntest du dort auch mal die 5V messen (die Masseseite hat den schwarzen Balken) an einem der 3 Kondensatoren? Die Frage ist, ob der HAT Brick die 5V abschaltet (5V nur an den Bricklet Ports weg), oder ob der 5V Regler an sich einbricht (5V am Kondensator weg). Geht dann auch die Status LED des HAT Bricks selbst aus, oder bliebt die an? Benutzt du in deinem Programm Funktionen des HAT Bricks, z.B. um die Stromversorgung der Bricklets zu schalten oder den Sleep Mode zu nutzen? An welchem Port hast du welches Bricklet angeschlossen? Woran erkennst du dass das Raspberry Pi neustartet? Wie viele Schaltvorgänge braucht es bis das Problem auftritt? Wir haben, dass hier gerade versucht nachzustellen, es läuft aber ohne Probleme 10 Minuten durch wobei abwechselnd jede Sekunde alle 3 Industrial Dual Relay Bricklet umgeschaltet werden. Tritt das Problem beim Anziehen ober beim Abfallen der Relais auf? Sorry für die viele Fragen, das Problem ist mysteriös. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 27, 2020 at 10:29 Autor Share Geschrieben July 27, 2020 at 10:29 (bearbeitet) zu den 24V ist ein Aufbau mit Labornetzteil da hatte ich die Spg. nur auf 20V Es bricht nur die Spg. zu den Bricklets ein die 5V am Kondesator bleiben Hat Brick Status-LED bleibt an Funktionen bzgl. Sleepmodus usw. werden nicht genutzt Port A = hier wird die Spg für das PI-Display abgegriffen Port B = Ind 4-fach Digitale Eingänge Port C = Dual Relais Port E = Dual Relais PI startet doch nicht neu, habe mich vom Display irritieren lassen. meistens reichen 2 - 3 Schaltvorgänge Das Problem tritt beim Anziehen der Relais auf, da diese sonst ca. 2s angezogen wären Bild 1 Aufbau Bild 2 Status LEDs bei Absturz bearbeitet July 27, 2020 at 11:36 von PaulPaulaner Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 27, 2020 at 11:44 Share Geschrieben July 27, 2020 at 11:44 Interessant! Zwischen dem 5V Regler und dem 5V Ausgängen zu den Bricklets sitzt ein TPS22975 Leistungsschalter, über den der HAT Brick die Versorgung der Bricklets abschalten kann. Der TPS22975 Chip hat auch einen Überlastschutz. Entweder schaltet der HAT Brick die 5V Versorgung willentlich ab, was er nicht von sich aus tut, sondern nur beim Aufruf der entsprechenden API Funktion, oder der Überlastschutz des Chips greift ein. Tritt das Problem auch auf, wenn der Display nicht über den Bricklet Port versorgt wird? Bzw. was ist der minimalste Aufbau mit dem das Problem auftritt? Über Brick Viewer kann über die "Enable Bricklet Power" Checkbox auf dem HAT Brick Tab die Versorgung der Bricklets gesteuert werden. Hilft es im Fehlerfall, die Checkbox zu deaktivieren (falls sie aktive ist) und wieder zu aktivieren? Oder hilft ein Reset des HAT Bricks über den "Reset" Knopf auf dem HAT Brick Tab im Brick Viewer? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 27, 2020 at 12:01 Autor Share Geschrieben July 27, 2020 at 12:01 (bearbeitet) Hallo, tritt auch auf wenn das Display über ein extra Netzteil versorgt wird. Die Bricklets werden nach setzen des Enable Bricklet Power wieder mit Spg. versorgt. Rest des Hat Bricks geht auch. Jetzt sind nur noch die 3 Bricklets angeschlossen. Diese Funktion wird genutzt zum Schalten industrial_dual_relay_set_monoflop(reinterpret_cast<IndustrialDualRelay *>(psDevice->vDevice), ui8RelayChannel, true, ui32TO_ms); bearbeitet July 27, 2020 at 12:03 von PaulPaulaner Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 27, 2020 at 12:57 Share Geschrieben July 27, 2020 at 12:57 Das sieht so aus als ob dein Programm da unabsichtlicherweise hat_set_bricklet_power(hat, false) aufruft. Ein industrial_dual_relay_set_monoflop(...) Aufruf für Channel 0 wird bei passend korrumpierter UID als hat_set_bricklet_power(hat, false) verstanden, da beide Funktionen die Funktions-ID 3 haben und der Channel 0 Parameter als false interpretiert werden kann. Daher wäre es interessant zu sehen (z.B. per Wireshark auf localhost), ob dein Programm wirklich diesen korrumpierten Aufruf schickt. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 27, 2020 at 13:04 Share Geschrieben July 27, 2020 at 13:04 Zusätzlich könntest du das Programm in Valgrind laufen lassen. Valgrind dient u.a. dazu Speicherkorruption zu finden. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 27, 2020 at 14:10 Autor Share Geschrieben July 27, 2020 at 14:10 (bearbeitet) Hallo Photron, kann das Ganze auch mit dem Brick Viewer 2.4.12 reproduzieren. Ich schalte an beiden Bricklets immer nur Channel 0 als MonoFlop Zeit ist 1000ms eingestellt. Somit kann ich meine Applikation vermutlich ausschließen. bearbeitet July 27, 2020 at 14:14 von PaulPaulaner Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 27, 2020 at 14:35 Share Geschrieben July 27, 2020 at 14:35 Hast du da einfach eine UID Kollision? Schau mal bitte das alle Bricks und Bricklets unterschiedliche UIDs haben. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 28, 2020 at 06:14 Autor Share Geschrieben July 28, 2020 at 06:14 (bearbeitet) Kannst du das bei dir mit dem Brick-Viewer nicht nachvollziehen? Ich habe immer zwischen den 2 Relais-Reitern hin und her gewechselt und immer Relais Channel 0 geschaltet. Kann ich mir eigentlich nicht vorstellen da ich 2 Aufbauten habe mit jeweils eigener Hardware. Aber hier die UIDs aus dem Brick-Viewer': bearbeitet July 28, 2020 at 06:17 von PaulPaulaner Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben July 28, 2020 at 07:16 Share Geschrieben July 28, 2020 at 07:16 Moin, Ich habe hier mit dem Aufbau nochmal rumgetestet und konnte es jetzt reproduzieren. Bei mir reicht es, am Dual Relay an Port C Channel 0 zu schalten, dann werden sofort Timeouts hochgezählt. Passiert es bei dir auch, dass das Digital In an Port B schnell zu blinken anfängt, wenn du beim Relay an Port C Channel 1 schaltest? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 28, 2020 at 07:25 Autor Share Geschrieben July 28, 2020 at 07:25 (bearbeitet) Hallo, das mit dem schnellen blinken des Digital In kann ich nicht bestätigen. Aber ist ja prima, dass es sich bei euch reproduzieren lässt. bearbeitet July 28, 2020 at 07:27 von PaulPaulaner Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rtrbt Geschrieben July 28, 2020 at 07:36 Share Geschrieben July 28, 2020 at 07:36 Anschlussfrage: Hast du während das HAT Strom hatte die Bricklets an/ab/umgesteckt? Edit: Da war ich zu optimistisch am frühen Morgen, ich habe mir einfach ein Hot-Plug-Problem erzeugt, das ist aber nicht das selbe Problem, das du hast. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 28, 2020 at 07:49 Autor Share Geschrieben July 28, 2020 at 07:49 Nein, es wurde nichts umgesteckt. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 28, 2020 at 08:48 Share Geschrieben July 28, 2020 at 08:48 2 hours ago, PaulPaulaner said: Kann ich mir eigentlich nicht vorstellen da ich 2 Aufbauten habe mit jeweils eigener Hardware. Willst du damit sagen, dass du das Problem nicht nur an einem, sondern an zwei Aufbauten hast? Update auch mal bitte alle Tinkerforge Software. Also Brick Viewer auf 2.4.13, Brick Daemon auf dem Raspberry Pi auf 2.4.1 und C/C++ auf 2.1.19. Mir ist kein Bug bekannt in den alten Versionen der zum Problem passt, aber ich möchte vermeiden, dass wir hier alte bereits behobene Bugs suchen. Kannst du bitte das /var/log/brickd.log vom Raspberry Pi hier anhängen, vielleicht steht dort etwas interessantes drin. Welche Kernel Version hast du auf dem Raspberry Pi laufen (was gibt "uname -a" aus)? Was steht in /boot/cmdline.txt und /boot/config.txt auf dem Raspberry Pi? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
photron Geschrieben July 28, 2020 at 08:54 Share Geschrieben July 28, 2020 at 08:54 Teste auch mal bitte die angehängte Firmware 2.0.3 für den HAT Brick. Diese Version legt die set_bricklet_power Funktion tot, um zu verifizieren, dass es wirklich ein fälschlicher Aufruf dieser Funktion ist, der das Problem erzeugt. hat-brick-firmware-203.zbin Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 28, 2020 at 10:48 Autor Share Geschrieben July 28, 2020 at 10:48 Das Problem besteht an 2 Aufbauten, welche aber aus den selben Komponenten bestehen. Deamon auf PI ist schon die 2.4.1 uname -a Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux /boot/cmdline.txt dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=125111a8-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles logo.nologo consoleblank=0 loglevel=1 quiet /boot/config.txt # For more options and information see # http://rpf.io/configtxt # Some settings may impact device functionality. See link above for details # uncomment if you get no picture on HDMI for a default "safe" mode #hdmi_safe=1 # uncomment this if your display has a black border of unused pixels visible # and your display can output without overscan #disable_overscan=1 # uncomment the following to adjust overscan. Use positive numbers if console # goes off screen, and negative if there is too much border #overscan_left=16 #overscan_right=16 #overscan_top=16 #overscan_bottom=16 # uncomment to force a console size. By default it will be display's size minus # overscan. #framebuffer_width=1280 #framebuffer_height=720 # uncomment if hdmi display is not detected and composite is being output #hdmi_force_hotplug=1 # uncomment to force a specific HDMI mode (this will force VGA) #hdmi_group=1 #hdmi_mode=1 # uncomment to force a HDMI mode rather than DVI. This can make audio work in # DMT (computer monitor) modes #hdmi_drive=2 # uncomment to increase signal to HDMI, if you have interference, blanking, or # no display #config_hdmi_boost=4 # uncomment for composite PAL #sdtv_mode=2 #uncomment to overclock the arm. 700 MHz is the default. #arm_freq=800 # Uncomment some or all of these to enable the optional hardware interfaces dtparam=i2c_arm=on #dtparam=i2s=on # Uncomment this to enable the lirc-rpi module #dtoverlay=lirc-rpi # Additional overlays and parameters are documented /boot/overlays/README # Enable audio (loads snd_bcm2835) dtparam=audio=on gpu_mem=256 #Ratio Spezifisch disable_splash=1 disable_overscan=1 enable_uart=0 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
PaulPaulaner Geschrieben July 28, 2020 at 10:57 Autor Share Geschrieben July 28, 2020 at 10:57 firmeware Update bekomm ich nicht hin. HAT wird von meinem Windows 10 Rechner nicht erkannt wenn ich diesen per USB anschließe ?? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.