photron

Shell Bindings 2.0.3 mit listen Modus. Dazu hier auch eine Anleitung für NetIO: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html

Shell Bindings 2.0.3 mit listen Modus. Dazu hier auch eine Anleitung für NetIO: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html Loetkolben, mir ist keine Alternative zu NetIO bekannt. Ich muss aber zugeben auch nicht aktiv danach gesucht zu haben

Bindings: C/C++ 2.0.11, C# 2.0.11, Delphi 2.0.13, Java 2.0.12, PHP 2.0.10, Python 2.0.11, Ruby 2.0.11, Shell 2.0.3, VB.NET 2.0.7 Fix signature of edge count functions in IO-16 Bricklet API [all] Add listen mode for handling incoming commands over a TCP/IP connection [shell] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET

Bindings: C/C++ 2.0.11, C# 2.0.11, Delphi 2.0.13, Java 2.0.12, PHP 2.0.10, Python 2.0.11, Ruby 2.0.11, Shell 2.0.3, VB.NET 2.0.7 Signatur der Flankenzählerfunktionen in der IO-16 Bricklet API korrigiert [alle] Listen Modus zur Behandlung eingehender Befehle über eine TCP/IP Verbindung hinzugefügt [shell] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET

Das ist im Prinzip ein bekanntes Problem. Mir war bekannt, dass nach einen Host Standby auf Linux und Mac OS X Bricks an USB nicht mehr richtig kommunizieren. In beiden Fällen hilft ein Neustart des Brick Daemon oder des Bricks selbst. Ich denke im Moment, dass das Problem nicht in brickd selbst liegt. Das ein Neustart von brickd hilft liegt wahrscheinlich daran, dass dann das USB Device neu initialisiert wird durch brickd. Da brickd das Problem aber nicht erkennen kann, kann er auch nicht versuchen dies als Abhilfe zu verwenden. Neu ist, dass das Problem auch Windows betrifft. Ich kann es wie von dir beschreiben auf Windows 8 mit einem Servo Brick und auch mit einem Master Brick reproduzieren. Im Unterschied zu Linux und Mac OS X hilft hier ein Neustart von brickd nicht, sondern nur ein Reset des Bricks hilft. Es ist mir nicht klar wo das Problem genau liegt und wie es zu beheben sei

Ich hatte Java Bindings Versionen 2.0.10 und 2.0.11 unbeabsichtigter Weise mit Java 7 kompiliert, da ich für Tests Java 7 brauchte und dann nicht daran gedacht hatte meine Java Version wieder zurück auf 6 zu setzen. Ich habe gerade Versionen 2.0.10 und 2.0.11 neu mit Java 6 kompiliert und neu hoch geladen. Damit sollte das Problem behoben sein.

CMake kann make und GCC für ARM nicht finden, entweder weil du sie nicht installiert hast, oder weil sie nicht im PATH sind. Siehe folgende Anleitung dazu: http://www.tinkerforge.com/de/doc/Software/Firmwares_And_Plugins.html#compiler-und-tools-installieren

Die Shell Bindings haben einen neuen Befehl gelernt: listen. Dieser öffnet einen TCP/IP Socket auf Port 4217 und nimmt die gleichen Befehle entgegen wie die Shell Bindings selbst auf der Kommandozeile. Hier ein Beispiel: $ tinkerforge listen $ echo "call ambient-light-bricklet f6y get-illuminance" | nc -w1 localhost 4217 illuminance=307 Angehängt eine Shell Bindings Version mit listen Befehl zum Testen. tinkerforge

Nein. Das ganze ist so: Intern wird die Spannung jede Millisekunde gemessen und über 50 Messwerte wird dann der Mittelwert gebildet. Diesen Mittelwert kannst du dann über GetVoltage abfragen oder dir über OnVoltage mitteilen lassen. Über die Periode von OnVoltage kannst du einstellen wie häufig dir neue Werte mitgeteilt werden. Wenn sich der Mittelwert nicht ändert wird OnVoltage nicht aufgerufen. Wenn er sich ändert wird OnVoltage sofort aufgerufen. Dann aber erst frühstens wieder nach der eingestellten Periode. Wenn sich also der Mittelwert ständig ändert bekommst du alle Periode Millisekunden einen Callback. Vor Version 2.0.3 was das Averaging fest auf 50. Dass heißt, der Mittelwert wurde über 50 Messwerte bestimmt und konnte sich daher nur alle 50 msec ändern. Damit wurde dann OnVoltage auch höchstens alle 50 msec aufgerufen, selbst wenn du die Periode von OnVoltage kleiner eingestellt ist. Durch die Mittelwertbildung bedingt werden Änderungen der Spannung im Worst Case erst um Länge der Mittelwertbildung Millisekunden verzögert gemeldet. Mit Version 2.0.3 kann das Averaging jetzt zwischen 1 und 255 Werten eingestellt werden. Dadurch hast du Kontrolle darüber ob du Änderungen ohne Verzögerung haben möchtest, oder glattere Werte. Zu deinem Beispiel, bei einer Periode von 1000 Millisekunden und Averaging von 100 Werten bekommst du im Worst Case eine Spannungsänderung erst nach 1100 Millisekunden durch OnVoltage mitgeteilt. Im Best Case direkt, wenn gerade die Periode angelaufen ist und die Spannungsänderung der 99. der 100 Werte pro Mittelwert ist.

Richtig.

That's just fine. You could use the symbol RANGE_UP_TO_3V instead of the magic value 5, but that's just a matter of taste: $range = $ai->setRange(BrickletAnalogIn::RANGE_UP_TO_3V);

Hast recht, das fehlte. Ist jetzt verbessert

Brick Viewer doesn't know about this new range yet, but you can use your own program to set it.

Bindings: C/C++ 2.0.10, C# 2.0.10, Delphi 2.0.12, Java 2.0.11, PHP 2.0.9, Python 2.0.10, Ruby 2.0.10, Shell 2.0.2, VB.NET 2.0.6 Add edge counters to Industrial Digital In 4, IO-4 and IO-16 Bricklet [all] Make averaging length configurable for Analog In Bricklet [all] Avoid void pointer to function pointer cast warnings with MSVC [C/C++] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET

Bindings: C/C++ 2.0.10, C# 2.0.10, Delphi 2.0.12, Java 2.0.11, PHP 2.0.9, Python 2.0.10, Ruby 2.0.10, Shell 2.0.2, VB.NET 2.0.6 Flankenzähler für Industrial Digital In 4, IO-4 und IO-16 Bricklet hinzugefügt [alle] Länge der Mittelwertberechnung kann beim Analog In Bricklet eingestellt werden [alle] void-Pointer zu Function-Pointer Cast Warnungen unter MSVC vermieden [C/C++] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, Shell, VB.NET

siamon, your post seems incomplete. What trouble do you have?

Industrial Digital In 4 sowie das IO-4 und IO-16 Bricklet haben jetzt Flankenzähler.

Plugins: Industrial Digital In 4 Bricklet 2.0.1, IO-4 Bricklet 2.0.1, IO-16 Bricklet 2.0.3 Flankenzähler für alle Pins hinzugefügt [Digital In 4, IO-4] Flankenzähler für Pin 0 an beiden Ports hinzugefügt [iO-16] Download: Industrial Digital In 4 Bricklet, IO-4 Bricklet, IO-16 Bricklet

Plugins: Industrial Digital In 4 Bricklet 2.0.1, IO-4 Bricklet 2.0.1, IO-16 Bricklet 2.0.3 Add edge counters for all pins [Digital In 4, IO-4] Add edge counter for pin 0 of each port [iO-16] Download: Industrial Digital In 4 Bricklet, IO-4 Bricklet, IO-16 Bricklet

Analog In Bricklet 2.0.3 supports manually selecting the 3.3V range. The auto range selection will not pick it as before for the mentioned reason. Also be aware that in the 3.3V range there is no pull down resistor from the voltage divider anymore. So VIN is really floating by default and the ADC can measure everything up to 3.3V if nothing is connected to VIN. An updated bindings version will be released later today.

Plugins: Analog In Bricklet 2.0.3 Fix jumps in average value calculation due to automatic range switches Add support for manual 3.3V range selection Add support for changing the averaging length Download: Analog In Bricklet

Plugins: Analog In Bricklet 2.0.3 Sprünge in Mittelwertberechnung durch Bereichsumschaltung entfernt 3,3V Messbereich kann manuell gewählt werden Länge der Mittelwertberechnung kann eingestellt werden Download: Analog In Bricklet

Did you restart both Master Bricks after changing the Bricklet configuration. You cannot hotunplug Bricklets. If you hotunplug then the ADC input used to read out the Ambient Light Bricklet is floating now and you can ready any value from a floating input. If you did restart the Bricks, does your program probably handle timeout errors? If you remove an Ambient Light Bricklet and are still requesting data from it you'll get timeout errors that your program needs to handle properly.

Okay, I just did some more tests: First of all: Are you using a Master Brick hardware version 1.x or 2.0? Hardware version 1.x did not auto-calibrate its ADC, hardware version 2.0 does. So if you have only the Analog In Bricklet connected to a Master Brick 1.x and still get an offset from 0V if VIN is shorted to GND then you might need to calibrate its ADC. See the documentation about this. As Loetkolben said, the Bricklet cables can act as antennas and pick up interference. Rule of Thumb: Use the shortest Bricklet cables possible. Also shielded cables are a good idea if you have trouble with interference. I tested other Bricklets with analog sensors and none of them has a similar problem. Only the Analog In Bricklet can be affected by other analog Bricklets. The problem only occurs if the Analog In Bricklet is connected directly behind another analog Bricklet in the ADC channel multiplexing. Rule of Thumb: Connect the Analog In Bricklet to Bricklet port A to avoid this. The technical problem with the Analog In Bricklet is the way its voltage divider is configured. The VIN isn't really floating if nothing is connected. In auto-range mode a weak 120 kOhm pull down is selected. This is not very robust against interference. If you actually drive the VIN pin then it's much less prone to interference. There is a 100 kOhm series resistor between VIN and the ADC input on the Brick. This results in very little current flowing to the ADC. This is probably the cause why your Ambient Light Bricklet can affect the measurement of the Analog In Bricklet. In my tests I can see a change of 5 to 10mV if the Ambient Light Bricklet is in bright light and the Bricklets are connected to the right ports. So there is no general problem. It's only the Analog In Bricklet that's having a slight offset in its measurement under specific conditions. We tested a modified version, that lets more current flow to the ADC pin and this fixed the problems. So the next hardware version of the Analog in Bricklet won't have this problem anymore.

Plugins: Ambient Light Bricklet 2.0.2 Fix jumps in average value calculation due to automatic range switching Download: Ambient Light Bricklet