photron

Okay, laut lsusb ist der Brick da. Allerdings bekommt brickd Fehler bei der Interaktion mit dem Brick. Bevor brickd irgendetwas mit dem Brick tut resettet es die USB Kommunikation. Das schlägt fehl: 2014-01-25 17:24:26.523655 <E> <usb|usb_stack.c:278> Could not reset USB device (bus: 2, device: 4): LIBUSB_ERROR_NOT_FOUND (-5) Bei einem späten Versuch scheint der Reset zu funktionieren, aber das Auslesen des USB Config Descriptors schlägt fehl. 2014-01-26 12:46:49.676619 <E> <usb|usb.c:462> Could not get product string descriptor for USB device (bus: 2, device: 4): LIBUSB_ERROR_TIMEOUT (-7) Das ist komisch, ist mir beides noch nicht untergekommen. Ich habe gerade auch noch mal Mint 16 32bit in einer VirtualBox VM getestet und keine Probleme mit durchgereichten Bricks. Ich habe gerade kein VMware zur Hand zum Testen. Wie dem auch sei, hier mal eine brickd Version die keinen initialen Reset durchführt. brickd-2.0.10-d1_amd64.deb brickd-2.0.10-d1_i386.deb

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen. Ich meinte, ob zur Laufzeit dem Linux-System über Rechtevergabe an den BrickV der direkte Zugriff an ein bestimmtes USB-Device erlaubt wird. Nein, brickv braucht keine root Rechte. Das läuft anders. Typischerweise hat nur root Zugriff auf die USB Geräte. Daher läuft brickd als root und kann daher auf die USB Geräte zugreifen. brickv kann sich dann zu brickd verbinden und mit den Bricks kommunizieren ohne selbst root Rechte zu brauchen. Sprich, du hast da keine Rechteproblem mit brickv. Ich hoffe Du meinst das Download-Paket von TF, dann ja, es mussten aber noch einige Dependencies für den BrickV via Internet während der Install. nachgeladen werden. Mit den Linux eigenen Begrifflichkeiten bin ich nicht bewandert, ich bin schon froh, dass ich soweit gekommen bin Ja, dass meinte ich. Unser .deb Packet von der Downloadseite installiert brickd und richtet ihn als Service ein, damit er automatisch im Hintergrund mit root Rechten läuft. Ja. Ja, also zumindest über die Toolbar-Leiste des VMWare Players, rechts oben. Dort werden alle relevante HW des Host eingeblendet und lassen sich connecten. Okay, dann ist der Brick nach VMwares Meinung wohl durchgereicht. Dann ist jetzt der nächste Schritt sich anzusehen wie Linux das sieht. Dazu einen Terminal in der VM öffnen und lsusb eingeben und Enter drücken. Das sollte sowas in der Art hier ausgeben: Bus 006 Device 030: ID 16d0:063d GrauTec Bus 006 Device 029: ID 16d0:063d GrauTec Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 003: ID 045e:078c Microsoft Corp. Bus 004 Device 004: ID 046d:c05b Logitech, Inc. M-U0004 810-001317 [b110 Optical USB Mouse] Bus 003 Device 006: ID 16d0:063d GrauTec Die ersten beiden Zeilen sind Bricks, zu erkennen an 16d0:063d. Ob da bei dir dann GrauTec oder MCS steht hängt davon ab wie aktuell, die usb.ids Datei des Linux ist. Wenn bei durchgereichtem Brick lsusb keine Zeile mit 16d0:063d ausgibt, dann erkennt Linux den Brick nicht.

Normalerweise nicht. Ich nehme an du hast brickd über das .deb Packet installiert, dann läuft der als root und sollte keine Probleme haben auf die USB Geräte zuzugreifen. Dass heißt, du hast dabei auch folgende Reihenfolge getestet: VM starten, Brick durchreichen, brickv starten und Connect klicken? Sagt dir das VMware oder hast du das mit lsubs in der VM nachgesehen?

industrial_quad_relay_get_monoflop() erwartet Pointer auf Variablen in die es dann die drei Werte schreiben kann. Hier ein Beispiel für Pin 0: uint16_t value; uint32_t time uint32_t time_remaining; industrial_quad_relay_get_monoflop(&iqr, 0, &value, &time, &time_remaining); printf("value %u, time %u, time_remaining %u\n", value, time, time_remaining);

Hast du den Brick in die VM durchgereicht bevor oder nachdem du in brickv in der VM auf Connect geklickt hast? Falls du den Brick danach durchgereicht hast, dann muss du einmal in brickv Disconnect und dann wieder Connect klicken, um ein Enumerate auszulösen. Wenn du den Brick per USB ansteckst sendet er von sich aus ein Enumerate. Wenn du ihn aber durchreichst ist das zwar für die VM das anstecken eines neuen USB Gerätes, aber nicht für den Brick. Daher hat bei dieser Abfolge brickv den Brick einfach noch nicht gesehen. Falls es dass nicht ist, kann du dir verschiedene Dinge ansehen (alles in einem Terminal): Das brickd Log: less /var/log/brickd.log Möglicherweise ist hier ein Hinweis auf das Problem zu finden. Als nächstes die Liste der USB Geräte: lsusb Hier tauchen Bricks unter der ID 16d0:063d auf. Abhängig davon wie neu deine usb.ids Liste ist wird GrauTech oder MCS als Vendor angegeben. Wenn hier kein solcher Eintrag vorhanden ist, dann hat der Kernel den Brick nicht erkannt. Dann ist da noch das Kernel Log: dmesg Hier solltest du im Normalfall beim Durchreichen am Ende des Logs Meldungen wie diese sehen: [204458.156050] usb 6-3: new full-speed USB device number 28 using ohci_hcd Oder aber Fehlermeldungen des Kernels die dann auch mit "usb" beginnen.

Wie Loetkolben schon richtig sagt kann das EEPROM vom Brick aus beschrieben werden. Der Brick Viewer hat einen Dialog dafür. Da kannst du den Brick, den Bricklet Port an dem dein Bricklet angeschlossen ist und die passende Firmware auswählen und der Brick Viewer schreibt diese dann über den Brick in das EEPROM des Bricklets. Keine zusätzliche Hardware nötig.

Eigentlich wäre es besser gewesen, wenn du einen neuen Thread erstellt hättest, aber nicht so wichtig Zu deiner Frage: Du möchtest also dein eigenes IO-16 Bricklet bauen. Wenn du von ICs sprichst meinst du M24C64 (EEPROM), MCP23017 (I/O Expander) und PCA9306 (I2C Voltage-Level Translator), nehme ich mal an. Wenn du das IO-16 Bricklet nach unserem Schaltplan nachbaust wird jeder Brick es erkennen, wenn es geflasht ist. Du kannst natürlich ein exaktes IO-16 Bricklet nachbauen, aber du musst nicht. Der Knackpunkt ist, dass das EEPROM die I2C Adresse hat, die der Brick erwartet. Das wird aber einfach dadurch sichergestellt, dass du das gleiche EEPROM wie wir verwendest und es auch gleich anschließt. Den Rest der Hardware des Bricklets kannst du ändern, solange du dich an die elektrische Spezifikation des Bricklet-Steckers hältst. Dann musst du aber natürlich auch eine passende Firmware für dein Bricklet schreiben. Die Erkennung läuft so ab: Beim Start versucht der Brick das EEPROM des Bricklets über I2C auszulesen. Die I2C Adresse des EEPROMs ist in unserem System für alle Bricklets gleich, daher können wir sie im Brick fest vorgeben. Wenn der Brick die Firmware des Bricklets erfolgreich vom EEPROM in seinen Flash übertragen hat führt er diese aus, um so deren Funktionalität dem Nutzer zur Verfügung zu stellen. Sprich, wenn deine Hardware die elektrische Schnittstelle eines Bricklets hat und auf dem EEPROM eine Firmware gespeichert ist, die die Software-Schnittstelle eines Bricklets erfüllt, dann wird deine Hardware vom Brick als Bricklet erkennt und auch funktionieren.

Die Beispiele für Callbacks in PHP sehen vernünftig aus, warum wird hier aber trotzdem davon abgeraten ? Wenn das mit Callbacks schlechter funktioniert als "teueres" Polling mit Getter-Funktionen, dann sollte ein Hinweis in die Doku rein "vom Benutzen der Callbacks in PHP ist abzuraten, weil... usw" oder bitte von den PHP Experten genauere Erklärungen, ansonsten wirkt das u.U. hier für Unsicherheiten. Ganz grundsätzlich: Callbacks funktionieren in PHP genauso gut oder schlecht wie in anderen Bindings. Es gibt hier kein Problem oder Nachteil mit Callbacks in PHP! Der Punkt auf den AuronX abzielt und den ich versucht habe darzustellen ist ein anderer: Callbacks sind gut dafür Wertänderungen/Ereignisse mitzubekommen ohne ständig einen Getter dafür aufrufen zu müssen. Das ist vor allem in Programmen nützlich die länger laufen. Genau dies ist aber bei PHP in seiner ursprünglichen Verwendung zur Erzeugung von Websites nicht der Fall. Darauf zielte der Teil ab in dem ich Callbacks für PHP als Website-Generator als eher nicht nützlich erachte. Dies war und ist keine Aussage über Callbacks in PHP in Allgemeinen, sondern nur für diesen speziellen Fall. Die Aussage, dass ich Callbacks für Website-erzeugende Programme nicht als nützlich erachte hängt nicht mit PHP zusammen sondern gilt auch für alle anderen Bindings. Das eigentliche Problem mit Callbacks in PHP ist, dass ich mich als Nutzer der Bindings darum kümmern muss sie zu erhalten. Bei anderen Bindings passiert das automatisch, was Vorteile und auch Nachteile hat. Wenn ich in PHP Callbacks verwenden will muss ich irgendwo in meinem Programm an geeigneter Stelle und zu geeigneter Zeit dispatchCallbacks() aufrufen. Am einfachsten ist dass, wenn man es so macht wie alle PHP Beispiele die Callbacks verwenden. Sie konfigurieren als erstes alles was sie brauchen und rufen dann dispatchCallbacks(-1) auf. Mit -1 aufgerufen bedeutet das: "kümmer dich für immer um eingehende Callbacks und returne niemals". Dieses Muster funktioniert gut, ich muss aber mein Programm darauf hin ausrichten, dass es für immer in dispatchCallbacks(-1) stehen wird und ich dann in den Callbacks arbeiten muss. Wenn ich mein Programm nicht darauf ausrichten kann, aber dennoch Callbacks verwende will, dann muss ich mir Gedanken machen darüber wann und wie ich dispatchCallbacks() aufrufe, um es mit meinem restlichen Programm zu kombinieren. Das kann im Einzelfall kompliziert werden. Daher meine Aussage darüber, dass man sein PHP Programm entweder auf die Verwendung von Callbacks ausrichten sollte, oder wenn das nicht möglich ist, besser keine Callbacks verwenden sollte. Das ist als guter Rat bzw. Best-Practice-Hinweis zu sehen. Ich rate damit niemanden von Callbacks im generellen ab, ich weise aber darauf hin, dass die Verwendung von Callbacks in PHP schwieriger sein kann (aber nicht muss) als mit anderen Bindings.

Nein, das ist nicht nötig. Es funktionier in beiden Weisen. Die IPConnection muss nicht verbunden sein um Device Objecte zu erzeugen.

Das würde ich jetzt nicht so negativ darstellen. Das Problem mit PHP und Callbacks ist, dass PHP (zumindest zum Zeitpunkt der Entwicklung der Bindings) keine Threads kannte. Daher muss das PHP Programm selbst für die Abarbeitung der Callbacks sorgen, indem es die dispatchCallbacks() Methode der IPConnection aufruft. Ob die Verwendung von Callbacks sinnvoll ist hängt natürlich auch davon ab was dein PHP Programm tut. Wenn es eine Webseite erstellt dann sind Callbacks nicht sehr sinnvoll und man fährt besser mit Gettern. Wenn ich aber auf ein Ereignis wie den Druck einen Knopfes am Dual Button Bricklet warten will dann sind Callbacks schon sinnvoll. Dennoch ist die richtige Verwendung von dispatchCallbacks() nicht ganz leicht in größeren Programmen. Was dazu führt, dass man sein Programm am besten entweder vollständig auf Callbacks ausrichtet, oder sie gar nicht benutzt. Mittlerweile kann PHP PThreads nutzen und man könnte Callbacks in PHP wie in den anderen Bindings auch durch einen extra Thread ausliefern lassen. Was jetzt aber bitte nicht als "Es gibt bald PHP Bindings mit Threads" verstanden werden soll . Aber zumindest auf der TODO List steht es sich darüber noch mal Gedanken zu machen. Genau so ist das gedacht. Hast du mit diesem Programm Probleme? Die IPConnection stellt die Verbindung zu einem brickd her, über diese Verbindung kannst du dann alle Bricks und Bricklets erreichen die diesem brickd bekannt sind. Wenn es sich um brickd auf deinem PC handelt, dann sind dass alle Stacks die per USB angeschlossen sind. Wenn du die IPConnection zu einem Stack mit WIFI oder Ethernet Extension verbunden hast, dann kannst du alle Bricks und Bricklets diese Stacks darüber erreichen. Denn auf dem Stack mit WIFI oder Ethernet Extension läuft auch eine Art brickd, der sich um das Verteilen der Nachrichten kümmert. Du brauchst also im Normalfall nur eine IPConnection und kannst diese dann für mehrere Devices verwenden.

Die Varistoren sind nicht geklebt, die halten beim Bestücken durch Gravitation.

gcc -pthread -o Temperaturanzeige.c ip_connection.c bricklet_temperature.c bricklet_ptc.c bricklet_lcd_20x4.c Mit "-o Temperaturanzeige.c" sagst du gcc er soll das Programm nach Temperaturanzeige.c schreiben, statt Temperaturanzeige.c auch mitzukompilieren. Daher auch das "undefined reference to `main'", weil Temperaturanzeige.c nicht mitkompiliert wurde findet gcc keine main() Funktion und beschwert sich. So sollte das funktionieren: gcc -pthread -o Temperaturanzeige Temperaturanzeige.c ip_connection.c bricklet_temperature.c bricklet_ptc.c bricklet_lcd_20x4.c Jetzt wird Temperaturanzeige.c mitkompiliert und das kompilierte Programm in die Datei Temperaturanzeige geschrieben.

Das hört sich an, als ob das Motion Detektor Bricklet nicht mehr richtig geflashed ist. Um das zu beheben musst du das Bricklet neu flashen. Da der Brick aber in diesem Zustand nicht richtig startet muss du das Bricklet hotpluggen, entgegen dem üblichen Vorgaben. Also erst den Brick per USB anschließen und dann erst das Bricklet an den schon laufenden Brick anschließen und über brickv neu flashen. Siehe http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricklets-wird-im-brick-viewer-nicht-angezeigt -> Defektes Plugin

Nein, die Bricks sind selbst USB Geräte und können nicht als USB Host agieren, um andere USB Geräte daran anschließen zu können. Sprich ein Master Brick mit WIFI Extension kann nicht als Brücke zwischen WLAN und einem weiteren USB Gerät genutzt werden.

Da springen mir direkt keine richtig groben Fehler ins Auge. Was mir aber auffällt ist diese Zeile strecke = (zaehler - zwSpeicher1) * (radUmfang / 1000); Wobei zaehler, zwSpeicher1 und radUmfang Integerwerte sind. Dies führt dazu, dass radUmfang / 1000 == 2 ist und nicht 2.184 (bei radUmfang == 2184). Das verfälscht deine Werte etwas. Dann ist da noch das Busy Waiting: while(waitingStartTime + 1000 > System.currentTimeMillis()){} Da könnte man stattdessen Thread.sleep(1000) nehmen. Aber das hat denke ich nichts mit deinem Problem zu tun, außer das Busy Waiting wäre recht ungenau und führt nicht zu 1 Sekunde Wartezeit, was sich auch wieder auf die Genauigkeit deiner Berechnung auswirkt. Ansonsten schlage ich vor, dass du dein Programm und deinen Aufbau auf ein Minimum reduzierst. Also nur Master Brick und Industrial Digital In 4 Bricklet und in deinem Programm nur noch den Flankenzähler abfragst und den Wert umrechnest. Wenn das funktioniert liegt das Problem im entfernten Teil des Aufbaus. Wenn das nicht funktioniert, muss man sich nur noch den minimalen Aufbau genauer ansehen.

Per Bindings fertig Blogeintrag

Perl bindings ready Blog entry

Ich glaube, die Frage, ob das im BrickD oder in einem vorgeschalteten Proxy passiert, ist für den Endbenutzer/Entwickler letztlich egal. Wichtig ist, *wo* das läuft, d.h. würde der vorgeschaltete Proxy dann auch auf dem Stapel laufen oder auf einem zusätzlichen Rechner. Wenn das auch auf dem Stapel ginge, dann wäre es wirklich genial. Das Problem, dass brickd dann aufmal alle Funktionen mit Namen usw. kennen müsste gilt auch für den Stapel. Dann müssten dort auf einmal auch alle Funktionen mit Namen usw. bekannt sein. Diese Information ist dort nicht vorhanden. Diese Informationen stecken nur in den Bindings. So ein Proxy würde also wahrscheinlich nicht auf dem Master Brick selbst laufen, sondern wie die Shell Bindings im Listen-Modus auf einem extra Rechner.

So wie ich das verstehe würde der Web Server im brickd dann aber nur für den initialen Verbindungsaufbau HTTP sprechen, um dann eine WebSocket Verbindung aufzumachen. Sonst könnte er keine HTTP Verarbeitung. Die Abfrage von Bricklets wäre dann erstmal nur über die WebSockets Verbindung möglich. HTTP Abfragen wie z.B. http://server:port/<brickletID>/getTemperature wären dann nicht möglich. Richtig, brickd kann einen WebSocket öffnen, weil er dazu nicht wissen muss welche Bricks und Bricklets es gibt und welche Funktionen sie haben. Denn nach dem HTTP Websocket Handshake würde einfach das normale TCP/IP Protokoll über den WebSocket gesprochen, das brickd jetzt auch schon behandelt. Für RESTartige Dinge die wie http://server:port/<brickletID>/getTemperature müsste brickd aufmal wissen, wie das Paket für getTemperature aussieht. Er muss also die Informationen kennen, die in den Bindings stecken. Das wollen wir vermeiden, brickd soll hier generisch bleiben. Eine RESTartige Schnittstelle würde also eher als extra Proxy realisiert werden, der brickd vorgeschaltet wird. So ein Proxy stellt z.B. der listen Befehl der Shell Bindings dar, der über einen Socket Textbefehle entgegennimmt und dann weiss wie die getTemperature aussieht.

Ich hab das hier mit 5mm Glas und 10x10cm Alufolie unter dem Glas getestet und die Erkennung funktioniert problemlos auch noch 1cm über dem Glas. Denke das sollte auch bei 10mm Glas und auch bei etwas kleineren Elektroden noch gut funktionieren.

Robin, das Verhalten bleibt gleich, wenn du die beiden Bricklets vertauscht? Du hast also nicht einfach ein zweites kaputtes Industrial Quad Relay Bricklet, dass das Problem verursacht? tatzemax, das sind keine einfachen Widerstände, sondern Varistoren, die dem Schutz des Bricklets dienen.

Richtig, der Bootloader ist fest im Mikrocontroller integriert. Allerdings machen nicht wir das, sondern Atmel liefert die Chips schon so aus.

Yes, you can probably do that. It depends on the specific interface of your load cells. The Voltage/Current Bricklet can be used to measure a single voltage and current. For 8 load cells you'd need 8 Voltage/Current Bricklets and two Master Bricks to connect them to your PC. The Industrial Dual 0-20mA Bricklet can be used to read out two sensors with 4-20mA type 2 or 3 interface (IEC 60381-1). For 8 load cells you'd need 4 Industrial Dual 0-20mA Bricklets and one Master Bricks to connect them to your PC. The PTC Bricklet can be used to read out a single Pt100/Pt1000 temperature sensor. If your load cells have a similar resistance interface as a Pt100/Pt1000 sensor then you can probably used it to read out your load cells. For 8 load cells you'd need 8 PTC Bricklets and two Master Bricks to connect them to your PC.

Die Signatur ist so void BrickletIndustrialQuadRelay::setMonoflop(int $selection_mask, int $value_mask, int $time) Das zweite Parameter ist nicht bool, sondern int. Mit der $selection_mask wählst du per Bitmaske aus auf welchen Pins einen Monoflop starten willst. Mit der $value_mask wählst du per Bitmaske per Pin aus ob ein Monoflop auf High oder Low erfolgen soll. setMonoflop(1, true, 1000) ist also eigentlich setMonoflop(0b0001, 0b0001, 1000) wobei PHP diese Binärschreibweise nicht kennt und die hier nur zur Verdeutlichung steht. Das funktioniert also zufällig. Aber setMonoflop(2, true, 1000) ist eigentlich setMonoflop(0b0010, 0b0001, 1000) Also Pin 2 auf Low, die 1 in der $value_mask wird ignoriert. Für Monoflop an Pin 2 auf High muss du also setMonoflop(2, 2, 1000) aufrufen. Nachtrag: Ah, ich sehe die Dokumentation redet da an einer Stelle verwirrender weise von true/false. Ich werde das gleich verbessern.

Nein, kann nur DC, weil kein Gleichrichter drauf ist. Den müsste man extern vorschalten. Ich habe in der Doku jetzt ein DC bei der Eingangsspannung hinzugefügt.