Jump to content

All Activity

This stream auto-updates

  1. Today
  2. Yesterday
  3. Das klingt vielversprechend. Laden funktioniert ja grundsätzlich, daher sind zwei Wochen kein Thema. Danke für die schnelle Analyse.
  4. Die Logs sind spannend. Man kann den Effekt sehen weswegen wir einen "ID.3 Mode" in der Firmware haben: https://github.com/Tinkerforge/evse-bricklet/blob/master/software/src/iec61851.c#L217 Anscheinend kann das bei den eGolfs auch auftreten. Es gibt dabei einen kurzen Peak in dem CP/PE-Widerstand wenn dieser von 2700 auf 880 gehen sollte. In deinem Fall geht er kurz bis auf über 30000 Ohm hoch, die Firmware akzeptiert aber nur bis 30000 Ohm. Ich werde da noch eine zusätzliche Wartezeit einfügen zwischen dem Zustandswechsel um das Problem zu verhindern. An der Stelle ist das Timing auch nicht sicherheitsrelevant, das Schütz ist ja nicht geschaltet. Die neue Firmware gibt es dann allerdings erst ca. in zwei Wochen. Bei uns überschneiden sich gerade die Urlaubszeiten, daher ist es schwierig das dazwischen zu bekommen. Ab Anfang Oktober sind wir wieder voll besetzt.
  5. Please try this example. I think the critical difference is the disable_read_callback() function call here. If you have the Brick Viewer tab for the RS232 Bricklet open, then the read callback is enable and the read() function call will return empty in that case. You should close Brick Viewer before testing this example. #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "XYZ" # Change XYZ to the UID of your RS232 Bricklet import time from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_rs232 import BrickletRS232 # Convert string to char array with length 60, as needed by write def string_to_char_list(message): chars = list(message) chars.extend(['\0']*(60 - len(message))) return chars, len(message) # Assume that the message consists of ASCII characters and # convert it from an array of chars to a string def char_list_to_string(message, length): return ''.join(message[:length]) if __name__ == "__main__": ipcon = IPConnection() # Create IP connection rs232 = BrickletRS232(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Ensure read callback is disabled, otherwise the read call will return empty rs232.disable_read_callback() # Send request rs232.write(*string_to_char_list('S02\r\n')) rs232.write(*string_to_char_list('MSV?\r\n')) # Wait for response time.sleep(1) # Read response message = char_list_to_string(*rs232.read()) print('Message: ' + repr(message)) ipcon.disconnect()
  6. Hi everybody! I'm working with a RS232 bricklet, connected to a weighing machine. I have to send a code to connect (S02) and ask for a measure (MSV?) to this device, but i don't receive responde with the value of the weight. ipcon = IPConnection() # Create IP connection rs232 = BrickletRS232(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd rs232.write(*string_to_char_list('S02')) rs232.write(*string_to_char_list('MSV?')) time.sleep(1) buffer=rs232.read() The value of buffer is always the same and the length of the message is 0, so i understand is not a valid response. I have tried adding the characters \ r \ n to the end of the string and the result is the same. However from Brickviewer if I enter both codes in the input field (first S02, Intro and then MSV? and Intro again) I get a valid response with the correct measure. What could be the problem? Thank you very much and excuse my english
  7. Das ist interessant, weil es bedeutet, dass sowohl Ladecontroller, als auch der ESP, der das Webinterface hostet, noch liefen. Vermutlich war die Kommunikation zwischen beiden gestört. Ich versuche weiterhin mal das hier zu reproduzieren, bin aber wie gesagt die nächsten zwei Wochen im Urlaub, dauert also etwas.
  8. Moin Erik, Firmware ist 1.2.4-60f17413 Anbei drei Logs die ich gerade erstellt habe, ich denke der Titel erklärt mein Vorgehen. Gruß Felix start_9A_dann_reduziert_auf_6A.txt 6A_manueller_Start.txt 6A_autostart.txt
  9. Moin, Das sieht nach dem klassischen VW-Ladeproblem aus: Wenn das Auto von "Ich bin hier" auf "Ich will laden" umschaltet, springt der Widerstandsmesswert kurz extrem hoch, was die Wallbox als "Das Auto ist nicht mehr angeschlossen" interpretiert. Wir haben in der Firmware 1.2.3 dafür den ID.3-Modus eingebaut, der auf die Änderung träger reagiert. Welche Firmware hast du laufen? Falls es nicht 1.2.4 ist, teste mit der aktuellen nochmal (Findest du hier). Wenn das Problem dann immer noch auftritt, erstell bitte nochmal ein Ladelog. Du musst die Konfigurationen übrigens nicht rauslöschen: Passwörter können über das Webinterface nicht ausgelesen werden, d.h. du leakst höchstens deinen WLAN-Namen und den Hostnamen der Box (die kannst du natürlich gerne löschen, aber alles, was mit evse/ anfängt könnte hilfreich zum Debuggen sein ;) ) Grüße, Erik
  10. Moin Zusammen, ich habe bei mir festgestellt, dass der eGolf nicht laden will, wenn der Ladestrom auf 6A oder 7A steht. Ab 8A startet er zuverlässig. Ob die Ladeleistung 100%ig zu dem einstellten Strom passt, bin ich mir nicht sicher. Wenn ich im Menü des Golf den Ladestrom auf 5A begrenze und die Box auf >=8A steht, dann lädt er auch mit 5A. Ich habe mal die Leistung auf 6A gestellt und manuell den Ladevorgang gestartet: Anbei das Ladelog, ohne den Configteil, ich bin mir gerade nicht sicher ob dort sensible Daten drin stehen. Hat jemand eine Idee? Gruß Felix Ladelog_6A.txt
  11. Last week
  12. Werde ich machen. Das Webinterface war noch erreichbar, eine Statusänderung auf Laden konnte ich aber auch nicht mehr sehen. Ich meine, dass auf der Startseite auch nicht verbunden stand, obwohl das Auto den Stecker hörbar verriegelt hatte.
  13. Kurze Bestandsaufnahme: Damit meinst du, dass die Wallbox auf der das Lastmanagement läuft, die zweite Wallbox nicht mehr erreichen konnte. An welcher von beiden hattest du das Auto angeschlossen? (Das Lastmanagement schaltet sicherheitshalber alle Boxen ab, wenn eine nicht erreicht werden kann) Warst du auch auf dem Webinterface der anderen Box? War da etwas suspekt, hast du eventuell Ereignis-Logs? Das heißt, dass der Ladecontroller selbst noch lebt und nur der ESP32 auf dem das Webinterface läuft Probleme macht (oder die Kommunikation zwischen den beiden oder zwischen den Wallboxen) Dann können wir schonmal Netzwerkprobleme ausschließen (es sei denn die Wallbox selbst hat nicht bemerkt dass sie nicht mehr im WLAN ist o.Ä.) Mir ist unklar, was du damit meinst. Hast du es mehr als einmal geschafft, dass das Lastmanagement blockiert und es ist egal welche Box du neustartest, damit es wieder funktioniert? Hoffentlich nicht ;) Ich halte ein reines Speicherleck für unwahrscheinlich, da würde es bei dir nicht > einen Monat problemlos laufen, soviel RAM hat der ESP nicht. Falls du das Problem nochmal erzeugen kannst würde mich folgendes interessieren: Kannst du das Webinterface beider Wallboxen noch erreichen? Falls ja: Ein Ereignis-Log und einen Debug-Report beider Wallboxen (im Debug-Report ist u.A. auch der aktuelle Zustand des Lastmanagers) Wie lange bleibt der Zustand so? Reicht es eine Box neuzustarten damit es wieder funktioniert? Wir haben hier einen Lastmanagement-Verbund aus vier Wallboxen, der lief aber meines Wissens noch nie länger als zwei bis drei Wochen, weil man immer irgendwelche Dinge testet. Ich bin aber nächste und übernächste Woche im Urlaub und habe meinem Kollegen mal bescheid gesagt, dass er aufpassen soll, dass niemand die Boxen neustartet. Ich habe mir die aktuelle RAM-Auslastung der vier Boxen notiert, für den Fall, dass es wirklich ein Speicherleck ist. Eventuell wissen wir dann Anfang Oktober mehr.
  14. Hallo zusammen, ich habe seit nunmehr etwas über einem Monat die Beta laufen. Heute lud das Auto nicht mehr, weil die wallbox laut web Interface keine Verbindung hatte. Irgendwas kam allerdings an, da die Status Led anging. Ich habe daraufhin die wallbox vom Strom getrennt und wieder aktiviert, dann ging es wieder. Das Verhalten konnte an meinen beiden Warp Pro nachstellen. Läuft mit der Zeit irgendein Speicher voll und daher arbeitet die ab nicht mehr ordentlich? Auto möchte ich explizit nicht ausschließen, allerdings war die einzige Änderung von geht nicht zu geht, dass ich den LSS raus und wieder rein habe.
  15. Moin, das werde ich gerne machen. Ich habe gestern mit MQTT Explorer weiter debugged und für mich sieht es auch so aus als würde die WARP zu bestimmten Zeiten einfach keine updates senden, was dann ja für ein Problem mit einem der laufenden Prozesse sprechen würde. Ich werde das Login deaktivieren, das Update einspielen und dann weiter beobachten. Danke Dir.
  16. Moin Thomas, Teste bitte mal die Lastmanagement-Beta. Ich habe ein paar Fälle gehabt, bei denen sich der (alte) Webserver und der MQTT-Client auf den Füßen standen. MIt dem neuen Webserver sind die Probleme dann verschwunden. Achtung: Falls du den Login des Webinterfaces aktiviert hast, musst du u.U. deinen Browser nach dem Update neu starten, die Beta unterstützt den Loginprozess nicht.
  17. Der Logger ist nicht auf maximalen Durchsatz ausgelegt. Das Acceleromter Bricklet 2.0 hat Callback-Funktionen die bis zu 60 Werte gleichzeitig übertragen und von diesen können bis zu 1000 pro Sekunde übertrgen werden. Damit kann die maximale Sampling-Rate des Bricklets übertragen werden.
  18. Hallo zusammen, meine WARP 1 verliert mehrmals am Tag Ihre MQTT-Kommunikation und ich brauche Hilfe bei der weiteren Fehlersuche. IST-Stand: WARP-1 Smart mit FW: V1.2.4-60f17413 und MQTT konfiguriert Raspi mit Mosquitto MQTT Broker der mit zig anderen Komponenten seit Jahren zuverlässig funktioniert UniFi U6 Lite Wifi Bisherige Erkentnisse: Auf der WARP sehe ich: 55987456 Disconnected from MQTT: TCP_DISCONNECTED (0) 55989101 Connecting to MQTT broker 55989121 Connected to MQTT session=0 max payload size=14330 Im Mosquitto-Log sehe ich: 1631520569: Client warp-U7X has exceeded timeout, disconnecting. 1631520569: Socket error on client warp-U7X, disconnecting. 1631520572: New connection from 192.168.28.30 on port 1883.1631520572: New client connected from 192.168.28.30 as warp-U7X (c1, k30). Diskussion: Mein erster Verdacht viel natürlich aufs WLAN, das UniFi Dashboard zeigt allerdings eine Wifi-Experience von 100%, die Signalstärke ist mit -76db vollkommen ausreichend, Paketverluste sind sehr gering (2%, für WLAN einandfrei). Dazu kommt die Tatsache dass MQTT über TCP ja eigentlich extrem robust ist was einzelne Aussetzer angehen würde. Für mich sieht es so aus, als würde die WARP keine Updates senden, der Broker erkennt sie dann als stale und beendet die Verbindung. Im Fehlerfall hatte ich auch schon auf den Broker gelauscht und habe keine MQTT-Messages gesehen. Meine Frage wäre jetzt, was kann ich auf der WARP tun, um den Fehler evtl. weiter einzugrenzen bzw. zu prüfen ob der MQTT-Prozess ok ist und ob die WARP die Pakete im Fehlerfall wirklich nicht sendet? Danke für eure Hilfe! Thomas
  19. Schönen guten Tag, Folgendes Szenario: Ich möchte einen Prozess näher untersuchen, hierfür sollen die Beschleunigungen mit möglichst hoher Sampling-Rate aufgenommen werden. Die Messwerte sollen in eine csv Datei geschrieben werden. Der Accelerometer 2.0 erlaubt eine Sampling-Rate von 25,6 KHz, jedoch erreiche über den Data Logger des BrickViewers in Testläufen per USB nur eine Sampling-Rate von ca. 60 Hz. Wo liegt mein Fehler? Gefühlt werden die Messwerte des Accelerometers 2.0 von dem Data Logger zu selten abgefragt. Im Programmieren bin ich nicht versiert, würde also wenn möglich im DataLogger des BrickViewers bleiben.
  20. ja, der Master (oder viele oder ein Stack) kann einfach zusätzlich per USB angeschlossen werden.
  21. Earlier
  22. Kann man den Raspi mit HAT Brick oder HAT Zero Brick in Kombination mit einem Master Brick verwenden, wenn man Bedarf nach mehr Anschlussmöglichkeiten für Bricklets hat?
  23. Weitere Messungen und Überlegungen haben zu einer Erklärung geführt: Die Leitungslänge und damit der Ohmsche Widerstand von der WB (= Messpunkt für FI-Auslösezeit) bis zum FI reduziert den vom Messgerät erzeugten Fehlerstrom. Die Auslösezeit des Typ-B FI im TN-Netz liegt im Toleranzbereich von 0,4s. Es gibt allerdings noch nicht erklärbare Abweichungen zwischen erster und zweiter Halbwelle. Mein Fazit ist aber: Das Problem wird nicht vom WARP-Charger erzeugt. Insofern ist das Thema an dieser Stelle beendet. Nochmals vielen Dank an alle, die sich hierzu Gedanken gemacht haben! ms
  24. Hi everyone, I am quite new to Tinkerforge and I've got the following project I would like to install. I've got a gas bag at my research plant. To measure the mass of the produced gas I would like to hang the gas bag at my load cell. Therefore I'am not sure how to manage it properly. * Due to the momentum of force does it make a difference where exactly I am fixing my load cell beam and where I am putting the load on the beam? * Do I have to isolate the beam ? Currently I've tried to calibrate the system but the weight shown is fluctuating a lot. I would be grateful if there is anybody who ever had a similar problem or an idea how to fix this issues. Recommendations are appreciated. Thanks Jonas
  25. Hallo NetFritz, nein, ich denke ich habe dir damals eine falsche/unvollständige Info gegeben. Sorry!
  26. Danke für die Antwort! Die Firmware sollte mit 2.0.5 auf dem neuesten Stand sein. Dein Hinweis hinter dem Optokoppler zu messen hat mich nochmal auf die debouncing Problematik aufmerksam gemacht, der Reedschalter scheint kurz nach Betätigung noch einmal auf zu schwingen und auch wenn die vom Bricklet ausgegebene Periode nicht so ganz passt, ist das die naheliegenste Erklärung für die Glitches. Ich werde mir wohl mal Gedanken über ein analoges Debouncing machen. Wenn ich die Periode auf ~100µs genau bestimmen will, ist die Variante ein Software Debouncing und Flankenzählung via Industrial Digital In Bricklet + Red Brick wohl zu langsam. (?) Danke noch einmal.
  27. Bezüglich der Callbacks: Der Callback wird ausgelöst sobald sich irgendeiner der im Callback übergebenen Werte ändert verglichen zur letzten Auslösung. Das Zählen und Messen der Periode, Duty Cycle etc übernimmt eine Hardwareeinheit des XMC1400, dort lässt sich leider kein Debounce-Wert konfigurieren. Falls das möglich ist, könntest du um sicher zu gehen dass der Prozessor wirklich keine Glitches sieht, mit dem Oszilloskop einmal auf der Prozessorseite hinter den Optokopplern messen. Dazu müsstest du vom Optokoppler (das sind die 4 Bauteile in der Mitte der Leiterplatte, je einer pro Kanal, mit 2 Pinnen unten zum Eingang hin und 3 Pinnen oben zum Prozessor hin) den mittleren Pin oben gegen GND messen. An GND kommst du am einfachsten über das Haltepad vom Bricklet-Stecker. Falls das Bricklet an einem Master Brick angeschlossen ist: Das Gehäuse des USB-Steckers ist auch GND. Das ist dann das Signal welches der Prozessor wirklich als Eingang bekommt. Andere Frage: Ist die Firmware auf dem Bricklet auf dem neuesten Stand?
  28. Hallo zusammen, ich habe ein seltsames Verhalten von einem Industrial Counter: Die Impulse kommen von einem 24V Netzteil, welches über einen Reedkontakt unregelmäßig mit ~3 Hz durchgeschaltet wird und ich möchte die einzelnen Perioden von Falling zu Falling Edge messen. Meistens klappt das gut und die Werte sind sinnvoll, ab und an wird aber eine zu kleine Periode (z.B. 100ms) und ein unrealistischer Duty Cycle Wert von 0,00% (??) oder 50,00% angezeigt. "Echte" Events haben größere Periodenlängen und einen Duty Cycle von ~60% mit zufälligeren Nachkommastellen. Das Problem tritt nur beim Aufbau mit 24V und dem Reedschalter auf. Mit dem parallel geschalteten Oszi sehe ich keine Auffälligkeiten und keine zu kurze High/Low-Perioden bis auf etwas Überschwingen an den Flanken, welches aber im µs Bereich und in der Amplitude außerhalb des High/Low-Wechsels liegt. Bei einem "perfekten", regelmäßigen Signal von einem 20V Frequenzgenerator gibt es keine Probleme. Jetzt bin ich mit meinem Latein am Ende: 1. der Prescaler ist ausreichend groß, so dass ein Counter Overflow ausgeschlossen sein sollte (z.B. 4096: Minimale Frequenz 0.36Hz, Auflösung 42.66us) 2. Ein Debouncing-Setting wie im Digital In Bricklet scheint es nicht zu geben? 3. Verschiedene Kanäle zeigen das gleiche Verhalten Hat jemand eine Idee? Eine Frage auch zu Callbacks bei Werteänderung: Was ist mit Werteänderung gemeint, der value, d.h. der High-Low-Zustands des Kanals oder z.B. Periode bzw. Frequenz? Wenn ich den Abstand von Falling zu Falling Edge messen will, bräuchte ich im Idealfall einen Callback bei jedem Übergang von High zu Low (und nicht bei jeder Value-Änderung).
  1. Load more activity
×
×
  • Create New...