photron
-
Gesamte Inhalte
3.053 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
39
Posts erstellt von photron
-
-
Die PHP Beispiele sind nicht als CGI-Programme gedacht, sondern als Kommandozeilen-Programme.
Im CGI Modus darf ein PHP Programm maximal 30 Sekunden laufen, ansonsten wird es abgebrochen. Alle Callback Beispiele laufen aber bis du sie per Tastendruck abbrichst. Daher ist es nicht verwunderlich, wenn du Probleme mit einem Callback Beispiel im CGI Modus hast.
Für den CGI Modus sind Callbacks ungeeignet, weil du nicht auf einen Callback warten kannst/willst. Dort solltest du Getter verwenden. Also solltest du dir die Simple Beispiele ansehen. Dort musst du dann diese Zeile entfernen, die das Beispiel davon abhält sich zu beenden bevor du das mit einem Tastendruck gestattest.
fgetc(fopen('php://stdin', 'r')); -
1 hour ago, kstaehle said:
Vielleicht habe ich da einen Fehler eingebaut, so dass der Constructor ohne Fehler zurückkehrt, obwohl keine Verbindung hergestellt werde konnte - und daher rührt dann der zweite Fehler...!? Sorry, war etwas spät gestern...🙄
Das erklärt einiges...
Am besten machst du deine Schleife in deinem Code der IPConnection.connect() aufruft anstatt IPConnection.php zu verändern. Aber eigentlich sollte das gar nicht nötig sein.
Bei einem "Connection timed out" Fehler würde ich erwarten, dass die IP Adresse die du angegeben hast überhaupt nicht erreichbar ist, z.B. weil sie falsch ist oder ein Routing-Problem vorliegt, so dass diese von deiner Disk Station aus gar nicht erreichbar ist.
Kannst du von der Disk Station aus 192.168.178.39 per ping erreichen? Oder ist auf der Disk Station vielleicht eine Firewall eingerichtet die ausgehenden Netzwerkverkehr blockiert? Oder ist das PHP auf der Disk Station beschränkt und darf keine Netzwerkverbindung aufbauen?
-
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:
-
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:
-
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.
-
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
-
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
-
On 10/1/2021 at 8:13 PM, lapawa said:
Denn selbst der Monoflop von 250ms wird teilweise nicht zurückgenommen!
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.
-
1
-
-
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?
-
1
-
-
41 minutes ago, Sinus76 said:
kann es sein, dass nach einem Update in der GUI Usernamen und Passwort gefordert werden?
Das sollte nicht passieren.
42 minutes ago, Sinus76 said:Unter der 3.15 war definitiv ein offener Zugang ohne Passwort eingestellt, jetzt bei 3.16 kommt nun die Abfrage.
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?
1 hour ago, R_Gerald said:Ist es auch möglich über Modbus TCP die Bricklets auszulesen?
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.
-
1 hour ago, R_Gerald said:
Wenn ich spidev wieder auskommentiere ist der Raspbarry wieder nicht mehr ansprechbar. Woran liegt das?
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.
1 hour ago, R_Gerald said:Laut Health Monitor gibt es aber schon noch viele Checksum und Frame Erros.
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.
1 hour ago, R_Gerald said:Die Sensordaten der Child devices werden aber nicht übertragen es kommen diese Fehlermeldung am Raspberry PI
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:
-
2 hours ago, R_Gerald said:
Schaut es eher nach einem SW oder HW Problem aus?
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?
VB.Net-Programm auf Red Brick funktioniert nicht mehr
in Allgemeine Diskussionen
Geschrieben
Standardmäßig wird die Stdout-Ausgabe des Programms aufgezeichnet, außer du hast das absichtlich ausgestellt. Die Logdatei findest du im Brick Viewer im Log-Abschnitt des Programms unter Continuos als stdout.log. Was steht da drin?
Du musst nur die UIDs der Bricklets anpassen die in deinem Programm auch wirklich verwendet werden.