Jump to content

remotecontrol

Members
  • Content Count

    607
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Nachtrag - Ports getauscht: Quad-Relay an Port C und Temp-IR an Port D mit 2m Kabel => geht ! Vorher war es umgekehrt: Temp-IR an C oder "unten" (A oder B) und Quad-Relay an D.
  2. Es scheint am Quad Relay zu liegen: stecke ich das ab, dann bekomme ich realistische Werte am Temp-IR Sensor ! Aufbau dann nur noch Master mit 2m Kabel zum Temp-IR (also auch kein WIFI mehr). Stecke ich das Quad Relay wieder an => 0° Habe das Quad-Relay mit dem 6cm Kabel und dem 15cm Kabel versucht, am dem das Temp-IR funktioniert ... Kann es sein, dass die Gesamtkabellänge am Stack das Problem ist? Mit einem 2m Kabel geht es, kommt aber ein Kabel dazu, sei es auch nur ein Kurzes, dann kommen Fehler ... Oder ich nehme kurze Kabel, dann geht es auch.
  3. Also ein Rotary Poti funktioniert an dem 2m Kabel. Aber auch an einem zweiten 2m Kabel funktioniert das Temp-IR nicht (zeigt 0° bei beiden Werten). Hänge ich ein Quad Relay dran zeigt der Brickv erstmal nichts Auffälliges: alle 4 Ports lassen sich schalten und der Status wird nach Disconnect / Connect korrekt erkannt. Ich habe aber die Ausgänge nicht real nachgemessen. Am Bricklet scheint es aber anzukommen, sonst würde der Status nach reconnect nicht korrekt ausgelesen werden - oder ?
  4. Hallo TF Team, ich habe folgenden Aufbau: Master WIFI ext 2.0 Industrial Quad Relay (mit 6cm Kabel am Master) Temperature IR 1.0 Und ich habe auch noch die "alten" geschirmten 2m Kabel mit 10pol Stecker. Wenn ich das Temperature Bricklet mit 15cm oder 50cm Kabel anschließe funktioniert es einwandfrei. Nehme ich das 2m Kabel wird es erkannt, aber für beide Temperaturwerte kommt nur 0.0 zurück. D.h. das Bricklet scheint mit dem langen Kabel nicht zu funktionieren? Ist das generell so oder eher Zufall? Jetzt hätte ich tatsächlich mal den Bedarf
  5. Hatte den PI jetzt 3 Tage aus Nach Neustart war das Datum 14. Februar 2019 Nach einer Weile (~ 30 Sekunden) fing die Zeit an, langsam hochzuzählen, das wurde dann schneller bis die aktuelle Zeit erreicht wurde der ganze Vorgang ging ca. über 2 Minuten Sieht für mich so aus, als verliert die RTC im HAT die Zeit und der NTP braucht einfach eine Weile bis die korrekte Zeit im System eingestellt ist. Das Hochzählen scheint mit systemd-timesynd und NTP ähnlich zu sein. Ist der PI nur ein paar Stunden aus, so ist die Zeit quasi nach Booten sofort korrekt.
  6. OK versuche ich bei Gelegenheit. Wie lange puffert die RTC im HAT denn ca. die Zeit? Ich muss den PI ja min. 12h Stunden aus lassen damit beim Neustart die Zeit sichtlich hoch geht und der Vorgang lange genug dauert.
  7. Mit NTP und Ethernetverbindung beim Booten tritt das Problem nicht mehr auf. Das NTP gar nicht installiert war ist mir nicht aufgefallen, dachte jede Distro installiert das mit ... nutze das Standard Raspbian. Die fake-hwclock habe ich mal deinstalliert.
  8. Hallo TF-Team, ich habe ein paar Detailfragen zur Funktion der RTC des HAT: in der Doku steht "mit Batteriebackup" => puffert der HAT die Zeit ohne zusätzliche externe Batterie? Der Raspi war einen Tag aus, kurz nach booten des Raspi wird die Zeit "schnell hochgezählt" bis die tatsächliche aktuelle Zeit erreicht wird. Ich habe eine Schleife in meinem Programm welches eigentlich nur 1x pro Sekunde aktiv wird und man sieht deutlich, dass es sehr schnell was tut. Eine Uhr zählt mehrere Minuten im Sekundentakt hoch, bis die aktuelle Zeit erreicht wird. => kommt das
  9. Danke für den Link. Das ist vom Prinzip was ich suche. Auf der Startseite finde ich auch noch den Link, aber die Seite zum Projekt fehlt dann doch - schade.
  10. Hallo TF-Team, habt Ihr eigentlich noch die Daten vom alten Wiki? Ich hab' viel zu spät bemerkt, dass damit eine gewisse "Doku" weg ist ... die Links aus dem Form ins Wiki gehen ja auch nicht mehr. Viele Grüße und bleibt gesund
  11. OK, danke für den Hinweis mit Pythin 3.5. Ich muss eh die ganze Distribution aktualisieren, weil die EOL ist. Ein weiterer Grund das nun über die Feiertage zu tun.
  12. Damit komme ich weiter, aber nicht viel: Traceback (most recent call last): File "main.py", line 32, in <module> from tzlocal import get_localzone ImportError: No module named 'tzlocal' Ich habe zwar ein tzlocal Package gefunden, aber das scheint für python2 gewesen zu sein ? Kommentiere ich die Import Zeile aus, kommt der nächste Fehler: Traceback (most recent call last): File "main.py", line 283, in main from brickv.mainwindow import MainWindow File "/home/holger/bin/tf/brickv-2.4.11/src/brickv/mainwindow.py", line 40, in <module> from brickv.plu
  13. Hallo zusammen, wenn ich versuche den Brickv 2.4.11 aus den Sourcen zu bauen + starten, dann bekomme ich mit der neuesten Version diesen Fehler: tf/brickv-2.4.11/src/brickv> python3 main.py File "main.py", line 111 ^ SyntaxError: only named arguments may follow *expression Ich habe Python 3.4.6 auf dem System. Zuletzt hatte ich Brickv 2.4.2 in analoger Weise gebaut, das war lauffähig. Eine Idee was falsch ist ?
  14. Über Ethernet hat der Raspi eine andere IP Adresse. Wie sprichst Du den an? Mit IP-Adresse oder Host-Namen? Kannst Du einen "ping" gegen den Raspi machen, wenn er mit Ethernet verbunden ist und Dich mit ssh einloggen?
  15. Du hast einen RasPi an dem das Load Cell steckt. Und über einen anderen Laptop möchtest Du die Werte auslesen? Dann brauchst Du eine Netzwerkverbindung zwischen Raspi und dem Laptop: WLAN oder Ethernet. Kannst Du den Raspi per Ethernet / Kabel anschließen? Auf dem Laptop kannst Du den Brick Viewer laufen lassen, aber der braucht eine Netzverbindung zum Raspi, wo der Brick Daemon läuft.
×
×
  • Create New...