Tipsy Tinker
-
Gesamte Inhalte
29 -
Benutzer seit
-
Letzter Besuch
Posts erstellt von Tipsy Tinker
-
-
Hey Tinkerforge Community,
das Zusammenspiel der Python Versionen sowie Varianten von Bibliotheken, Kernels in Spyder und Interpreter oder Virtual Envoirement und was weiß ich nicht noch alles verwirrt mich. Ich benötige also mal Nachhilfe, um da etwas Licht in´s Dunkel zu bringen.
Wenn ich ne Python File auf dem RED-Brick ausführen möchte, lade ich Sie mittels Brickviewer dort hoch und wähle Python 3.5.3 im Tab Python Configuration im Brickviewer.
Was passiert, wenn ich dieses Python Skript in Spyder mit Python 3.7.9 geschrieben habe und dann hoch lade? Funktioniert das trotzdem? Abwärtskompatibilität? Wie ist das Zusammenspiel mit anderen Python Versionen?
Kann da jemand was zu sagen?
(Und weiß jemand zufällig, wie ich Spyder dazu bringe, mit Python 3.5.3 zu arbeiten? Also in welchem Spyder-Kernel die unterstützung für 3.5.3 steckt? Krieg da nichts zu gegoogelt)
Vielen Dank, Gruß Tipsy
-
Moin,
vor 10 Stunden schrieb borg:an einen Monitor ranbringt der ein Magnetfeld ausstrahlt
Ja, das konnte ich reproduzieren. Hatte ich in einem anderen Post von Dir schonmal wo gelesen.
Mein Problem konnte ich lösen, in dem ich set_sensor_fusion_mode(0) gewählt habe. Hatte zunächst set_sensor_fusion_mode(2) versucht, allerdings hat das ja, wie oben beschrieben keine Abhilfe geschaffen. Hat wohl nicht ausgereicht, das Magnetometer abzuwählen.
Die Verwendung von unkalibrierten und unkompensierten Sensorwerten genügt wohl im dargelegten Anwendungsfall.
vor 10 Stunden schrieb borg:eine leichte Drehung zurück
Im Zeitlupenvideo kann ich diese nicht erkennen.
Naja, jetzt passt es ja. :)
Trotzdem vielen Dank!
Gruß Tipsy
-
Hallo Zusammen,
Ich hatte für ein studentisches Projekt auch den Versuch unternommen, mittels des IMU Bricks eine Rotationsbewegung aufzuzeichnen und kämpfe scheinbar mit einer Art Sensordrift, den ich aber mit imu.SetSensorFusionMode(2) wie hier vorgeschlagen, nicht wegbekomme.
Am orangen Graph der ermittelten Daten erkennt man das recht gut. Die Werte der Drehbewegung laufen nach dem Nulldurchgang wieder ins Positive, was ja bedeuten würde, dass Real eine Art "Wendung" stattfindet. Allerdings ist real der Bewegungsablauf abgeschlossen. Die Beschleunigungswerte (blauer Graph) und die visuelle Beobachtung entsprechen dem.
Den Versuchsaufbau habe ich mal vereinfacht dargestellt.
Die Bewegung von Pos. 1.) nach Pos. 2.) soll aufgezeichnet werden. Nach dem Ablauf werden aber weiter Werte aufgezeichnet, die gegenläufig sind.
Sind das eigentlich die gleichen Werte, die den IMU in der 3D Anzeige des Brickviewers weiter drehen lassen, wenn er nach dem rumspielen wieder ruhig liegt? Und könnte ein Zusammenhang mit der Kalibrierung, bzw. automatischen Dauerkalibrierung bestehen?
Vielleicht hat wer einen Tip, was man prüfen könnte?
Gruß Tipsy
-
Ok, scheint soweit geklappt zu haben 🙂
Selten lagen Verwunderung und Firmware-Update so nah beieinander *gg*
Vielen Dank auch für Deine Ausführungen zu den Ticks.
Gruß Tipsy
-
Hallo Zusammen,
kann jemand sagen warum folgender Code kein Temperaturwert für die Kerntemperatur des IMU 2.0 Bricks zurück gibt?
#!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "6rGa5o" import time from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_imu_v2 import BrickIMUV2 Liste = ["X","X","X","X","X","X"] def cb_quaternion(w, x, y, z): Liste[1] = (w/16383.0) Liste[2] = (x/16383.0) Liste[3] = (y/16383.0) Liste[4] = (z/16383.0) def cb_temperature(temperature): Liste[5] = temperature def main(): ipcon = IPConnection() imu = BrickIMUV2(UID, ipcon) ipcon.connect(HOST, PORT) imu.register_callback(imu.CALLBACK_QUATERNION, cb_quaternion) imu.register_callback(imu.CALLBACK_TEMPERATURE, cb_temperature) imu.set_quaternion_period(100) imu.set_temperature_period(100) time.sleep(1) i = 0 while i < 20: Liste[0] = i print("Übersicht Werte in Liste:") print("Wert 1:" + str(Liste[0])) print("Wert 2:" + str(Liste[1])) print("Wert 3:" + str(Liste[2])) print("Wert 4:" + str(Liste[3])) print("Wert 5:" + str(Liste[4])) print("Wert 6:" + str(Liste[5])) print("") i = i+1 time.sleep(0.5) ipcon.disconnect() if __name__ == "__main__": main()
Benutze ich cb_all_data wie in den Beispielen gezeigt, kommt der Temperaturwert mit. Möchte ich ihn einzeln haben, so wie hier in meinem Beispiel, bekomme ich ihn nicht aufgerufen.
Vielleicht hat jemand ne Idee, woran das liegen könnte?!
Hintergrund ist, das mein IMU regelmäßig aussteigt, und ich die Vermutung habe, dass ihm ein bisschen zu warm ums Herz ist 😉
Das führt mich zu einer weiteren Frage:
Gefühlt gibt es ein Performance-Unterschied zwischen:
- Alle Werte per Callback erheben, diejenigen die ich benötige loggen
zu:
- Nur diejenigen per Callback erheben und loggen, die ich benötige
liege ich da richtig? Und wenn ja, was sind so die gängigen Tricks und Kniffe, um ein möglichst hochfrequentes Loggen von spezifischen Werten zu realisieren ?
Vielen Dank an alle Tinkerforger da draussen :)
Grüße Tipsy
-
-
Hey :)
Vielleicht liegt hier ein Missverständniss vor. Wenn der Stapel samt RED komplett und gebootet ist, gibt es unter RED eigene Tabs zur IP-Konfiguration.
Diese müssen entsprechend passend zum restlichen Netzwerk konfiguriert sein.
Hilft das weiter?
Grüßle
-
Hi !
Bei meinen Projekten komme ich immer wieder an den Punkt, an dem ich mir eine Art "Leerbrick", also quasi einen Spacer wünsche, der mir verschiedene Handlungsfreiräume bietet. Kabeldurchführung, Verschraubungen unter dem Brickstapel zugänglich machen, Abstandshalter-Funktion oder gar mit einem Lüfter aufgerüstet sind nur ein paar Ideen. Ich stelle mir in etwa sowas wie in meiner Skizze vor.
Toll wäre noch ein ausleiten von 5V auf 2 Lötpunkte, damit man zB. einen Lüfter versorgen könnte.
Somit könnte man zB. seinen RED kühl halten, oder Abwärme von den PoE´s weg schaffen.
Zusätzlich sind Befestigungsösen für zB. Kabelbinder o.Ä. vorgesehen.
Ich habe mal 2 Varianten entworfen:
- Spacer "Frame" im Standard Tinkerforge Formfaktor
- Spacer "light" wobei man da pro Ebene jeweils 2 Stück einsetzt. Diese sind wechselseitig verwendbar.
Natürlich ist zwingend erforderlich, das die Brick-Connectoren durchgeschleift werden.
Interessant wäre für mich auch ein Element, welches die Brick-Connectoren jeweils versetzt trägt und somit ermöglicht, Bricks innerhalb eines Stapels um 90° zu drehen.
Hat man sowas schon mal in Erwägung gezogen? Tendenziell würden es für einige Anforderungen auch Brick-Connector Aufsätze in entsprechender Länge tun.
Vielleicht kann jemand Auskunft geben, oder Communitymitglieder haben Lösungsvorschläge 🙂
Gruß Tipsy
-
Genau,
aber ich raffe noch nicht, wie ich mit dem Script auf den Alarm reagiere.
def main(): ipcon = IPConnection() rtc = BrickletRealTimeClockV2(UID_Clock, ipcon) led = BrickletRGBLEDV2(UID_Led, ipcon) ipcon.connect(HOST, PORT) led_green(led) time.sleep(1) led_red(led) rtc.set_alarm(-1, -1, -1, -1, -1, -1, 5) ### led_green(led) ipcon.disconnect()
Vielleicht könnte mal jemand anhand des Codebeispiel zeigen, was an stelle ### stehen muss, damit die Led nach 5* Sekunden (oder eingestelltem Alarmwert) wieder auf grün schaltet. Ich hab da irgendwie grad nen Knoten.
Die nächste Frage wäre, wie ich das parallel zum eigentlichen Programm bewerkstellige :)
Vielen Dank.
Grüßle Tipsy
-
rtrbt,
vielen Dank für deine Eingaben. Hat mir sehr weiter geholfen.
import subprocess subprocess.run(["sudo", "reboot"])
Hat direkt funktioniert, wird allerdings langfristig ein Sicherheitsproblem darstellen, schätze ich.
Werd mal noch ein bisschen damit herum experimentieren, wäre schon nice das auf einen Alarm zu legen. Hab allerdings noch nicht so ganz raus wie ich auf den Alarm aus dem Skript heraus reagieren kann.
Den Monoflop find ich großartig :) So naheliegend und doch so fern. Langfristig wirds der wohl werden.. 🙂
Grüßle Tipsy
-
Hallo Zusammen 🙂
Besteht die Möglichkeit, den RED Brick aus einem python-Script heraus zu rebooten?
Wenn ja, wie ?Besteht die Möglichkeit, den Alarm aus dem "Real-Time Clock Bricklet 2.0" zu benutzen, um einen reboot auszulösen?
Und aller guten Dinge sind 3:
Besteht die Möglichkeit, irgendwie zu erkennen, das sich der RED aufgehängt hat, um ihn dann zu rebooten? Klingt irgendwie widersprüchlich, aber ihr versteht schon...🤣Vielleicht hat wer Hinweise, wie ich diese Fragestellungen lösen kann, oder hat Recherchehinweise die mich weiter bringen.
Grüßle,
Tipsy
-
Der Allwinner10s ist das SoC des RED-Brick.
Für die Ethernet Extension (mit/ohne PoE) steht hier auf Seite 60 :
-40 bis +85°C
-
Am 31.8.2020 um 08:50 schrieb Tipsy Tinker:
betreibe ein Humiditiy 2.0 Bricklet seit Knapp 6 Monaten störungsfrei im "Hochtemperaturbereich" ... 80-120 °C / rel. Feuchtigkeit 5-20 %
Hab grad nochmal in die Datensätze geschaut. Als max.Temp erreiche ich am Einsatzort des Humidty Bricklets 146 °C, im niedrigen Temperaturbereich bis zu 90% rel. Feuchtigkeit.
Das hier verlinkte Allwinner 10s Datenblatt verrät auf Seite 47:
-20 bis +70°C
Aber ob das so für den RED-Brick im allgemeinen gilt ?!
Es führt kein Weg vorbei, es muss gemessen werden. 😐
-
Jap, wird wohl notwendig sein noch zwei Thermocouple Bricklet mit rein zu hängen. Müsste dann immer zum Aufzeichnungende hin in den Daten erkennbar sein.
Bisher habe ich die deutlich über Handwarme Temperatur aussen am Gehäuse festgestellt. Jetzt werden Tatsachen geschaffen. 🙂
-
Klink mich mal ein,
betreibe ein Humiditiy 2.0 Bricklet seit Knapp 6 Monaten störungsfrei im "Hochtemperaturbereich" ... 80-120 °C / rel. Feuchtigkeit 5-20 %
Wohingegen einer meiner RED-Bricks, in dessen Stapel ausserdem ein PoE-LAN Master seine Arbeit verrichtet, immer mal wieder hängt. Die Abwärme des PoE-LAN Master sorgt regelmäßig für Gehäuseinnentemperaturen im Temperaturbereich < ~60 °C . Ich habe den Verdacht, das ein Zusammenhang bestehen könnte.
Grüße Tipsy
-
Hi Zusammen,
wie bildet man denn auf dem OLED 128x64 Bricklet 2.0 Sonderzeichen ab?
Also zum Beispiel °C wobei hier das "°" gemeint ist. Bzw alle Zeichen die hier
Abgebildet sind und ausserhalb des grünen Bereichs liegen?
Aus 'C kenn ich sowas wie exit_nodes, aber zu Python finde ich dazu nichts.
Hat das was mit der UTF-8 Codierung des Codes zu tun ?
Besten Dank für Hinweise.
Gruß Tipsy
-
Randnotiz:
Was passiert eigentlich mit der Config einer Ethernet Extension (PoE), wenn ich sie ohne RED Brick, direkt per USB konfiguriere, und dann auf den RED Brick stecke ?
Welche Config gilt dann? Diejenige im BrickViewer RED Brick Tab, oder die zuvor auf der Ethernet Extension abgespeicherte?
-
Hi,
hab dir die Logs, von diesem komplizierten Test aufgrund des komplizierten Problems ☺️,
angefertigt und direkt geschickt. Besten Dank für deine Unterstützung!
Vielen Dank
-
- Switch an, RED-Brick bootet über PoE, Netzwerkverbindung funktioniert >> wenn die Thermocouple nicht angeschlossen sind oder Thermocouple und Thermofühler angeschlossen sind
- Dann USB-Kabel eingesteckt, dann verlierst du die Netzwerkverbindung zum anderen Stapel >> wenn keine Thermofühler an den Thermocouple eingesteckt sind
- Alles aus, USB-Kabel eingesteckt gelassen, dann alles wieder gebootet, dann funktioniert es nur, wenn du die Thermofühler an den Bricklets angeschlossen hast? >> oder die Couple garnicht angeschlossen sind
Auffällig wäre noch die enorme Wärmeentwicklung am Stack mit dem RED Brick an der PoE-Extension (192.168.0.2). Die wird sehr deutlich über Handwarm, wenn ich das mal logge 😂 , kommen da
48-52 °C an den "Platine-zu-Platine" an der Oberfläche zustande...
Beim 2ten (192.168.0.3) Stack ist es ok.
-
Ahoi,
PoE-Switch hatte ich die letzten Tage mehrfach zurückgesetzt. Der ist auch ok mit seiner Config, denke ich (Begründet, keine Vermutung).
Zunächst habe ich alle (Netzwerk-)Kabel getauscht. Anschließend alle 7p-10p Kabel.
Aktuell habe ich 2 (eigentlich unbeteiligte, und erst für spätere Umfänge benötigte) Thermocouple am Stack mit dem RED Brick (192.168.0.2) eingegrenzt. Wenn die angeschlossen sind, funktioniert unter der Vorraussetzung, das die Stromversorgung für den Bootvorgang ausschließlich über PoE anliegt, die Kommunikation nach 192.168.0.3 nicht. Egal ob mit oder ohne Thermofühler am Thermocouple.
Es gibt ein Lichtblick
Aber es funktioniert auch nicht dauerhaft.
Siehe Screen.
Wenn es läuft, kann ich auf alle Beteiligten pingen, wenn es nicht läuft, logischerweise nicht.
Eine weitere Eingrezung brachte die USB Verbindung mit in den engeren Kreis.
Aller Wahrscheinlichkeit nach, bricht irgendwo etwas ab/zusammen/ein, wenn zusätzlich zu PoE der USB an den RED Brick kommt.
Und zwar nur unter der Vorraussetzung, das keine Thermofühler an den Thermocouple hängen.
In welchen (internen Event-)Logs kann man das genauer nachschauen? USB gesteckt/nicht gesteckt zB. ?
Überraschend empfindlich...
Muss ich mir was überlegen, wie ich das im Produktivsystem später absichern kann...
Grüßle, Tipsy
-
Moin,
ja hab den Edit von dir nicht rechtzeitig mitbekommen.
Aber auch mit 255.255.255.0 läuft es nicht. Im Programm habe ich als HOST 192.168.0.3, also die IP von demjenigen Stack in dem der Thermocouple steckt, den ich mit der richtigen UID anspreche. Führe ich das Programm mit "localhost" aus, funktioniert es, die Temperatur wird in die Logfiles ausgegeben. Führe ich es auf dem RED Brick aus, bekomme ich den o.g. Eintrag in den Logs..
Ich habe jeweils die Stacks am Switch, und den RED Brick per USB am Rechner.
Nochmal zur Konfiguration:
- Stack mit PoE Ethernet Extension:
IP: 192.168.0.3
Sub: 255.255.255.0
- Stack mit PoE Ethernet Extension und RED Brick
IP: 192.168.0.2
Sub: 255.255.255.0
Gateway: 192.168.0.1
- PoE Switch
IP: 192.168.0.1
Sub: 255.255.255.0
Korrekt?
So langsam setzt Verzweiflung ein...
Kurze Randnotiz noch: Ich hatte in der Vergangenheit einmal den Fall, das die auf beiden Stacks verfügbaren Bricks alle als Tabs im BrickViewer aufgeführt waren... Wie kommt das Zustande?
Beste Grüße & erneut vielen Dank
Tipsy
Edit: Mir fällt gerade auf, das im BrickViewer beim RED Brick Settings//Network "connected" angezeigt wird, obwohl offensichtlich kein Netzwerkkabel angeschlossen ist. Verwirrt mich zusätzlich...
-
Hi,
also mit dieser Config
RED Brick:
Master Extension:
bekomm ich
"""
Traceback (most recent call last):
File "PoE_IP_Test.py", line 16, in <module>
ipcon.connect(HOST, PORT) # Connect to brickd
File "/usr/local/lib/python3.5/dist-packages/tinkerforge/ip_connection.py", line 581, in connect
self.connect_unlocked(False)
File "/usr/local/lib/python3.5/dist-packages/tinkerforge/ip_connection.py", line 784, in connect_unlocked
tmp.connect((self.host, self.port))
OSError: [Errno 113] No route to host"""
bekomms nicht geregelt ...
Hab ich was übersehen ?
-
Hi,
es soll ja gerade ohne FritzBox funktionieren (Habs nochmal dazueditiert, sorry für die möglichweise unpräzise Fragestellung)... quasi Stand-Alone ...
Nur die Stacks und der Switch ... Hast du da auch einen Lösungsansatz?
Vielen Dank
-
Moin Leute,
ich hab hier aktuell 3 Stacks stehen, alle mit Lan.PoE und ein PoE-fähiges Switch.
- Ethernet Master Extension (mit PoE) + Thermocouple
- Ethernet Master Extension (mit PoE) + Thermocouple
- Ethernet Master Extension (mit PoE) + Thermocouple + RED Brick
Ein auf dem RED Brick laufendes Programm soll von allen 3 Thermocouples die Werte runter schreiben.
Allerdings bekomme ich die Teilnehmer ohne DHCP nicht verbunden.
Irgendwo hab ich einen Logikfehler, der sich mir nicht offenbart. Aus der Doku heraus bekomme ich ihn auch nicht gelöst.
Zugegebenermaßen beschäftige ich mich erstmalig mit Netzwerken.
Mein Grundgedanke war, jede Master Extension bekommt manuell im Brickviewer ne IP zugewiesen, diese kann ich dann entsprechend aus dem BrickViewer
oder aus dem Programm heraus ansprechen. Aber aus Gründen die sich mir nicht offenbaren, bekomm ich das ohne DHCP nicht auf die Kette.
Häng ich alles an ne FritzBox, krieg ichs irgendwie hin. Weil die ja DHCP zur Verfügung stellt.
Wo liegt der Hund begraben?
Wie konfiguriere ich das Richtig?
Ziel ist, ich habe am PoE-Switch den Redbrick per PoE Lan und kann dann entsprechend am Switch
Stack um Stack einstecken und somit meine Messstellen entsprechend bei Bedarf erweitern. Das ganze
als in sich geschlossenes Netzwerk. Edit2: Also ohne FritzBox.
Vielleicht hat jemand den entscheidenden Tip!
Vielen Dank, Grüße Tipsy
Edit:
Geil wäre, wenn der RED Brick DHCP könnte..
Python Versionsstände Abwärtskompatibilität Spyder
in Software, Programmierung und externe Tools
Geschrieben
Hey,
das habe ich vermutet und leuchtet auch ein.
Gleiches wird es wohl mit z.B. Numpy und ähnlichem sein, bzw den Paketen die auf dem RED (vor-) installiert sind.
Die Pythonversion ist nicht das eigentliche Problem.. eher die Spyder Version.. und daraus resultierend der entsprechende Kernel... Nunja.
Dankeschön schonmal