photron

Das über eine Datenbank zu vereinheitlichen ist eine gute Idee. Deine Regeln sind aber komplexer formuliert als sie müssten. Da würde ich die Zustände/Stellwerte der Ausgänge mit zu den Eingaben der Regeln nehmen. Das erlaubt dir dann Sensor 0 > 30C° und Sensor 14 < 50°C and Systemmodus = “no Errors” then Schalte Motor1 ein bis Sensor 0 < 10°C so zu formulieren if Sensor0 > 30C° and Sensor14 < 50°C and Systemmodus = “no Errors” and Motor1 aus then schalte Motor1 ein if Sensor0 < 10°C and Motor1 an then schalte Motor1 aus Dadurch kannst du dieses bei 30°C einschalten und 10°C ausschalten des Motors einfacher abbilden, weil dadurch diese "bis" Komponente entfällt und die Regeln selbst zustandslos sind. Du wirst nicht darum herum kommen die Regeln an irgendeiner Stelle ausformulieren zu müssen. Aber ich würde mich auf eine einfach nicht-verschachtelte Struktur von if-this-then-that beschränken. Der sich immer wiederholende Ablauf wäre - den Zustand/Messwert aller Eingänge und Parameter bestimmen - mit all diesen Eingabewerten die Regeln nacheinander auswerten, um die neuen Zustände/Stellwerte der Ausgänge zu bestimmen - die Ausgänge auf die bestimmten Zustände/Stellwerte setzen Da die Regeln nicht Aktionen, sondern Zustände/Stellwerte bestimmen, kommt das System auch damit zurecht, wenn sich Regeln widersprechen, weil in diesem System einfach die letzte Regel gewinnt.

Ja, das erklärt alles perfekt.

Also, du hast in Brick Viewer den richtigen Chip Type ausgewählt. Ich habe gerade auch eine Rolle frisch aus den Lager getestet, um zu sehen, dass wir da auch das richtige verkaufen. Was wir tun, die Rolle funktioniert einwandfrei. Du hast das Channel Mapping auf BGR stehen, es müsste aber GRB sein, dass kann aber nur falsche Farben erklären, teste trotzdem ob das was ändert. Auf deinem Foto ist nicht zu erkennen, ob du Daten- und Minusleitung richtig angeschlossen hast. Dein Adapterkabel zwischen Bricklet und LED Strip scheint 2 grüne Leitungen zu haben. Du könntest Daten und Minus vertauscht haben. Normalerweise sollte das Kabel rot, grün weiss sein. Kontrollier bitte noch mal, ob du das wirklich richtig für WS2812B angeschlossen hast: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/LED_Strip_V2.html#led-streifen-ohne-taktleitung-z-b-ws2812b

Die Anfrage sieht also auf dem Oszilloskop identisch aus, egal ob aus Matlab oder aus Brick Viewer gesendet, sprich der Sensor kann das nicht unterscheiden. Aber es kommt in Brick Viewer und Matlab nur eine Antwort an, wenn Brick Viewer die Anfrage gestellt hat, aber nicht wenn Matlab die Anfrage stellt. Das verwirrt mich weiterhin sehr. Interessant wäre jetzt noch zu sehen, was mit der Antwort laut Oszilloskop ist. Ob der Sensor sie wirklich nicht sendet. Ich nehme an auf dem RS485 Bricklet ist die aktuelle Firmware 2.0.5 drauf. Falls nicht, updated bitte mal über Brick Viewer. Okay, mal ganz zurück zum Anfang. Funktioniert das unveränderte Loopback Beispiel in Matlab, unter der Annahme das Bricklet ist entsprechend der Angaben im Beispiel verkabelt und der DIP Schalter passend eingestellt? Funktioniert das Loopback Beispiel mit eurer 9600 7E1 Konfiguration? Wobei ihr hier für Loopback auf Full-Duplex stellen müsst, statt auf Half-Duplex wie beim Sensoraufbau. rs485.setRS485Configuration(9600, BrickletRS485.PARITY_EVEN, ... BrickletRS485.STOPBITS_1, BrickletRS485.WORDLENGTH_7, ... BrickletRS485.DUPLEX_FULL);

Die Datenleitung ist nach dem Reset 4.8V, weil das Bricklet dann noch nichts sendet und die Leitung High hält. Sobald du in Brick Viewer das Bricklet etwas senden lässt, sendet das Bricklet dann dauerhaft Daten auf der Datenleitung und dein Multimeter misst da einen Mittelwert von 1.25V, so weit so gut. Darauf dass die 1.25V sich nicht ändern würde ich nichts geben, dass heißt nicht, dass das Bricklet kaputt ist, sondern nur dass ein Multimeter hier nicht das richtig Werkzeug ist. Da kommst du nur mit einem Oszilloskop oder Logic Analyzer weiter, um zu erkennen ob das Bricklet da das richtige sendet: https://www.mikrocontroller.net/articles/WS2812_Ansteuerung

Klinkt alles nach Wackelkontakt bzw schlechtem Kontakt, vor allem wenn du schon sagst DATA sähe mit dem Multimeter komisch aus. Ich würde als nächstes mal die Lötverbindung zwischen Anschlusskabel und Strip überprüfen/nachlöten.

Sehr komisch. Da habe ich keine gute Idee zu. Das initiale Programm sollte einfach funktionieren, abgesehen von den 4 Writes direkt nacheinander. Für mein Verständnis: Aus Brick Viewer heraus funktioniert alles wie erwartet. Wenn die Anfrage gesendet wird kommt eine passenden Antwort darauf. Wenn ihr das aber aus eurem Programm heraus macht kommt keine Antwort. Wenn aber euer Programm läuft und ihr parallel dazu in Brick Viewer die Anfrage sendet, dann kommt eine passenden Antwort in eurem Programm und in Brick Viewer an. Habe ich das so richtig verstanden? Was passiert wenn Brick Viewer bereits läuft und ihr euer Programm startet? Dann kommt weder in Brick Viewer noch in eurem Programm eine Antwort an. Sprich das Problem scheint zu sein, dass der Sensor die Anfrage nicht versteht/empfängt wenn sie von eurem Programm gesendet wird und deswegen gar nicht antwortet. Das Problem ist nicht, dass die Antwort zwar kommt, aber euer Programm sie nicht erhält, wenn die Anfrage auch durch euer Programm gesendet wurde? Hier ein paar schlechte Ideen 😜 1) Es gibt eine sehr kleine Chance, dass sich Brick Viewer und euer Programm über den Zustand des Read Callbacks in die Quere kommen. Wenn in Brick Viewer der Tab des RS485 Bricklets ausgewählt wird, dann merkt dich Brick Viewer ob der Read Callback bereits aktiv war. Falls nicht, dann wird der Callback aktiviert und beim Verlassen des Tabs wieder deaktiviert. Daher testet bitte mal Brick Viewer zu beenden und dann euer Programm auszuführen. Ich erwarte allerdings nicht, dass das hilft, denn damit das ein Problem sein könnte müsstet ihr in Brick Viewer den Tab verlassen genau zwischen euer Programm sendet die Anfrage und die Antwort kommt an. Unwahrscheinlich. 2) Startet mal alle Hardware neu. Also den ganzen Tinkerforge Aufbau und die Sensoren einmal vom Strom trennen, kurz Warten und wieder anschließen. Nur um sicherzustellen, dass die Hardware nicht einfach in einem verwirrten Zustand ist. Auch Unwahrscheinlich. 3) Brick Viewer ruft auch nur die Write Funktion auf. Habt ihr mit dem Oszilloskop mal die Anfrage von Brick Viewer und eurem Programm verglichen? Dort sollte keine Unterschied bestehen. Per Oszilloskop solltet ihr auch sehen können, ob vom Sensor einfach keine Antwort kommt oder ob eine Antwort kommt, dass Bricklet sie aber nicht versteht, wenn die auslösende Anfrage von eurem Programm gesendet wurde.

Okay, um einmal meine Verwirrung zu klären. Der Sensor den du da verwendest sprichst Modbus ASCII und das was du da schickst sieht auch nach korrektem Modbus ASCII aus, daher auch die 7 Bit. Die Modbus Funktionen des Bricklets sind für Modbus RTU, meinen Ratschlag das zu nutzen kannst du ignorieren, das funktioniert nicht. Es sieht auf den ersten Blick so aus als hättest du dein Vorgehen von Brick Viewer korrekt in dein Programm übertragen. Eine Unterschied könnte noch sein, dass du in Brick Viewer zwischen den 4 Anfragen die du schickst etwas Zeit vergeht, weil du händisch die Anfrage wechseln musst. In deinem Programm schickst du die 4 Anfragen aber direkt nacheinander raus. Du lässt also dem ersten Sensor gar keine Zeit zu antworten, sondern quatscht ihm sofort mit der Anfrage für den zweiten Sensor dazwischen. Versuch also mal in deinem Programm nur die erste Anfrage zu schicken, oder zwischen den Anfragen eine kurze Pause einzubauen, damit die Sensoren auch eine Chance haben zu antworten.

Ich fürchte der Modbus Modus des Bricklets für 7 Bit ist ungetestet. Daher jetzt eine Rolle rückwärts 😜. Da es mit Brick Viewer funktioniert müssen wir jetzt nur finden was in deinem initialen Programm nicht passt. Was genau hast du in Brick Viewer als Anfrage eingeben? Und hast du dabei das Encoding auf "ASCII" oder "Raw (Hex Bytes)" gestellt?

Was mich auf den ersten Blick stutzig macht ist die Wordlength von 7 Bit, üblich wären 8 Bit. Auf den zweiten Blick kommt die Frage warum du in deinem Programm das Bricklet im RS485 Modus verwendest und händisch Modbus versuchst zu sprechen, wenn du im Brick Viewer erfolgreich das Bricklet mit Modbus Master Modus verwendest mit der Read Holding Registers Funktion. Du solltest nicht auf das Loopback Beispiel aufsetzten, sondern auf das Modbus Master Besipiel: https://www.tinkerforge.com/de/doc/Software/Bricklets/RS485_Bricklet_MATLAB.html#modbus-master-matlab Und dieses von modbusMasterWriteSingleRegister auf modbusMasterReadHoldingRegisters umstellen.

Das Beenden müsste dein Programm selbst machen. Zum Beispiel den Wert time.time() beim Start des Programm speichern, dann in der Schleife mit dem aktuellen time.time() Wert vergleichen und nach 8h (28800s) das Programm beenden. Das Starten kannst du über den Scheduler machen. Dort den Cron Modus wählen mit "0 8 * * *", damit das Programm jeden Tag um 8 Uhr gestartet wird.

Das ist ein Python 2 vs 3 Problem. Du verwendest auf deinem PC Python 3, auf dem RED Brick aber Python 2. In Python 2 hängt der Typ einer Division von den Operanden ab: 2 / 3 ergibt eine Integer-Division 2 / 3.0 eine Float-Division. In Python 3 macht der normale Divisions Operator / immer eine Float-Division und für eine Integer-Division muss man // verwenden. In deinem Fall betrifft dieser Unterschied die alpha Berechnung: alpha = (count*360)*10/1000 Alle Operanden darin sind Integer, dadurch passiert dort eine Integer-Division, obwohl du eine Float-Division erwartest. Um das zu lösen musst du in Brick Viewer, im "Python Configuration" Abschnitt für dein Programm, die Python Version von 2 auf 3 umstellen.

Dann würde ich provokant sagen, dass du eben dein Programm so schreiben musst, dass es die "Signale" pro Sekunde und nicht pro Umdrehung ausgibt 😜 Sorry, aber da musst du mal genauer beschreiben, was du da machst. Mir ist unklar was du da genau misst und wie, so kann ich dir da keine sinnvolle Antwort zu geben. Wenn möglich zeigt auch mal dein Python Programm vor.

There is not precompiled library you could link against. You need to include ip_connection.c and brick_imu_v2.c from the API bindings into your Visual Studio project, as the documentation explains.

Schon komisch. Da das Hotplug Flashen geklappt hat muss der I2C Bus okay sein, da das Flashen über den I2C Bus läuft. Da ist mir jetzt unklar wo das Problem steckt. Hast du schon versucht den Master Brick neu zu flashen?

Wenn du das Programm auf den RED Brick lädst kannst du dabei angeben, dass das Programm automatisch gestartet werden soll. Das kannst du auch nachträglich noch umstellen.

Du kannst über Brick Viewer Programme auf den RED Brick laden und ausführen lassen: https://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick_Program_Tab.html Auf dem RED Brick läuft ein Debian Linux, daher unterschiedet sich der RED Brick vom Betriebssystem her nicht stark von einem Raspberry Pi. Über USB steht dir eine serielle Konsole bereit, die du auch auch über den Brick Viewer zugreifen kannst. Wenn du dem RED Brick über eine USB WLAN Strick oder USB Ethernet Stick oder eine Ethernet Master Extension eine Netzwerkschnittstelle gibst, die du über Brick Viewer konfigurieren kannst, dann kannst du den RED Brick auch über SSH erreichen.

Das Verhalten passt zum klassischen Problem eines ungeflashten 10 Pol Bricklets. Wenn auf einem 10 Pol Bricklet keine oder eine defekte Firmware ist, dann versucht der Brick diese trotzdem auszuführen und stürzt dabei ab. Das passt zum den Symptomen, dass die 4 LEDs nicht leuchten. Das passt allerdings nicht damit zusammen, dass das bei 4 verschiedenen Bricklets auftritt. Du kannst versuchen eines der 10 Pol Bricklets per Hotplug zu flashen, aber ich erwarte nicht wirklich dass das hilft. Dazu schließt du zuerst den Brick ohne Bricklets an USB an und erst danach (eigentlich verbotenerweise) schließt du an den laufenden Master Brick ein Bricklet an. Wenn du jetzt keine elektrischen Probleme auf dem Master Brick hast, dann sollte der Master Brick dir das nicht Übel nehmen. Aber das Bricklet wird so jetzt nicht erkannt und der Master versucht jetzt nicht das zu nutzen. In Brick Viewer flasht du jetzt das Bricklet neu. Dazu wählst du sozusagen blind Parent, Port und Plugin aus, entsprechend dem was du angeschlossen hast. Wenn der Flashvorgang erfolgreich war kannst du jetzt den Master Brick neustarten und alles funktioniert wieder. Ich erwarte aber fast, dass der Master Brick ein Problem mit seinem I2C Bus hat und das Hotplug Flashen mit einem Fehler scheitert. Ein Unterschied zwischen 7 Pol und 10 Pol Bricklets ist, dass die 7 Pol Bricklet den I2C Bus der Bricks nicht mehr verwenden, das entspricht den 3 fehlenden Pins. Auf der Unterseite des Master Brick sitzt ein 20 Pin Chip der Teil des I2C Bus ist. Schau mal nach ob dort vielleicht durch Verschmutzung ein Kurzschluss zwischen den Pins vorliegt. Schau auch mal nach, oder in den Bricklet Anschlüssen Pins krumm sind und Kurzschlüsse machen.

Das Debug Log Level ist nicht für den normalen Betrieb gedacht, da es abhängig vom System so viele Meldungen ausgeben kann, dass darunter die Performance von Brick Daemon leiden kann. Ich werde das Level dieser Meldung in der nächsten Brick Daemon Version auf Info ändern, da diese Meldung offensichtlicher Weise für den Nutzer interessant ist 😁. Bis dahin kannst du dir über den Debug Filter behelfen. Aktuell kann dieser nicht einzelnen Zeilen erfassen, sondern nur auf Dateibasis arbeiten. Mittels -all,+bricklet.c kannst du die Debug Logausgabe auf die Datei bricklet.c beschränken. Wenn du das Level auf Debug stellst, aber keinen Filter angibst, werden alle Debug Meldungen ausgegeben, daher müssen zuerst über "-all" alle Debug Meldungen wieder herausgefiltert werden, um dann mit "+bricklet.c" nur die aus der Datei bricklet.c wieder zuzulassen. Auf der langen Nice-to-have-Liste steht auch noch "-all,+bricklet.c:256" zu unterstützen, um auch auf Zeilennummern filtern zu können, aber ob und wann das was wird steht in den Sternen.

Nach kurzem googlen kann ich dazu nur finden wie man auf Basis einen PyPI Packages selbst eine Conda Package bauen kann: https://docs.conda.io/projects/conda-build/en/latest/user-guide/tutorials/build-pkgs-skeleton.html#building-a-simple-package-with-conda-skeleton-pypi Alternative dazu diese Stack Overflow Frage, wobei das mit Vorsicht zu sehen ist, da Frage und Antworten schon älter sind. Möglicherweise entspricht die Option die du da gefunden hast der pip_interop_enabled Option in der in der letzten Antwort die Rede ist. Wenn ich das richtig verstehe, kann Conda dadurch PyPi Packages zwar nicht installieren, kann aber über pip installierte PyPI Packages nutzen: https://stackoverflow.com/questions/29286624/how-to-install-pypi-packages-using-anaconda-conda-command

Das liegt daran, dass die Tinkeforge API Bindings nicht in Conda (bzw der kommerziellen Variante Anaconda) verfügbar sind, weil sie noch niemand dafür paketiert hat.

Bindings: JavaScript 2.1.30 Restore ECMAScript 5 compatibility Add 64-bit integer support using BigInt Download: JavaScript

Bindings: JavaScript 2.1.30 ECMAScript 5 Kompatibilität wieder hergestellt 64-Bit Integer Support mittels BigInt hinzugefügt Download: JavaScript

Error 31 is "Timeout". The most common cause for this is that you used the wrong UID in the example. Are you sure it's error 31? Error 13 is "Connection Failed" that could be caused by wrong IP address or port configuration. The RED Brick does not used the WebSocket port configured on the Ethernet Extension itself. For the RED Brick you need to configure the WebSocket port on the RED Brick itself: Brick Viewer > RED Brick > Settings > Brick Viewer > Web Socket Port.

Diese Frage kam schon häufiger auf und ich dachte eigentlich wir hätten das mittlerweile dokumentiert, scheint nicht der Fall zu sein. Der Sensor misst einfach die absolute Niederschlagsmenge seitdem die Batterien eingelegt wurden. Jeglichen anderen Zeitbezug musst du selbst berechnen. Das der Messwert fällt sollte unmöglich sein, wenn du nicht die Batterien für einen Reset herausgenommen hast. Hast du vielleicht mehr als eine Station in Empfangsreichweite und die haben zufälligerweise die gleiche ID?