PaulPaulaner

Danke für die schnelle Antwort !!! So einfach kann es sein - Danke funktioniert jetzt !

Hallo zusammen, ich versuche die Baudrate und die Parität für das RS232 Bricklet zu ändern. Leider bleibt diese unverändert auf RS232_BAUDRATE_115200 und RS232_PARITY_NONE wie ich das Bricklet mal in Betrieb genommen habe, kann das sein? wenn sich das Bricklet meldet wird es wie folgt initialisiert: rs232_v2_create(reinterpret_cast<RS232V2 *>(psTemp_Device->vDevice), psTemp_Device->sDevice_UID.toLocal8Bit().data(), &ipcon); rs232_set_configuration(reinterpret_cast<RS232V2 *>(psTemp_Device->vDevice), RS232_BAUDRATE_9600,//RS232_BAUDRATE_115200, RS232_PARITY_EVEN,//RS232_PARITY_NONE, RS232_STOPBITS_1, RS232_WORDLENGTH_8, RS232_HARDWARE_FLOWCONTROL_OFF, RS232_SOFTWARE_FLOWCONTROL_OFF); rs232_v2_register_callback(reinterpret_cast<RS232V2 *>(psTemp_Device->vDevice), RS232_V2_CALLBACK_READ, (void (*)(void))cb_readRS232_V2_static, psTemp_Device); rs232_v2_enable_read_callback(reinterpret_cast<RS232V2 *>(psTemp_Device->vDevice)); Gibt es einen Ablauf wie die Baudrate/Parität usw in Betrieb geändert werden kann? Da ich verschiedene Baudraten automatisiert durch probieren müsste um das Gerät zu erkennen. Danke und viele Grüße

habe ich vor der Installation gelöscht, es wurde keine neue Datei angelegt.

Mit beiden Programmen kein Absturz Auch kein Unterschied zwischen der HAT - Firmware lief mit beiden Programmen durch mit dem Brick-Viewer und Firmware 2.0.2 Absturz 2.0.3 kein Absturz bei der Installation der neuen Daemon-Versionen bekomm ich leider einen Fehler. sudo dpkg -i /home/pi/Ratio/brickd-2.4.2~log_armhf.deb (Lese Datenbank ... 149419 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../brickd-2.4.2~log_armhf.deb ... Removed /etc/systemd/system/multi-user.target.wants/brickd.service. Entpacken von brickd (2.4.2~log) über (2.4.2~log) ... brickd (2.4.2~log) wird eingerichtet ... Created symlink /etc/systemd/system/multi-user.target.wants/brickd.service → /lib/systemd/system/brickd.service. Job for brickd.service failed because the control process exited with error code. See "systemctl status brickd.service" and "journalctl -xe" for details. dpkg: Fehler beim Bearbeiten des Paketes brickd (--install): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück Trigger für man-db (2.7.6.1-2) werden verarbeitet ... Fehler traten auf beim Bearbeiten von: brickd journalctl -xe Jul 29 15:58:03 raspberrypi systemd[1]: apt-daily-upgrade.timer: Adding 26min 44 Jul 29 15:58:04 raspberrypi systemd[1]: Reloading. Jul 29 15:58:04 raspberrypi systemd[1]: apt-daily.timer: Adding 8h 33min 55.9280 Jul 29 15:58:04 raspberrypi systemd[1]: apt-daily-upgrade.timer: Adding 24min 41 Jul 29 15:58:04 raspberrypi systemd[1]: Starting Brick Daemon... -- Subject: Unit brickd.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit brickd.service has begun starting up. Jul 29 15:58:04 raspberrypi brickd[1122]: /usr/bin/brickd: /lib/arm-linux-gnueab Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Control process exited, Jul 29 15:58:04 raspberrypi systemd[1]: Failed to start Brick Daemon. -- Subject: Unit brickd.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit brickd.service has failed. -- -- The result is failed. Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Unit entered failed stat Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Failed with result 'exit Jul 29 15:58:05 raspberrypi sudo[1047]: pam_unix(sudo:session): session closed f lines 1796-1818/1818 (END) systemctl status brickd.service ● brickd.service - Brick Daemon Loaded: loaded (/lib/systemd/system/brickd.service; enabled; vendor preset: e Active: failed (Result: exit-code) since Wed 2020-07-29 15:58:04 CEST; 21s ag Process: 1122 ExecStart=/usr/bin/brickd --daemon (code=exited, status=1/FAILUR Jul 29 15:58:04 raspberrypi systemd[1]: Starting Brick Daemon... Jul 29 15:58:04 raspberrypi brickd[1122]: /usr/bin/brickd: /lib/arm-linux-gnueab Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Control process exited, Jul 29 15:58:04 raspberrypi systemd[1]: Failed to start Brick Daemon. Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Unit entered failed stat Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Failed with result 'exit ...skipping... ● brickd.service - Brick Daemon Loaded: loaded (/lib/systemd/system/brickd.service; enabled; vendor preset: e Active: failed (Result: exit-code) since Wed 2020-07-29 15:58:04 CEST; 21s ag Process: 1122 ExecStart=/usr/bin/brickd --daemon (code=exited, status=1/FAILUR Jul 29 15:58:04 raspberrypi systemd[1]: Starting Brick Daemon... Jul 29 15:58:04 raspberrypi brickd[1122]: /usr/bin/brickd: /lib/arm-linux-gnueab Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Control process exited, Jul 29 15:58:04 raspberrypi systemd[1]: Failed to start Brick Daemon. Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Unit entered failed stat Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Failed with result 'exit ● brickd.service - Brick Daemon Loaded: loaded (/lib/systemd/system/brickd.service; enabled; vendor preset: e Active: failed (Result: exit-code) since Wed 2020-07-29 15:58:04 CEST; 21s ag Process: 1122 ExecStart=/usr/bin/brickd --daemon (code=exited, status=1/FAILUR Jul 29 15:58:04 raspberrypi systemd[1]: Starting Brick Daemon... Jul 29 15:58:04 raspberrypi brickd[1122]: /usr/bin/brickd: /lib/arm-linux-gnueab Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Control process exited, Jul 29 15:58:04 raspberrypi systemd[1]: Failed to start Brick Daemon. Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Unit entered failed stat Jul 29 15:58:04 raspberrypi systemd[1]: brickd.service: Failed with result 'exit ~

Info zu den Aufbauten: Räumlichkeiten unterschiedlich 1x Pi ohne Display und Leitungen zu den Bricklets 15cm => Keller 1x wie bereits auf Foto gezeigt mit Display und Leitungen zu den Bricklets 50cm => OG mit der 2.0.3 & 2.0.2 für den HAT getestet Ausgabe ident. Relay tester - HAL Linux Found device Frp of type 2100 at port B Found device Nnn of type 284 at port C Found device NjK of type 284 at port E Found device Li7 of type 111 at port I Relay 1 error counters: 0 0 0 0 Relay 2 error counters: 0 0 0 0 Relay tester - HAL BCM2835 Found device Frp of type 2100 at port B Found device Nnn of type 284 at port C Found device NjK of type 284 at port E Found device Li7 of type 111 at port I Relay 1 error counters: 0 0 0 0 Relay 2 error counters: 0 0 0 0

Hat funktioniert, Danke hab jetzt erst noch mit der 2.02 getestet und dann auf die Version welche du mir gegeben hast. Test mit dem Brick Viewer mit der 2.02 - gleiches Verhalten 3 x geschaltet => Bricklets aus mit der 2.03 - 20 x geschaltet => funktioniert noch (mit meiner Applikation getestet auch OK) brickd.log

firmeware Update bekomm ich nicht hin. HAT wird von meinem Windows 10 Rechner nicht erkannt wenn ich diesen per USB anschließe ??

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

Nein, es wurde nichts umgesteckt.

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.

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':

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.

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);

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

An den Relais ist nichts angeschlossen

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.

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

Im Moment werden nur LEDs mit Vorwiderstand geschaltet.

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

Schade, aber Danke für die Info.

Hallo zusammen, ich habe einen Pi + das Raspberry Touchdisplay im Einsatz, bisher habe ich die 5V für das Display von der Stiftleiste des PI's für die Versorgung genutzt. Jetzt habe ich aber das HatBrick auf der Stiftleiste und komm somit nicht mehr an meine 5V. Da der HatBrick mit einem 24VNetzteil versorgt wird sind nur die 5V vom HatBrick vorhanden. Von wo/wie hole ich jetzt meine 5V fürs Display? Gibt es bereits was fertiges? Danke für eure Ideen/Lösungen. Viele Grüße Paul

Danke! Das mit dem Brick-Viewer war dann der Schlüssel zum Glück! Auf die einfachsten Sachen kommt man selbst immer nicht 🙂 Der hat die Geräte auch nicht gesehen, die hatten zwar alle geleuchtet, aber Verbindung war wohl nicht möglich erst nach erneutem Reboot des Raspberrys. Warum auch immer? @cl- : hab den Ablauf nach deinem Muster integriert, Danke für die Tipps von euch !! Grüße Paul

Hallo photron, Danke für die Antwort! Das Objekt CTF_Steuerung bleibt bestehen, wird also beim Progammstart angelegt und erst beim Beenden wieder aufgeräumt. Das hätte ich erwartet, das nach dem Aufruf von ipcon_enumerate der Callback dann asynchron irgendwann aufgerufen wird. Aber an meinen Haltepunkt kommt nichts an in der Callbackfunktion.

Hallo zusammen, Ich habe wie folgt meine Callback Funktion angelegt: im Header außerhalb der Klasse: void cb_enumerate_static(const char *uid, const char *connected_uid, char position, uint8_t hardware_version[3], uint8_t firmware_version[3], uint16_t device_identifier, uint8_t enumeration_type, void *user_data); CPP-Datei void cb_enumerate_static(const char *uid, const char *connected_uid, char position, uint8_t hardware_version[3], uint8_t firmware_version[3], uint16_t device_identifier, uint8_t enumeration_type, void *user_data) { CTF_Steuerung *psTemp = reinterpret_cast<CTF_Steuerung *>(user_data); psTemp->cb_enumerate(uid,connected_uid,position,hardware_version, firmware_version,device_identifier,enumeration_type); } So schaut die Registrierung und der Aufruf von ipcon_enumerate(...) CTF_Steuerung::CTF_Steuerung() { QString sPro; // Create IP connection ipcon_create(&ipcon); if(ipcon_connect(&ipcon, HOST, PORT) < 0) { sPro = "Error ipcon_connect(...)"; } ipcon_register_callback(&ipcon, IPCON_CALLBACK_ENUMERATE, (void (*)(void))cb_enumerate_static ,this); if(ipcon_enumerate(&ipcon) < 0) { sPro = "Error ipcon_enumerate(...)"; } } Nach meinem Verständnis sollte nach dem Aufruf von ipcon_enumerate(&ipcon) der Callback ausgelöst werden. Kommt aber leider nicht in die Callback-Funktion, die Registrierung des Callbacks usw. läuft alles ohne Fehler durch. Danke für eure Hilfe Viele Grüße Paul

Super Danke! Jetzt ist hab ich das verstanden 🙂 Viele Grüße Paul