Holy

Hallo Nero, die Bitschieberei und Arbeit mit Masken hat ihre Tücken Was für ein Anwendungsfall würdest du gerne mal realisiert sehen? Anbei mal ein Beispiel welches folgende Funktionalität realisiert: Pin 0 und 2 als Eingänge und 1 und 3 als Ausgänge Wenn entweder Pin 0 oder 2 aktiv dann Ausgabe von Pin 1 Wenn Pin 0 und 2 aktiv dann Ausgabe von Pin 1 und Pin 3 Wenn keiner der Eingangspins aktiv dann keine Ausgabe von Ausgangspins Das Snippet im Anhang kannst du auch im Github finden.

So hatte die letzten 2 Wochen leider wenig Zeit zum testen und habe das mittlerweile nachgeholt. Nur ist es nichtmehr reproduzierbar. Ich vermute mittlerweile einen ähnlichen Effekt wie hier.

Ich habe leider keines der genannten Bricklets. Was ich stattdessen mal getestet habe ist nur das Barometer und das Temperature IR Bricklet anzuschließen. Diese Kombination habe ich mittlerweile trotz rund ein Dutzend Versuche nicht zu dem fehlerhaften Verhalten bringen können Ich werde mal der Reihe nach jeweils noch ein weiteres meiner Bricklets hinzufügen und wenn ich das durchprobiert habe dann noch ein Viertes anschließen und da nach Möglichkeit alle Kombinationen durchtesten.

Alles klar. Ich werde nochmal eine Reihe von Ansteckversuchen machen. Was mich hinsichtlich deiner Ausführungen aber trotzdem stutzig macht ist der Fall das die Temperatur auf 20°C konstant geht. Wie passt das ggf. in das Bild mit den gespeicherten Kalibrierdaten?

Siehe meine erste Sammlung an Screenshots. Sobald die Temperatur da statisch auf 20°C geht ist die Höhe rund 7000m und wenn er auf -40°C geht sinds dann 0m. Warum das passiert kann ich nicht beantworten, da aber das Bricklet allein funktioniert halte ich nen Ausfall, Kabel- oder Konnektierungsproblem für eher unwahrscheinlich.

Ich habe den Aufbau nochmal exakt wie deinen gemacht. Habe jeweils nur im Brick Viewer das Barometer angeschaut und sonst auf den Stack nicht weiter zugegriffen. Bei allen 4 angeschlossenen ist es egal ob ich Barometer Bricklet Plugin 1.1.1 oder 1.2.1 RC1 nutze. Ich hatte bei den ersten Tests noch eine WiFi-Extension auf dem Master aber ohne ist das Bild exakt das selbe. Sobald ich nur das Barometer Bricklet alleine an den Master hänge geht es, siehe hierzu die Screenshots zum Vergleich.

Ich hatte auch nen Startup Error als ich alles AUSSER dem Gateway konfiguriert hatte. Wobei es sich so ohne Fehler speichern ließ. Vielleicht fehlt einfach irgend eine Angabe?

Hm, Fehler gefunden! Er saß ungefähr 1 Meter vor dem Monitor. Hatte einfach nen Port geflasht wo NIX dran hing Jetzt nochmal mit dem richtigen Port und Bricklet durchgeführt und das Problem besteht auch mit der neuen Firmware.

Kann ich leider nicht einspielen. Bekomme ich immer einen Verification error

Kann ich nicht bestätigen. Bisher noch keine Probleme gehabt. Ist es rechnerunabhängig an deiner Leitung so?

Die LabVIEW-Bindings habe ich mittlerweile um folgendes erweitert: Reconnect-Funktionalität der "IP Connection"-Klasse Barometer Bricklet hinzugefügt Der Download ist unter https://github.com/Felmer/TinkerWithG/downloads zu finden. Die Autogenerierung hab ich bisher nicht weiter vorran getrieben. Mal sehen ob ich da endlich mal weiter mache

Hab gerade den Master auf 1.4.1 geflasht und jetzt ist der Wert bei Start auf 1200 mbar und fällt in mehreren Schritte auf 10 mbar ab. Und dann noch ein Fall wo er einfach über den ganzen Bereich einfach hin und her springt. Zum Glück ist das nicht real sonst würde ich hier wohl nimmer sitzen Das Barometer Bricklet selbst scheint nicht defekt zu sein. Sobald es alleine am Master hängt lässt sich nix von diesem komischen Verhalten in irgend einer Art und Weise herbeiführen.

Ich habe exakt das selbe Problem. D.h. unter Umständen liefert das Barometer Bricklet 10 mbar und 20 oder -40°C. Für die Versuche habe ich folgende Hardware und Firmware verwendet: Master Brick (1.4.0) Temperature-IR Bricklet (1.1.1) Humidity Bricklet (1.1.0) Barometer Bricklet (1.1.1) Ambient Light Bricklet (1.1.0) Bisher ist es bei mir immer nur bei 3 oder 4 Bricklets am Master aufgetreten und ist hierbei direkt von Anfang an so und sporadisch auch erst nach einiger Zeit in Betrieb. Ich habe verschiedenste Kombinationen durchprobiert was angesteckte Bricklets, Ports und auch Kabellängen angeht. Leider ohne irgend welche Kombinationen bei denen man das Problem zuverlässig reproduzieren kann. Wenn das Problem im laufenden Betrieb nach einiger Zeit auftritt ist auch bisher immer das Temperature-IR Bricklet betroffen. Port und/oder Kabellänge hatten hierbei keinen Einfluss. Was mir hierbei noch aufgefallen ist, ist dass der Wert nicht sofort auf 10mbar fällt sondern in großen Schritten abfällt. Also irgendwas ist da sehr komisch jetzt spinnt es total. Es springt von 10mbar auf 1200 und dann wieder auf normal. Bilder zu dem ganzem im Anhang.

Ich mache es immer so im BrickViewer: [*]UID für den Port laden [*]Gegen angeschlossene Bricklets prüfen im Hauptfenster [*]zugehörigen Typ der für die geladene UID gilt auswählen [*]Bricklet flashen Müsste doch auch automatisch so gehen?

Über einen langen Zeitraum kann jede Connection wegsterben. Ich denke man muss das nicht zwingend in der API handhaben. Wenn man z.B. auslesen könnte ob die Connection automatisch reconnected wurde könnte die Anwendung entsprechend die Callbacks neu setzen. Eine andere Variante wäre sicher eine Art Session einzuführen. Die bei einem Connect vom brickd an den Client mitgeteilt wird und er beim reconnect auf diese Session reconnecten kann. Wäre aber denke ich problematisch da Protokolländerung, mal abgesehen vom Aufwand in den Bindings und dem brickd.

Ist das nicht als problematisch einzustufen? Es ist dann ggf. ja möglich das ein Anwendungsprogramm, was primär Callbacks nutzt, zwar eine aktive Verbindung hat aber keine Daten mehr bekommt und hierbei, bei periodischen Callbacks, nichtmal unterscheiden kann ob nun einfach ein Reconnect zum entfernten brickd stattgefunden hat oder einfach die Werte sich nicht geändert haben (da wird ja dann auch keine Callback geschickt).

Dann stellt sicher meiner Meinung nach die Frage was passiert wenn man einen entfernten brickd abfragt und die Connection stirbt. Reconnected die IP Connection dann automatisch und wir haben geschildertes Problem? Sobald der brickd mal nicht lokal läuft wäre das ja vorstellbar.

Ich war gerade dabei die Reconnect-Funktionalität in die LabVIEW-Bindings einzubauen und dabei ist mir folgendes aufgefallen: Wenn ich die Phyton-Bindings korrekt verstehen wird bei auftretendem Socket Error in der Receive Loop solange ein Reconnect versucht bis entweder die Connection wieder steht oder der Thread gekillt wurde. Daraus ergeben sich meiner Meinung nach folgende Fragen: 1. Hab ich die Funktionsweise des Reconnect an der Stelle überhaupt korrept verstanden? 2. Es erfolgt keine Unterscheidung ob eine Connection zu einem WLAN-Stack besteht oder zu einem brickd mit USB-Stack, korrekt? 3. Wie verhält sich der WLAN-Stack bei Reconnect hinsichtlich der Callbacks? Warum die ganzen Fragen: Da meine WLAN-Extension noch unterwegs ist habe ich das ganze mit dem brickd getestet indem ich einfach den Dienst beendet und erneut gestartet habe. Meine Bindings haben sich auch sauber wieder verbunden nur kommen da natürlich keine Callbacks mehr! Die muss ich, da neue Verbindung zum brickd, ja erneut scharf schalten. Verhalten sich die Phyten,C ... Bindings an der Stelle auch so oder hab ich hier einfach nur was vermurkst?

Das ist ja genau der Punkt! Für uns alles kein Problem. Nur ein Neueinsteiger wird mit "Einfach" auf der Startseite gelockt und hätte dann erstmal ne tolle Anleitung und nicht zu einander kompatible Hardware vor sich liegen. Erscheint mir schwierig. Zu dem Cut hast du vollkommen recht. Lieber gescheit umstellen als alte Zöpfe ewig mitzunehmen und vermurkste Lösungen zu bauen nur damit die alte API noch geht.

Die angedachte Änderung klingt sehr sinnvoll aber ich denke diesen beschriebenen Zustand muss man unbedingt vermeiden. Für versierte Nutzer alles kein Problem aber für Neueinsteiger sehr abschreckend. Warten das alle Altbestände raus sind wird wohl kaum gehen da ja sicher von irgend einem Brick/Bricklet immer eine größere Charge da sein wird. Evtl. im Shop die Möglichkeit aktiv Brick/Bricklets mit alter FW zu bestellen mit einem kleinen Rabatt oder sowas. Dann kann sich jeder, unter Wissen des Aufwands/Probleme, aktiv dafür entscheiden und der Standardweg ist einfach neue Hardware mit aktueller Firmware.

Mit rund 1,6% vom Messwert für Sensor und Analog In Bricklet liegst denke ich erstmal nicht schlecht. Die auf der Analog In Bricklet Seite angegebenen Werte entsprechen ungefähr der reinen ADC-Auflösung (Messbereich / 2^12) und sollten daher nicht täuschen. Das wird nie als Messgenauigkeit rauskommen. Noch paar Tipps um trotzdem etwas rauszuholen: - für Spannungsmessung kurze Kabel - weg von Versorgungsleitung - ggf. geschirmt und vedrillt - stabile Spannungsversorgung (ist ja schon in Arbeit )

Ich habe mir das nochmal genauer angeschaut und ein Repository erzeugt: https://github.com/Felmer/TinkerWithG Der aktuelle Download ist hier zu finden: https://github.com/Felmer/TinkerWithG/downloads

Der Upload funktioniert weiterhin nicht. Folgender Fehler wird ausgegeben: Ein Fehler ist aufgetreten! Fehler beim Speichern der Datei, bitte versuchen sie es noch einmal. Habs mittlerweile auch mehrfach probiert. Hab auch schon über Github nachgedacht aber zum Verteilen von fertigem Code wohl eher weniger geeignet?! Noch kurz zum allgemeinen Stand, bin aus Zeitmangel keinen Millimeter vorran gekommen. Ich denke das wird sich sicher aber wieder ändern, hoffentlich zeitnah.

Da gewünscht habe ich den DC Brick hinzugefügt. Mangels Hardware ist diese Klasse aber ungetestet. Die Autogenerierung der Bindings ist auch vorran geschritten aber folgende Teile sind noch zu erledigen: Erzeugung des klassen-spezifischen Message-Handlers Erzeugung Getter/Setter-VIs Parsen der Konfigurationsdateien Ist an dieser Stelle leider noch einiges an Arbeit. Edit: Der Upload des Anhanges wird aktuell mit einem Fehler quittiert. Ich werde es im Tagesverlauf nochmal probieren.

Ja, ist Implementation auf TCP/IP. Kannst dir hierfür die "IP Connection"-Klasse anschauen. Ich bin auch schon eine ganze Ecke vorran gekommen mit der automatischen Generierung der Brick/Bricklet-Klassen. Wenn das mal fertig ist, kann man diese dann aus den existierenden Konfigurationsdateien automatisch generieren, wie alle anderen Bindings.