photron

Wenn du uns sagst wo die sind dann werden sie auch korrigiert. Ich könnte da noch x-mal drüber lesen und meine eigenen Fehler nicht sehen, wie das halt so ist

No, the PHP bindings don't require MySQL. The only requirement is that your PHP has the bcmath extension enabled. It seems to me that there's something wrong with either your PEAR or your PHP installation that leads to those errors about MySQL. Actually the "Ignoring installed package __uri/Tinkerforge" line tells you that the Tinkerforge PEAR package is already installed. At least PEAR thinks so. Try running pear list -c __uri to see what packages are already installed on the __uri channel. The Tinkerforge should be there. Then the PHP examples from the Tinkerforge PHP bindings zip should already work.

Das ist genau die Ecke um die es da gehen wird. Also z.B. ein Bricklet das für Sensoren mit 4..20mA Schnittstelle ausgelegt ist und z.B. eine Art I/O-4 (wobei I und O getrennt sein werden) die für 24V ausgelegt ist. Weitere Details folgen dann in Kürze.

Das LCD hat einen speziellen Zeichensatz: https://github.com/Tinkerforge/lcd-20x4-bricklet/raw/master/datasheets/standard_charset.pdf Für Python gibt es hier ein Beispiel, um Unicode und im speziellen auch Umlaute möglichst gut auf diesen speziellen Zeichensatz abzubilden: http://www.tinkerforge.com/doc/Software/Bricklets/LCD20x4_Bricklet_Python.html#unicode Die unicode_to_ks0066u Funktion wird auch in brickv verwendet. Daher kann brickv Umlaute auf dem LCD anzeigen. Im Moment gibt es diese Beispiel noch nicht für Delphi. Aber es sollte nicht allzu schwer sein dies auch in Delphi zu implementieren.

Gut Idee. Ich werde die Examples dahingehend erweitern.

Hast du den Hinweis am Ende der Installationsanleitung für brickv unter Linux im Zusammenhang mit Debian Wheezy und python-qwt5-qt4 befolgt? http://www.tinkerforge.com/doc/Software/Brickv.html#linux

Hast du den Master Brick am Laptop an USB 3.0 angeschlossen? Damit das funktioniert brauchst du mindestens Brick Daemon 1.0.9 und falls du einen NEC/Renesas USB 3.0 Controller hast musst du mindestens Treiber Version 2.1.16 für diesen Controller installiert haben.

Meinst du die Steckverbindung zwischen Bricklet und Brickletkabel? Typischerweise sitzen die bombenfest.

It's known and by design. Each Brick has a protecting diode in the 5V line feed from USB resulting in a 0.5V drop. To get "better" 5V output at the IO-16 you can use a Step-Down Power Supply.

fimopatassou, ich hab den Hinweis jetzt eingebaut als vorläufige Lösung.

Wie AuronX schon sagt wirkt dein langes Kabel wie eine Antenne und im Zweifelsfall ist der Pull Up im Prozessor nicht stark genug um gegen die Antenne zu wirken. Zur Abhilfe könntest du einen externen Pull Up einbauen, bzw. auf andere für deine Anwendung geeignete Weise dafür sorgen, dass der Eingang nicht floatet. Das nicht Erkanntwerden mit IO-4 Plugin 1.1.1 kann ich hier nicht reproduzieren. Funktioniert hier alles wie erwartet. Bricklets können nicht hotplug-mässig angeschlossen werden. Damit der Brick das Bricklet erkennt muss du erst das Bricklet an den Brick und dann den Brick an den PC anschießen. Hast du da sonst noch was dran? Zum Beispiel dein langes Kabel? Oder funktioniert es auch nicht wenn du nur das IO-4 Bricklet an den DC Brick und den Brick an den PC anschließt ohne sonst noch was dran? Nachtrag: Wird dann nur das IO-4 Bricklet nicht mehr in brickv angezeigt, der DC Brick ist aber noch in brickv da? Oder tauchen beide dann nicht mehr in brickv auf? Wenn beide nicht mehr in brickv auftauchen, ist denn dann der Brick im Gerätemanager noch da, wenn du ihn anschließt?

Ist jetzt korrigiert.

Richtig, im Beispiel hätte wie in den Beispielen für alle anderen Sprachen auch UID = '9qL'; { Change to your UID } statt nur UID = '9qL'; stehen sollen. Ich werde das verbessern.

Plugins: IO-16 Bricklet 1.1.3 Avoid useless I2C reads during monoflop handling Download Plugins: IO-16 Bricklet

Plugins: IO-16 Bricklet 1.1.3 Unnötige I2C Leseoperartion während Monoflopbehandlung vermieden Download Plugins: IO-16 Bricklet

Ah, das war mir nicht bewusst, dass da C# XML Doku geht. Ist auf die TODO Liste gesetzt.

Erstmal wundert es mich noch mehr, dass du angeblich brickd downgraden musst damit es wieder funktioniert. Bist du sicher, dass Master Firmware 1.2.4 (aktuell), IO-4 Firmware 1.1.0 (alt) und brickd 1.0.9 (aktuell) nicht zusammen funktionieren und Interrupt richtig geht? Wenn du deinen Code nicht vorzeigen kannst, kannst du dann mit dem Interrupt Example der IO-4 testen ob das Problem da auch auftritt? Wie ist denn dein Stack aufgebaut, was ist da alles drin? Video wird nicht nötig ein.

Bei mir funktioniert der Interrupt immer in allen meinen Tests. Welche Master Firmware verwendest du? Falls es nicht 1.2.4 ist, dann teste bitte nochmal mit aktueller Master Firmware. Falls das auch nicht hilft muss du mir mal deinen Aufbau genauer beschreiben, am besten plus Beipsielprogramm, dass das Problem demonstriert, da ich es wie gesagt nicht reproduzieren kann. Was meinst du mit BrickD Treiber? Brick Daemon 1.0.9?

Du meinst vorher den Load Button im Flash-Fenster drücken, um die UID zu anzuzeigen und dann diese mit den Viewer-Angaben vergleichen ? Richtig, für Ports die ein Brick hardwäremäßig nicht hat bekommst du eine Fehlermeldung, für Ports an denen kein Bricklet hängt typischerweise eine UID von 1 und für Ports an denen ein Bricklet hängt deren UID. Diese kannst du dann mit der UID in der Device Tabelle vergleichen.

Das stimmt so nicht. Brickv aktiviert den Stepper nicht von sich aus. Aber es zeigt an wenn der Stepper schon aktiviert ist. Dass heißt wenn du in Brickv (oder sonst wie) den Stepper aktivierst, dann einmal Disconnect und wieder Connect klickst, dann wird dir Brickv nach dem Connect anzeigen, dass der Stepper immer noch aktiv ist, denn du hast ihn ja zuvor aktiviert. Das ab- und anwählen des Stepper Tabs geht nicht mit einer De- bzw. Aktivierung des Stepper Bricks einher. Das ist nicht so einfach möglich. Ein Brick kann nicht immer feststellen was an welchem Bricklet Port hängt. Falls ein Bricklet richtig geflasht ist ginge es. Wir haben auf der großen TODO Liste auch ein verbessertes Enumerate, dass Topologie Information mitteilen kann. Für dein spezielles Problem schlage ich folgenden Workaround vor: Du kannst von Bricklet die UID im Flashing Fenster auslesen und so zwischen Port und angeschlossenem Bricklet matchen.

Der Brick, der hat den Prozessor. Das heißt für den Fall, dass sich der Brick selbst aufhängt hilft Monoflop nicht.

OnMonoflopDone wird nur aufgerufen, wenn der Timer des Monoflop auch wirklich abgelaufen ist, der Monoflop also zurückspring. Wenn du den Monoflop für einen Pin immer wieder erneuerst bevor der Timer abgelaufen ist, dann behält dieser Pin seinen Zustand und OnMonoflopDone wird nicht ständig aufgerufen. Erst wenn du aufhörst den Monoflop zu erneuern und der Timer wirklich abläuft springt der Monoflop zurück und OnMonoflopDone wird aufgerufen. Und ja, ein Anwendungsfall ist, dass du einen Pin z.B. auf High setzen willst, aber auch sichergehen willst dass der Pin von selbst auf Low zurück geht wenn z.B. die Chibi Verbinding zum Slave an dem das IO Bricklet hängt abreißt.

Korrigierte Bindings sind verfügbar.

Das Problem lag an einer Race Condition in der add_device Funktion. Das sleep hat die Race Condition aufgehoben. In den aktuellen Bindings ist das Problem korrigiert.

Bindings: C/C++ 1.0.18, C# 1.1.10, Delphi 1.0.2, Java 1.0.16, PHP 1.0.11, Python 1.0.19, Ruby 1.0.8 Plugins: IO-4 Bricklet 1.1.1, IO-16 Bricklet 1.1.2 Brick Viewer 1.1.6 Fix race condition in bindings function add_device Add monoflop functionality to IO-4 and IO-16 Bricklet Display chip temperature in Brick Viewer Download Bindings: C/C++, C#, Delphi, Java, PHP, Python, Ruby Download Plugins: IO-4 Bricklet, IO-16 Bricklet Download Brick Viewer: Windows, Linux, Mac OS X