photron

Welche Version der PHP Bindings verwendest du? Die Zeilennummern passen nicht zur aktuellen Version 2.1.29. Teste mal bitte mit 2.1.29. Ich kann auf die Schnelle kein PHP 5.3 auftreiben. Ich habe das Problem versucht in einem Docker Container mit PHP 5.5.38 nachzustellen, aber es funktioniert hier. Dein eigentliches Problem ist, dass die WIFI Extension nicht unter 192.168.178.39 erreichbar zu sein scheint. Kannst du den Stapel unter 192.168.178.39 mit Brick Viewer erreichen? Den zweiten Fehler den du dann siehst kann ich nicht nachvollziehen. Es scheint keine Verbindung zu bestehen dennoch versuchen die Bindings eine Nachricht auf einen geschlossenen Socket zu senden. Eigentlich sollte Tinkerforge\Device->sendRequest in diesem Fall Tinkerforge\IPConnection->send gar nicht aufrufen.

Du hast die SD Karte vom alten in den neuen RED Brick getauscht? Dann sollte das weiter funktionieren. Hast du vielleicht den Stapel nicht ordentlich auf den neuen RED Brick gesteckt? Kannst du mal die Logs der Programme selbst zeigen. Der Ausschnitt des Brick Daemon Logs beinhaltet keine Probleme und nicht interessantes.

Okay, I see your problem now. You have to use SetMonoflop(true, 5000) OR SetState(false). But you're using both in sequence. This doesn't do the correct thing. You need to use a case structure in your while loop. In the true case it contains SetMonoflop(true, 5000) in the false case it contains SetState(false). I created a new LabVIEW example to demonstrate this: https://www.tinkerforge.com/en/doc/Software/Bricklets/SolidStateRelayV2_Bricklet_LabVIEW.html#monoflop

Your problem is that you use SetMonoflop now for turning the heater on AND off. You need to call SetMonoflop(true, 5000) repeatedly to turn the header on and keep it on You need to call SetState(false) once to turn the heater off.

I assume you use SetMonoflop(false, 5000) to turn off the heater. This will turn of the heater for 5 seconds then turn it back on again. This is bad. You need to use SetState(false) to turn off the heater and keep it off.

Da kommt gerade etwas Bewegung in die Sache: https://github.com/Tinkerforge/generators/pull/58

I assume you're using a control to represent the UID, just the same as our examples do. A control will not keep changes that you make to its value by default. You have to tell the control to use the current value as its default value. To do this change the control to the UID you want, then open the context menu of that control and select "Data Operations" followed by "Make Current Value Default". Now save the file. The next time you open it the control will contain the changed UID. You can also replace the control with a constant to archive the same result. The difference is that the constant will not show up on the front panel.

I assume you use the SetState function of the Solid State Relay Bricklet 2.0. I assume you call SetState(true) once to turn the heater on and SetState(false) once to turn it off. To avoid that the heater stays on if your LabVIEW program stops working you can use the SetMonoflop function instead. If you call SetMonoflop(true, 5000) then the Solid State Relay Bricklet 2.0 will switch on for 5000 milliseconds and then switch itself off again. So instead of calling SetState(true) once to turn the heater on you call SetMonoflop(true, 5000) every second instead. This results in constantly extending the time the relay stays on, essentially keeping it on constantly as long as you keep calling SetMonoflop(true, 5000) again before the 5000 milliseconds expire. To turn off the relay you just call SetState(false) once. This turns the relay off and aborts any pending monoflop. This way the relay will turn itself off 5000 milliseconds after your LabVIEW program stopped working, bringing you system to a safe state.

Das kommt höchstwahrscheinlich daher, dass wir in Brick Viewer 2.4.19 geändert haben wie die Liste der seriellen Schnittstellen erstellt wird. Seit dieser Version nutzen wir da eine Hilfsfunktion von PySerial zu. Da scheint es aber einen Bug zu geben, der Apple M1 Macs betrift, der aber in PySerial 3.5 behoben sein soll. Wir liefern Brick Viewer aber mit PySerial 3.4 aus. Teste bitte die angehängte Version, die jetzt mit PySerial 3.5 kommt. brickv_macos_2_4_20_snapshot_445ae07.dmg

Brick Logger 2.1.8 Reuse thread in timer to avoid slow memory leak Fix device list clearing on config loading Fix slow memory leak in data tab Downloads: Windows, Linux, macOS, RED Brick

Brick Viewer 2.4.20 Hide unused custom line ending controls in hex mode in RS485 Bricklet plugin Reuse thread in Data Logger timer to avoid slow memory leak Fix Data Logger device list clearing on config loading Fix slow memory leak in Data Logger data tab Add firmware version column to Health Monitor dialog Improve udev rule compatibility on Linux Add support for RTC driver config to HAT Brick plugin Add support for simple mode to NFC Bricklet plugin Increase required PySerial version to 3.0 Add support for flashing ESP32 (Ethernet) Bricks Downloads: Windows, Linux, macOS

Brick Logger 2.1.8 Thread im Timer wird wiederverwendet um langsames Speicherleck zu vermeiden Löschen der Geräteliste beim Laden einer Config repariert Langsames Speicherleck im Data-Tab repariert Downloads: Windows, Linux, macOS, RED Brick

Brick Viewer 2.4.20 Unnötige Zeilenendeneinstellungen werden im Hex-Modus des RS485 Bricklet Plugins ausgeblendet Thread im Data-Logger-Timer wird wiederverwendet um langsames Speicherleck zu vermeiden Löschen der Data-Logger-Geräteliste beim Laden einer Config repariert Langsames Speicherleck im Data-Logger-Data-Tab repariert Firmware-Versions-Spalte zum Health Monitor hinzugefügt udev-Regel-Kompatibilität unter Linux verbessert Unterstützung für RTC-Treiber-Einstellung zum HAT-Brick-Plugin hinzugefügt Unterstützung für Simple-Mode zum NFC-Bricklet-Plugin hinzugefügt Benötige PySerial Version auf 3.0 erhöht Unterstützung für das Flashen von ESP32 (Ethernet) Bricks hinzugefügt Downloads: Windows, Linux, macOS

Du setzt mit dem Monoflop das Value auf true, oder? Wenn das hängenbleibt dann, musst du es schaffen den Master Brick so abzuschießen, das der Pin der das Relais schaltet im true Zustand hängen bleibt und dadurch das Relais geschaltet bleibt. Das passt aber nicht dazu, dass du sagst der Stapel startet neu. Denn dann sollte das Relais wieder in den Standardzustand false zurückgehen. Da kann ich dir jetzt leider auch nicht viel mehr zu raten als die Störung durch die 230V Seite zu beseitigen, sorry.

Tritt das Problem auch auf, wenn du den EPN510 vom Dual Relay Bricklet trennst? Oder muss der EPN510 wirklich geschaltet werden, damit das Problem auftritt? Was schaltet der EPN510 auf seiner Lastseite? Wie sieht deine Kabelführung aus? Hast du 230V Leitungen parallel zu Bricklet Kabeln liegen, so dass Störungen auf den 230V Leitungen sich auf die Bricklet Kabel übertragen können. Das könnte ein EMV Problem sein, dass also das schalten der Last eine Störung erzeugt die verlässlich den Stapel abschießt. Alternativ verursacht das Schalten der Last einen Spannungseinbruch der soweit durchschlägt, dass die Versorgung des Stapel kurzzeitig wegbricht, auch wenn du da ein 24V Netzteil dazwischen hast.

Klingt alles so als sollte das funktionieren können.

Ich nehme mal an du verwendet das Gefälle im Seil zum Herabrollen lassen des Wagens durch Schwerkraft. Sprich in dem Fall muss der Motor den Wagen bremsen durch langsames abwickeln der Schnur. Beim Heraufrollen zieht der Motor dann den Wagen über das Gefälle hinweg hoch. Da das Gefälle ja sehr gering ist trägt das Seil den Großteil des Gewichts des Wagens und der Zug auf der Schnur sollte gering sein. Da ist es fast egal was du an Motor nimmst, würde ich schätzen, so lange dieser nicht grundsätzlich zu schwach ist und mit ausreichend Kraft langsam genug laufen kann. DC Getriebemotor ist sicher keine falsche Wahl. Interessant sind da vielleicht auch andere Fragen. Muss der Motor immer unter Strom stehen, um den Wagen in der seiner Position zu halten? Oder hast du bei einem DC Getriebemotor genug Reibung im Getriebe, so das das Gewicht des Wagens die Schnur nicht abwickeln kann auch wenn der Motor stromlos ist? Oder ist das ein Schneckengetriebe? Wie ist es mit der Geräuschentwicklung? Ist das Surren eines DC Getriebemotor ein Problem? Aus welchem Material ist der Geist? Kann sich das mit Wasser vollsaugen im Regen? Wie schwer ist das ganze dann?

Das sollte nicht passieren. Mit den Zahlen/Versionen kann ich nichts anfangen. Die aktuelle WARP1 Firmware ist Version 1.2.4.

Also ist das eine Wechselwirkung zwischen Cumulocity Agent und Brick Daemon? Wenn du also den Cumulocity Agent deinstallierst anstelle von Brick Daemon dann läuft es auch it HAT Brick? Nein, dazu kannst du aber irgendeine Modbus TCP Bibliothek verwenden z.B. PyModbus. Für Modbus TCP brauchst du keine extra Hardware, da das einfach über die normale Netzwerkschnittstelle geht.

Das ist die Frage hier! Wenn du in der Config nicht die spidev Zeile drin hast, dann verwendet Brick Daemon den BCM2835 Treiber um mit dem HAT Brick und den Bricklets zu kommunizieren. Wenn du die spidev Zeile drin hast, dann verwendet Brick Daemon stattdessen den spidev Treiber. Warum das jetzt einen Unterschied macht ist mir gerade unklar. Eigentlich ist der BCM2835 Treiber besser, da mit diesem der Durchsatz höher ist. Das ist alles mit Kernel 5.10.60, oder? Interessant wäre zu sehen ob das mit 5.10.17 besser wird. Es kann sein, dass eine Kernel Änderungen das Problem auslöst, muss aber nicht. Bleiben die Fehlerzähler gleich, oder steigen die kontinuierlich? Im Health Monitor kannst du die Werte auch in einer Datei speichern. Mach das bitte mal und häng die Datei hier an. Wir pflegen den Tinkerforge Support in Cumulocity nicht, sondern das macht Cumulocity selbst. Cumulocity scheint einfach alle deine Bricks und Bricklets nicht zu unterstützen: Device Identifier 111 ist der HAT Brick Device Identifier 290 ist das Sound Pressure Level Bricklet Device Identifier 292 ist das Motion Detector Bricklet 2.0 Device Identifier 297 ist das Air Quality Bricklet Das hat also nichts mit dem HAT Brick Problem zu tun, sondern einfach damit, dass der Cumulocity Support für Tinkerforge unvollständig ist. Das ist hier auch nachzulesen: https://cumulocity.com/tinkerforge/ (in der Fussnote) https://cumulocity.com/guides/device-tutorials/tinkerforge/

Kann beides sein. Daher die Fragen ob du mit frischer SD Karte oder anderem Raspberry Pi testen kannst. Es kann auch sein, dass der HAT Brick selbst einen Schaden hat. Hast du die /etc/brickd.conf Änderung auf spidev gemacht? Laut Log wird immer noch der BCM2835 Treiber verwendet.

Laut Log treten da massive Kommunikationsprobleme zwischen Raspberry Pi und HAT Brick auf. Wie kommst du auf Kernel 5.10.60? Wenn ich ein frisches Raspberry Pi OS Image mit dem Image Tool auf eine SD Karte dann bekomme ich Kernel 5.10.17. Hast du den Kernel mit rpi-update aktualisiert? Bei mir tritt das Problem nicht auf. Weder mit Kernel 5.10.17 noch mit 5.10.60. Hast du eine weitere SD Karte zur Hand auf der du ein frisches Raspberry Pi OS aufsetzen kannst? Oder hast du ein anderes Raspberry Pi zur Hand mit dem du testen kannst?

rtrbt ist gerade im Urlaub. Ich habe aber mal den Generator durchlaufen lassen, kann aber nicht garantieren ob das auch zu deiner Version passt. Probier die beiden Dateien mal aus. bricklet_industrial_dual_ac_relay.c bricklet_industrial_dual_ac_relay.h

Hast du am HAT Brick noch Bricklets angeschlossen, oder ist das HAT Brick alleine? Falls Bricklets angeschlossen sind, macht es dann einen Unterschied, wenn du diese absteckst? Welche Kernel Version läuft auf dem Raspberry Pi? Das kannst du mit folgenden Kommando abfragen: uname -a Brick Daemon kann auf zwei verschiedene Arten mit dem HAT Brick kommunizieren. Standardmäßig wird auf dem Raspberry Pi der BCM2835 Backend verwendet. Das kannst du an dieser Zeile sehen: 2021-09-20 13:40:58.661002 <I> <bricklet_stack_linux.c:129> Using BCM2835 backend for Bricklets (Raspberry Pi detected) Du kannst brickd aber zwingen den spidev Backend zu verwenden. Dazu musst du die Datei /etc/brickd.conf bearbeiten und folgende Zeile anhängen: bricklet.spi.driver = spidev Um die Änderung zu übernehmen musst du dann brickd neustarten, oder das ganze Raspberry Pi neustarten. Das Kommando für den brickd Neustart ist: sudo systemctl restart brickd Wenn die Änderung geklappt hat sollte folgende Zeile im Log stehen: Using spidev backend for Bricklets (forced by config) Macht es dann einen Unterschied, wenn du auf das spidev Backend wechselst?

Korrekt!