borg

Unortunately we still have 10.6.8 on the Mac we are using for testing. We expect hat the problems have something to do with 10.7, you are not the only one with problems there. I am currently updating our MacBook, i will report back as soon as i know more!

Habs mir gerade kurz angeguckt, das ist leider gar nicht so einfach. Der Timer Counter den wir verwenden um die Schrittgeschwindigkeit zu bestimmen hat eine maximale Laufzeit von unter 2 Sekunden. D.h. ich müsste da anfangen mitzuzählen und nur jedes x-te mal ein Schritt machen etc. Das ist technisch natürlich möglich, kann ich aber nicht mal gerade so auf die Schnelle implementieren. Ich hab es mir aber auf die TODO Liste geschrieben. Ist die Bewegung der Kamera nicht relativ ruckartig bei 1/8 Schritten? Würde es nicht in deinem Fall sowieso mehr Sinn machen da noch eine Untersetzung einzubauen damit die Kamera sich ruckfreier bewegen kann? Langsamer würde sie dadurch dann ganz automatisch werden!

Wenn du schon eine IO4 hast kannst du denke ich auch einen einfachen Spannungsteiler bauen, so wie hier: http://www.mikrocontroller.net/articles/Datei:Pw_st_5-3.png Das zieht dann natürlich ein bisschen mehr Strom.

Ich kenne mich mit VCL leider nicht aus, aber kannst du nicht einfach eine Funktion wie "setLabelText" aus dem Callback heraus aufrufen? Also sowas wie: class Beispiel { public: callback(int16_t position); // Ruft setLabelText(toStr(position)) auf setLabelText(string str) // Setzt Text in label private: VCLLabel label; } Die eigentliche Frage hier ist ob ein Label in VCL Thread safe ist, falls nicht musst du die Position zwischenspeichern und aus dem GUI Thread heraus den Wert setzen!

Ich würde nicht ausschließen das wir sowas mal bieten, aber vermutlich nicht in den nächsten Monaten. Das einzige was mir dazu gerade einfällt ist sowas hier nehmen: http://www.pollin.de/shop/dt/MDY5OTE4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Sensoren_Peltier_Elemente/Kabelfuehler_mit_NTC_Sensor_10_k_2_m.html und mit dem Analog In Bricklet auslesen (da muss dann natürlich noch eine kleine Schaltung zwischen )

Ah, ich meinte nicht die Interrupt Zeit die du extern setzt, die ändert nichts daran wie schnell ich die Temperatur intern auslesen. Das sollte an der Stelle also egal sein. Im gegenteil, um zu testen ob der Fehler noch auftritt macht es wahrscheinlich Sinn die Interrupt Zeit möglichst klein zu machen .

Das kann man so ohne weiteres leider nicht beantworten, das ist von vielen Faktoren abhängig. Besonders bei den Bricklets die I2C zur Kommunikation nutzen (das sind im Moment die LCD Bricklets, Temperatrure Bricklet, Temperature-IR Bricklet und IO16) würde ich allerdings 2m schon als definitives Maximum ansehen.

OK, da bleibt dann als Fehlerursache wohl nur die Länge des I2C Busses über. Der Temperatursensor auf dem Temperature Bricklet wird über I2C ausgelesen (die anderen von dir verwendeten Bricklets benutzen kein I2C, daher der Fehler nur beim Temperature Bricklet). Die Länge des I2C Busses setzt sich zusammen aus der Summe alle angeschlossenen Bricklet Kabel. Dazu fallen mir mehrere Ideen ein: [*]Kürzere Kabel verwenden (geht wahrscheinlich nicht) [*]Das Temperature Bricklet mit einer geringeren Frequenz auslesen, die Temperatur ändert sich ja nicht jede ms, da muss also nicht unbedingt die volle Geschwindigkeit genutzt werden [*]Die Temperatur immer mehrfach auslesen und Ausreißer aussortieren Ich hab mal auf die Schnelle eine Firmware gemacht welche die Temperatur mit 100khz statt 400khz ausliest: http://download.tinkerforge.com/_stuff/temperature-bricklet-100khz.bin Das könnte die Probleme schon beseitigen, ich tendiere aber gerade dazu auf dauer Möglichkeit 3 zu implementieren. Das muss ich dann aber vernünftig testen damit ich nicht mehr Fehler reinbaue als ich fixe . Gucke ich mir dann am Dienstag oder Mittwoch an.

Das geht mit der IO16 leider definitiv nicht. Auf der IO16 ist ja ein I2C Port Expander drauf, d.h. jeder Befehl muss erst per I2C übertragen werden. Damit sind solche Frequenzen leider nicht zu erreichen. Mit der IO4 sollte eine Änderung pro ms möglich sein (mehr ist mit USB nicht drin). Das reicht aber auch nicht für 256 Zustandsänderungen in 10ms.

Unfortunately there is no single protocol that is spoken over RS485 or RS232. So there is no way to use a network out of Brick stacks together with other RS485 devices. It would be possible to write a special RS485 mode that makes it possible to speak to other RS485 devices, but i have no idea if thats worth the effort.

Die dll die bei den C# Bindings dabei sind C# dlls, keine C dlls. Ich bin mir nicht sicher wie einfach das ist die aus Delphi auszurufen. Ich bin mir noch nicht mal sicher ob das überhaupt möglich ist. Eine C dll könnte man aber aus den C Bindings erzeugen. Einen Generator direkt für Delphi zu schreiben ist allerdings vermutlich trotzdem weniger Aufwand als einen Wrapper für eine C dll zu schreiben! Für ersteres sind ja schließlich schon alle Informationen maschinenlesbar vorhanden, für letzteres müsste man sich alles mit viel Zeitaufwand zusammensuchen und dann auch noch bei jedem neuen Produkt und jeder API Änderung updaten.

Die Sensoren über sehr lange Kabel direkt zu verlegen würde ich nicht empfehlen. Das kann evtl funktionieren solange keine Störungen da sind, aber da gibt es keine Garantien. Die 2m Kabel die wir verkaufen würde ich als Maximallänge empfehlen für die meisten Bricklets. Anstatt direkt die Kabel der Sensoren zu verlegen bietet sich vielleicht die RS485 Extension an: http://www.tinkerforge.com/doc/Hardware/Master_Extensions/RS485_Extension.html RS485 wird für gewöhnlich in professioneller Hausautomatisierung verwendet, das kann dann für deinen Anwendungsfall also nicht ganz falsch sein . Du würdest dann also für jeden Knoten ein Master Brick eine RS485 Extension und entsprechende Sensor Bricklets benötigen. Ich bin schon seit längeren dabei die Software für die RS485 Extension fertig zu stellen, ich hoffe sie in der nächsten Woche fertig bekomme! Sobald die Software da ist gibt es die Extension dann auch zu kaufen, die Hardware haben wir schon hier liegen in größerer Anzahl.

Die Limitierung entsteht durch USB. Eine Nachricht die einmal durch das System geht: User Programm -> Bindings (Socket) -> Brick Daemon -> USB -> Microcontroller -> Nachricht bearbeiten -> USB -> Brick Daemon -> Bindings -> User Programm benötigt ca. 1ms (dabei ist USB der begrenzende Faktor!). Sprich, die Messwerte des Analog In Bricklets können ca. 1000x pro Sekunde ausgelesen werden und das IO4 könnte eine Frequenz von 500hz messen (500x Low/500x High pro Sekunde).

Die Schnittstelle ist eine TCP/IP Verbindung! Ansonsten wäre es nicht möglich den Brick Daemon auf einem anderen Rechner als das Steuerprogramm zu haben (nur dadurch ist auch z.B. eine Steuerung vom Handy aus möglich). Die Bindings selber werden automatisch generiert aus ganz vielen Config Dateien für die einzelnen Produkte. Eine kurze Abhandlung darüber wie dies funktioniert und wie man eigene Bindings erstellen kann hab ich schonmal hier beschrieben: http://www.tinkerunity.org/wiki/index.php/BindingsErstellen Falls du oder jemand anderes aus dem Delphi Forum sich daran versuchen will stehe ich jederzeit für Fragen bereit!

Aha! Das ist ja interessant. Vielleicht ist es dann doch ein Software Fehler. Ich werde das mal am Dienstag genauso nachstellen und die ganze Software im Debug Modus laufen lassen. Ich bin gespannt. Grundsätzlich gibt es keinen Grund warum das nicht gehen sollte, also gibt es da auch einen Fix falls es an der Software liegt! Erstmal vielen Dank für deine ganzen Mühen, es ist leider immer viel Aufwand bis man solche Bugs findet die mit so vielen Elementen gleichzeitig zu tun haben.

Ich könnte mir vorstellen das eine gewissen Gefahr durch Eisbildung an den Leiterplatten besteht. Wenn es dort langfristig bleiben soll würde ich versuchen die Platinen gut einzuwickeln, so dass es keine Kurzschlüsse geben kann wenn kurzzeitig Eis auftaut weil die Kühlschranktür auf ist (das gilt natürlich vor allem für das Eisfach).

"Distance 16"? Du meinst "Distance IR Bricklet 1.0"? Das kannst du doch genauso parsen. Alles nach der ersten Leerstelle von rechts ist die Version, alles vor der zweiten Leerstelle von links ist der Name und das was überbleibt ist der Typ.

Ah, verstehe. Mhhh. Also grundsätzlich solltest du es folgendermaßen Parsen können (Pseudocode): liste = name.split(" ") version = liste.last(); liste.remove_last() type = liste.last(); liste.remove_last() name = liste.join() Sprich: Am Ende steht der Name, davor kommt der Typ (mit Leerstelle getrennt), dann kommt der Name (zwischen Typ und Name auch mit Leerstelle getrennt, aber der Name selber kann Leerstellen enthalten). Aber: An der Stelle gibt es folgendes zu beachten: Die Versionsnummer ändert sich nur wenn die Hardware inkompatibel geworden ist. D.h. auch bei den ganzen neuen 1.1 Hardwareversion wird dort 1.0 stehen. D.h. du kannst damit nicht herausfinden ob die Platinen glänzend oder Matt sind (was der Unterschied zwischen Stepper Brick 1.1 und 1.0 ist). Ich hoffe das macht irgendwie Sinn. Wir wollen eigentlich nicht 1000 unterschiedliche Firmwares machen für Hardware die die gleiche Schaltung hat.

Das ist komisch. Wenn du einen anderen Master da hast probier den doch mal bitte. Sonst würde das ja bedeuten, dass der Temperatur-Mess-IC auf dem Temperature Bricklet einen defekt hat (wenn er nicht richtig angelötet wäre o.ä. hättest du definitiv eine höhere Fehlerquote). Hast du denn ein größeres System am laufen (zum testen jetzt)? Wenn ja probier doch mal eine Zeit lang nur den Master mit einem Temperature Bricklet laufen zu lassen! Vielleicht hat es ja mit der Kombination von irgendwas zu tun.

Ha, an sowas hatten wir beim ersten Design der Hardware in der Tat schon gedacht. Es gibt im Stack einen sync Pin (siehe Schaltplan). Damit wäre es in Theorie möglich genau das zu machen was du vorgeschlagen hast. Was ich mir da vorstelle ist eine Methode "trigger()" mit der man diesen Pin triggert. Dazu müsste es dann bei jedem Brick eine Methode "setTriggerType" geben bei der man setzen kann was getriggert wird damit (z.B. step() beim Stepper Brick). Ich schreib es mal auf meine TODO Liste, komme aber vermutlich frühestens Ende des Monats dazu das zu implementieren.

Ich kann das Problem bei mir nicht erzeugen. Hab es über Nacht laufen lassen (~6 Stunden) sowohl mit einem 2m als auch mit einem 15cm Kabel. Das erste was ich dann jetzt probieren würde ist ein kürzeres Kabel. Um zu gucken ob es am langen Kabel liegt.

So, ich hab mal alles an Messgeräten was wir hier haben angeschlossen und rumprobiert. Grundsätzlich ist es so, dass sich der Strom im Durchschnitt nicht besonders ändert zwischen halten, frei laufen und unter Last. Ich gehe davon aus dass dein Messgerät unterschiedliche Werte anzeigt weil der Stepper Brick unterschiedlich chopped (mit und ohne Last etc). Kannst du vielleicht unterschiedliche "Mess-Modi" einstellen? Wegen den weitläufigen Werten: Was du da siehst ist auch das Chopping, Der Schrittmotor wird angetrieben indem er immer abwechselnd volle Leistung/0A bekommt. Ich hab mal eine neue Firmware hochgeladen: http://download.tinkerforge.com/firmwares/bricks/stepper/ (1.1.3) Der Stromverbrauch wird jetzt über ein kleines Integral berechnet, so wie es jetzt ist stimmt der Wert zu jeder Zeit mit dem Messgerät überein was ich hier hab (+-15mA). Ich denke das ist erheblich sinnvoller als diskrete Werte zurück zu geben, wie wir es vorher hatten. Damit man die auswerten kann braucht man vermutlich zuviel Kenntnis von dem Schrittmotor Treiber IC den wir verwenden. Wenn es geht probier doch mal die neue Firmware aus und sag Bescheid ob die Werte eher so sind wie du dir vorgestellt hast.

Ich konnte das Problem hier bisher noch nicht erzeugen, auch nicht mit einem 2m Kabel.

Oh, das ist komisch. Wir schicken ja mit CRC und überprüfen die auch. Ist es für dich möglich zu testen ob dieses Problem auch ohne Chibi auftritt? Vor allem die gleiche Bricklet-Kabellänge verwenden! Bei Messungen alle 10 Sekunden ist das eine Fehlerrate von ~0,5% wenn ich mich nicht verrechnet hab. Das so oft ein Fehler auftreten soll der durch die CRC Prüfung rutscht kann ich mir gar nicht vorstellen. Welche Version haben deine Master denn? Wir haben in letzter Zeit viel am Chibi Code gearbeitet, die neueste Version ist 1.1.7: http://download.tinkerforge.com/firmwares/bricks/master/ Ich werde das hier mal nachstellen und über Nacht laufen lassen, mal gucken was dabei rum kommt.

Die ganzen Bindings sind komplett autogeneriert und die Konfigurationsdateien wo die Informationen für die Generierung herstammen findest du hier: https://github.com/Tinkerforge/generators/tree/master/configs für den Stepper Brick z.B. hier: https://github.com/Tinkerforge/generators/blob/master/configs/brick_stepper_config.py Mhhh, das ist im Moment leider nicht möglich. Die Informationen sind auf dem Master Brick alleine leider auch nicht alle vorhanden. Der Master könnte einer Stack ID den Platz in der Platine zuweisen (z.B. dritte Platine von unten). Alle Bricks könnten einer Stack ID von einem Bricklet den Port zuweisen. Stellt sich natürlich die Frage wie man dafür eine vernünftige API macht, muss ich mal drüber nachdenken. Kurz zur Erklärung: Der Master enumeriert sich erst selbst durch (seine Bricklets). Dann enumeriert er alle Stack Teilnehmer durch (und übergibt als startende Stack ID die momentan höchste Stack ID). Dann enumeriert er alle Extension Teilnehmer durch. Der Master der Extension seinen Stack schon enumeriert und es wird nur noch ein Offset in der ID übertragen. Wenn nun eine Nachricht mit Stack ID x ankommt, weiß der Master der per USB angeschlossen ist genau wo die hin muss (z.B an die Extension oder an den Stack Teilnehmer Nummer y). Er weiß aber nicht was es für ein Typ ist oder an welchem Port ein Bricklet sitzt o.ä. Da haben wir elektronisch keinen "Detection Pin" o.ä., das einzige was du machen kannst ist GetVoltage auf dem Master aufrufen. Wenn die Spannung ungleich 0 ist, ist eine Step-Down Powersupply da.