photron
-
Gesamte Inhalte
3.040 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
39
Posts erstellt von photron
-
-
The way you structured the code you call idr.get_value() a little bit to early. You call idr.get_value() directly after the ipcon.connect() call. At that moment the authentication probably has not completed yet and the ESP32 Brick rejects all requests.
I modifed your example to wait for a few milliseconds before the idr.get_value() call for the authentication to complete. Please test the modification, it should fix the problem.
-
1
-
-
The Bricklet doesn't respond to a request in time. The first thing to check in that case is that you use the correct UID to address the Bricklet. But because other functions work, I think you are using the correct UID already.
Do you have a load connected to the relay? If yes, does the problem go away when you disconnect the load from the relay?
Can you show your complete Pump_control.py?
-
Du hast im Release-Modus nicht ws2_32.lib;advapi32.lib; zu den zusätzliche Linker-Abhängigkeiten hinzugefügt.
-
7 minutes ago, StH said:
1.1.2 zu 2.0.11
Du musst nicht alle Zwischenschritte machen. Du kannst direkt auf die neuste Version aktualisieren.
-
Ich rate mal und sage, dass du aus dem Callback heraus die Datei mit fopen('dateiname.csv', 'w') öffnest und dann die Daten schreibst. Der Modus 'w' öffnet die Datei zum überschreiben. Du musst die Datei mit Modus 'a' öffnen für anhängen (append).
-
1
-
-
-
-
Änderungen für den CSV Export in der nächsten Version (vermutlich WARP2 2.0.12): Semikolon statt Komma als Feldtrenner und Window-1252 Kodierung, statt UTF-8.
-
1
-
-
Die Wallbox zeichnet tausende Ladevorgänge auf. Unter charge_tracker/last_charges sind die letzten 30 Ladevorgänge als JSON verfügbar und unter charge_tracker/charge_log alle aufgezeichneten Ladevorgänge als Binärblob.
-
Brick Viewer 2.4.24
- Fix Python dev-mode default handling
- Do not touch /usr/lib/python3/dist-packages on Debian Linux
- Convert Debian Linux package build to debhelper
- Disable ADC calibration for 7p Bricks
- Add missing pkg_resources dependency on Linux
- Update all temperature readings with 10 Hz
- Stop callback emulator from delivering results to destroyed plugins
- Avoid crash while loading the 3D model in all IMU plugins
- Avoid PyQt5 import problem with the Qt module
-
Brick Viewer 2.4.24
- Python dev-mode Standardbehandlung korrigiert
- Es wird nicht mehr mit /usr/lib/python3/dist-packages gemacht auf Debian Linux
- Debian Linux Package zu debhelper konvertiert
- ADC Kalibrierung für 7p Bricks deaktiviert
- Fehlende pkg_resources Abhängigkeit auf Linux hinzugefügt
- Alle Temperaturmessungen werden mit 10 Hz ausgelesen
- Callback Emulator liefert keine Ergebnisse mehr an bereits zerstörte Plugins aus
- Crash beim Laden des IMU 3D Models vermieden
- PyQt5 Importprobleme mit dem Qt Modul behoben
-
16 minutes ago, tasdevil13 said:
Wobei mir gerade nicht 100% klar ist, an welchen Anschluß das kommt
Den Anschluss kannst du frei wählen. Einfach einen der freien nehmen, die sind alle gleichwertig.
-
brickd fragt mit der SHGetFolderPathA Funktion das CSIDL_COMMON_APPDATA Verzeichnis ab. Das mappt auf meinen beiden Windows 10 Instanzen hier auf C:\ProgramData\. Laut MSDN kann das aber auch auf C:\Documents and Settings\All Users\Application Data\ mappen, das Verzeichnis existiert zumindest laut Explorer hier nicht.
brickd schreibt nur an eine Stelle. Welche das aber ist kontrolliert am Ende Windows und was jetzt das wahre Verzeichnis ist und was eine View ist kontrolliert auch Windows.
-
Brick Daemon 2.4.4
- Add menu entry to clear Live Log in Windows Log Viewer
- Abort delayed USB stall recovery if device was removed in the meantime
- Add rate limit for Bricklet error messages
- Increase libusb requirement from 1.0.6 to 1.0.20
- Allow to disable mesh gateway
- Update bundled libusb to 1.0.26.11755 on Windows (Windows Vista or newer required) and macOS
Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS
-
Brick Daemon 2.4.4
- Menueintrag zum Löschen des Live Logs zum Windows Log Viewer hinzugefügt
- Verzögerte USB Stall Recovery wird abgebrochen, wenn der Brick in der Zwischenzeit entfernt wurde
- Maximale Rate der Bricklet Fehlermeldungen wurde beschränkt
- Minimale libusb Anforderung von 1.0.6 auf 1.0.20 angehoben
- Mesh Gateway kann deaktiviert werden
- Mitgelieferte libusb Version auf 1.0.26.11755 für Windows (Windows Vista oder neuer benötigt) und macOS
Downloads: Windows, Linux (amd64, i386, armhf, arm64), macOS
-
4 hours ago, tfRookie said:
Wenn ich dieses Problem rein softwareseitig abfangen moechte, kann ich dann einen reset des Master Bricks ausloesen? Oder wuerde auch dieser Befehl in der Queue verworfen?
Auch der Reset Befehl wird den Master Brick nicht erreichen.
4 hours ago, tfRookie said:Koennte ich das Windows brickd service neu starten?
Das kannst du versuchen.
-
2kHz bingen dir nichts, da das Bricklet bzw der ADC darauf maximal 976 Werte pro Sekunde messen kann. Das folgenden Beispiel schafft eine Abfragerate von 991 Hz, allerdings ohne jeglich Verarbeitung der Werte.
// This example is not self-contained. // It requires usage of the example driver specific to your platform. // See the HAL documentation. #include <Arduino.h> #include "src/bindings/hal_common.h" #include "src/bindings/bricklet_industrial_dual_analog_in_v2.h" void check(int rc, const char *msg); void example_setup(TF_HAL *hal); void example_loop(TF_HAL *hal); static int32_t last_voltage; static bool last_voltage_is_new = false; // Callback function for voltage callback static void voltage_handler(TF_IndustrialDualAnalogInV2 *device, uint8_t channel, int32_t voltage, void *user_data) { (void)device; (void)user_data; // avoid unused parameter warning last_voltage = voltage; last_voltage_is_new = true; } static TF_IndustrialDualAnalogInV2 idai; void example_setup(TF_HAL *hal) { // Create device object check(tf_industrial_dual_analog_in_v2_create(&idai, NULL, hal), "create device object"); // Set sample rate to 976 samples per second check(tf_industrial_dual_analog_in_v2_set_sample_rate(&idai, TF_INDUSTRIAL_DUAL_ANALOG_IN_V2_SAMPLE_RATE_976_SPS), "set sample rate"); // Register voltage callback to function voltage_handler tf_industrial_dual_analog_in_v2_register_voltage_callback(&idai, voltage_handler, NULL); // Set period for voltage (channel 0) callback to 1ms without a threshold tf_industrial_dual_analog_in_v2_set_voltage_callback_configuration(&idai, 0, 1, false, 'x', 0, 0); } static int start; static int count = 0; void example_loop(TF_HAL *hal) { // Poll for callbacks tf_hal_callback_tick(hal, 0); // Check for new value if (last_voltage_is_new) { if (count == 0) { start = millis(); } count++; int32_t voltage = last_voltage; last_voltage_is_new = false; //tf_hal_printf("Voltage: %d 1/%d V\n", voltage, 1000); if (count % 1000 == 0) { int duration = millis() - start; tf_hal_printf("Got %d values in %d milliseconds (%d Hz)\n", count, duration, (duration * 1000) / count); } } }
-
brickd Version wird vermultich 2.4.3 sein. Ist aber auch nicht relevant hier, denke ich.
brickd hat intern in all Richtungen für all Datentransfers Queues um Bursts anfangen zu können. Die Queues sind jeweils 32768 Nachrichten lang. In deinem Fall ist die Queue zu diesem Master Brick Stack voll und es wurden seitdem 1308320823 Nachrichten weggeworfen. Die eigentliche Ursache ist wahrscheinlich schon lange nicht mehr im Log zu finden, da dieses auf die letzten 25MB beschränkt ist. Häng trotzdem bitte mal alle brickd.log und brickd_*.log Dateien aus dem C:\ProgramData\Tinkerforge\Brickd Verzeichnis an.
Das mag ein brickd Bug sein ich sehe aber gerade nicht wo. Ich habe mir die entsprechende Logik gerade nochmal angeschaut. Oder es ist ein USB Problem, dass verhindert, dass Daten an den Brick über USB geschickt werden können.
Bleibt das Problem auch nach einem ab und anstecken des Bricks an USB oder einem Neustart von Windows bestehen?
-
Das Problem ist im Github Repo behoben:
https://github.com/Tinkerforge/brickv/tree/e374b595664f3f68004271bc8dd994e213332f9e
Dev-Mode wird nur noch verwendet, wenn Dev-Mode überhaupt vorhanden ist.
-
Ich habe vor einer Weile mal damit begonnen einen Emulator zu programmieren. Das ist allderings längst nicht fertig:
https://github.com/Tinkerforge/generators/tree/master/emulator
Diese kleine Beispiel kann ein Ambient Light Bricklet 3.0 gut genug emulieren, dass es zu Anzeige des Graphen in Brick Viewer reicht:
https://github.com/Tinkerforge/generators/blob/master/emulator/emulate_ambient_light_v3_bricklet.py
-
There is not my_callback callback, that's why its not called. There is only the CALLBACK_FRAME_STARTED callback.
def cb_frame_started(length): print('cb_frame_started', length) ls.register_callback(BrickletLEDStripV2.CALLBACK_FRAME_STARTED, cb_frame_started)
-
Sorry, da haben wir nicht aufgepasst. Wir geben aktuell Python 3.5 als Mindestversion an, Dev Mode ist aber in Python 3.7 neu. Der Code versucht zu erkennen ob er paketiert oder aus Source läuft und schaltet Dev Mode nur bei Source ein. Du startest brickv vermutlich über main.py und dann wird Dev Mode aktiviert, den Python 3.6 nicht hat.
Das kannst du jetzt erstmal auf verschiedene Arten umgehen. Zum Beispiel, leg dir neben die main.py eine Datei namens package_type mit dem Inhalt none.
Wir werden das für die nächste Version besser lösen.
-
Brick Viewer 2.4.23
- Allow saving config when Modbus master timeout is changed for RS485 Bricklet
- Enable Python development mode when running from source
- Fix socket leak on connect error
- Add manual y-axis scaling for plot widget
- Remove all driver files for Windows 7 and earlier
- Fix calibration dialog title for Compass Bricklet plugin
- Fix Galileo satellite numbers for GPS Bricklet 3.0
- Add support for IPv6 connections
- Add commandline options to specify host, port and secret
- Add tab select menu that stays in the top left corner
- Fix corner cases in IMU Brick(let) plugin untab handling
- Add manual firmware list update button if auto-search for updates is disabled
-
Brick Viewer 2.4.23
- RS485 Bricklet Konfiguration kann wieder gespeichert werden, wenn der Modbus Master Timeout geändert wird
- Bei Ausführung vom Quelltext wird der Python Entwicklermodus aktiviert
- Socket wird bei Verbindungsfehler korrekt geschlossen
- Manuelle Y-Achsenskalierung zu Plots hinzugefügt
- All Windows 7 spezifischen Treiber entfernt
- Kalibrierungsdialogtitel des Compass Bricklet Plugins korrigiert
- Galileo Satellitennummern des GPS Bricklet 3.0 korrigiert
- Unterstürzung für für IPv6 Verbindungen hinzugefügt
- Kommandozeilenparameter für Host, Port und Secret hinzugefügt
- Menukopf zur Tab-Auswahl oben links hinzugefügt
- Behandlung von Sonderfällen un der IMU Brick(let) Plugin Ausklinklogik korrigiert
- Knöpfe zur manuellen Aktualisierung der Firmware-Listen hinzugefügt im Fall, dass "Auto-Search for Updates" deaktiviert ist
ESP32-Firmware: Merkwürdiger Fehler beim Build unter Windows
in Software, Programmierung und externe Tools
Geschrieben
Python verwendet auf Windows CP1252 als Encoding, auf Linux aber UTF-8. Wir entwicklen hier alle auf Linux, daher ist es leider nicht aufgefallen, dass wir nicht an allen Stellen Textdateien explizit als UTF-8 öffnen, sorry. Ich habe das gerade im git Repo repariert.