photron

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.

Brick Viewer 2.0.9 Support Get/SetClockFrequency in LED Strip Bricklet plugin Show "motion detected" in red in Motion Detector Bricklet plugin Support Intertechno and ELRO Home Easy addressing types in Remote Switch Bricklet plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.0.9 Support für Get/SetClockFrequency zum LED Strip Bricklet Plugin hinzugefügt "motion detected" wird im Motion Detector Bricklet Plugin in Rot angezeigt Support für Intertechno und ELRO Home Easy Addressierung zum Remote Switch Bricklet Plugin hinzugefügt Downloads: Windows, Linux, Mac OS X

Callbacks bekommst du nur wenn sich der Wert ändert. Die Period gibt die minimale Zeit zwischen zwei Callbacks an. Eine Period von 500 heißt nicht, dass du immer alle 500ms einen Callback bekommst. Im Zeifelsfall ist die Temperatur einfach recht stabil im Verhältnis zu den anderen Werten. Soll heißen, dass funktioniert alles wie erwartet.

Plugins: LED Strip Bricklet 2.0.1 Add Get/SetClockFrequency function Download: LED Strip Bricklet

Plugins: LED Strip Bricklet 2.0.1 Get/SetClockFrequency Funktion hinzugefügt Download: LED Strip Bricklet

Bindings: C/C++ 2.0.13, C# 2.0.13, Delphi 2.0.15, Java 2.0.14, PHP 2.0.12, Python 2.0.13, Ruby 2.0.13, Shell 2.0.5, VB.NET 2.0.9 Add Get/SetClockFrequency function to LED Strip Bricklet API [all] Fix mixup of Set/GetDateTimeCallbackPeriod and Set/GetMotionCallbackPeriod in GPS Bricklet API [all] Support addressing types of Intertechno and ELRO Home Easy devices in Remote Switch Bricklet API [all] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET

Bindings: C/C++ 2.0.13, C# 2.0.13, Delphi 2.0.15, Java 2.0.14, PHP 2.0.12, Python 2.0.13, Ruby 2.0.13, Shell 2.0.5, VB.NET 2.0.9 Get/SetClockFrequency Funktion zur LED Strip Bricklet API hinzugefügt [alle] Vertauschung von Set/GetDateTimeCallbackPeriod und Set/GetMotionCallbackPeriod in der GPS Bricklet API korrigiert [alle] Adressierungsarten für Intertechno und ELRO Home Easy Geräte zur Remote Switch Bricklet API hinzugefügt [alle] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET