borg

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.

Oh, das ist ein "Bug". An der Stelle ist das aber natürlich egal, der Wert wird ja nicht benutzt. Wenn ich das nächste mal etwas an den Bindings ändere werde ich das fixen.

Echt komisch, sieht alles so weit gut aus. Als length würde ich 12 erwarten anstatt 14, das sollte aber keine Probleme machen. Ich hab mal das Testprojekt was wir hier verwendet haben hochgeladen: http://download.tinkerforge.com/_stuff/project_uwet.zip Bin gespannt ob das bei dir funktioniert. Wenn ja müsste es irgendeine Compilereinstellung o.ä. in deinem Projekt sein sein die zu den Problem führt. Du kannst auch versuchen die Test.exe direkt auszuführen, das sollte auf jedenfall gehen. Wenn die nicht geht liegt das Problem außerhalb des Compilers, da sie bei uns funktioniert. Als UID haben wir 94ANbHiaKXq genommen das sollte die für deinen Stepper Brick sein.

Mysteriös. Wo steht er denn bei ipcon_add_device (Zeie 339ff)? Kommt er bis zum if(ipcon_answer_sem_wait_timeout(device) != 0) { oder steht er schon beim send(ipcon->s, (const char*) &gsid, sizeof(GetStackID), 0); ? Und kannst du da auch mal die Elemente von GetStackID ausgeben? Um zu gucken ob da alles richtig ist.

Brick Viewer and Brick Daemon for Mac OS X are now online: http://en.blog.tinkerforge.com/

It is fairly simple. We have a Brick Daemon, a Brick Viewer and language bindings. The daemon has a USB connection to the Bricks (and over the Bricks to the Bricklets) and opens a TCP port. The bindings (currently for C/C++, C#, Java, Python) speak over TCP with the Brick Daemon and provide an API to the user (like SetSpeed, GetTemperature, etc). That is in principle all you need to use Bricks and Bricklets (the Brick Daemon and one language binding). Additionally we have the Brick Viewer, that provides a GUI for all of the API for all Bricks/Bricklets. The idea is to use it for testing before you start your own project. A list of devices that we currently have can be found here: http://www.tinkerforge.com/doc/index.html#bricks You can click on the names to get an in depth description.

Sehr unwahrscheinlich das es am Rechner selbst liegt. Wird denn die Funktion ipcon_recv_loop überhaupt aufgerufen? Also wenn du mal ein printf direkt oben in Zeile 38 reinmachst. Ansonsten, gestartet wird die recv loop in Zeile 293: ipcon->handle_recv_loop = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)ipcon_recv_loop, (void*)ipcon, 0, (LPDWORD)&thread_recv_loop_id ); Wird da noch aufgerufen? Wenn nicht, wo bleibt das Programm stehen vorher? Dem Problem sollten wir auf die Spur kommen können, soviel passiert ja gar nicht bis dahin.

Mh, schwer zu sagen. Da im brickv jetzt alles funktioniert, scheint der brickd ja zu laufen. Der brickv nutzt zwar Python, aber die Kommunikation läuft ja über herkömmliche Sockets. Ich würde also ausschließen das die nicht richtig funktionieren. Bleiben nur noch die C Bindings selbst übrig. Kannst du mal den buffer in der ip_connection.c direkt in der recv loop ausgeben (Zeile 61)? Ich würde im Moment davon ausgehen das die Daten dort ankommen (da ich einfach keinen Grund sehe warum es nicht funktionieren sollte), dann aber irgendwo in einer der Semaphoren oder so stecken bleiben. Ich würde erwarten das die Nachricht an ipcon_handle_message übergeben wird, dort wird festgestellt das der Typ TYPE_GET_STACK_ID ist, von da gehts an ipcon_add_device_handler und da wird die sem_answer Semaphore freigegeben. Wenn es geht guck doch mal wo es da stecken bleibt, da es bei uns läuft hab ich da gerade keinen Anhaltspunkt woran es liegen könnte.

They would fit there, but the connectors of the Bricklet cables would collide with the USB connector on a USB cable (about 1mm with the cables we are currently selling).