photron

Die Beispiele arbeiten immer nur mit "LAN" weil es in dem Sinne nur "LAN" (TCP/IP) gibt. Der Brick Daemon kümmert sich um die Umsetzung zwischen TCP/IP und USB. Sprich alle LabVIEW Beispiel verbinden sich standardmäßig zu localhost auf Port 4223. Dort lauscht der Brick Daemon und macht dir die Bricks an USB zugänglich.

Dafür gibt es so direkt keine Funktion. Dein Vorgehen ist aber schon genau das richtige.

Dein Programm wird nicht in einem Terminal, sondern auf dem RED Brick im Hintergrund ausgeführt. Daher bekommst du keine Tastatureingaben. Hier wird beschrieben, wie man in C dennoch an die Tastatureingaben kommt: http://unix.stackexchange.com/questions/94322/is-it-possible-for-a-daemon-i-e-background-process-to-look-for-key-presses-fr Alternativ gibst du deinem Programm ein GUI um so an die Tastatureingaben zu kommen. Ich setze mir mal auf die TODO Liste mir anzuschauen wie viel Aufwand es wäre dem RED Brick beizubringen Tastatureingaben an ein Programm weiter zu leiten.

Es liegt aber nicht das Mini USB Kabel, oder? Sprich der eine Brick funktioniert am gleichen Kabel an dem der andere nicht funktioniert? Wenn das so ist, dann melde dich bitte mit Hinweis auf diesen Thread bei info@tinkerforge.com. Wir tauschen den defekten Master Brick aus.

Das Brick Viewer es "sieht" wird daran liegen, dass Brick Viewer nicht den Interrupt Callback verwendet, sondern pollt. Dennoch darf kein Callback verloren gehen. Wenn du sagst 3mal hat dein Script den Callback nicht erhalten, von wie viel Prozent Verlust reden wir dann hier? Wie viele Interrupts hast du erzeugt? Was passiert, wenn du den Aufbau vereinfachst? Also z.B. die RS485 Extensions aus dem Spiel nimmst und das IO-16 Bricklet direkt an den Master Brick am Raspberry Pi hängst?

Brick Daemon brauchst du, wenn deine Bricks an USB angeschlossen ist. Brick Daemon ist ein Grundbestandteil von Tinkerforge. Daher steht das in der MQTT Anleitung nicht so direkt drin. Ich füge das gleich hinzu. Sorry, dass wir dir da so viele Steine in den Weg gelegt haben mit der groben Anleitung

Okay, dein Python scheint etwas durch einander. pip installiert für Python 3. Dein Standard Python ist aber Python 2. das erklärt das Problem. Teste mal ob du auch pip2 hast, un für Python 2 zu installieren: sudo pip2 install tinkerforge paho-mqtt

Du kannst jetzt also brick-mqtt-proxy.py starten? Das import Problem ist behoben? Gut. Du hast aber auch Brick Daemon installiert?

Auch danach bleibt der "ImportError: No module named paho.mqtt.client" Fehler? Bist du sicher das "sudo pip install tinkerforge paho-mqtt" geklappt hat? Was passiert wenn du Python so startest und dann am interaktiven Modus import paho.mqtt.client eingibst?

Sorry, für die späte Antwort. Hast du mal einen anderen Anschluss für das Temperature Bricklet am Master Brick probiert? Hast du mal ein anderes Bricklet Kabel probiert? Hast du mal versucht das Bricklet neu zu flashen? Dazu steckst du das Bricklet erst an, wenn der Master Brick schon läuft. Dann im Brick Viewer Updates / Flashing Dialog den Brick den Port und das passenden Plugin wählen und dann Save klicken.

188 (dezimal) und BC (hex) ist die gleiche Zahl. Im Beispiel fehlt für das erste Byte der Tag ID ein dechex() Aufruf. Das habe ich gerade behoben. Die PHP Beispiele sind nicht direkt als Webseite gedacht, sondern als Kommandozeilenprogramme. In diesem Fall endet das Programm nicht, sondern fragt durchgehend nach der aktuellen Tag ID. Der Webserver wird dem PHP Script aber nur einige Sekunden Laufzeit zugestehen und es dann abwürgen. Eine einfache Änderung des Beispiels wäre es dispatchCallbacks(5) statt dispatchCallbacks(-1) aufzurufen. Dann wartet das Beispiel maximal 5 Sekunden bevor es sich beendet und du die Ausgabe als Webseite sehen solltest.

Zeigt der Brick Viewer IO-16 Tab Timeouts an, oder steht die Timeout anzeige auf 0?

Du hast paho-mqtt nicht installiert. Hast du folgenden Schritt aus der Anleitung ausgeführt? sudo pip install tinkerforge paho-mqtt

500 heißt Serverfehler. Da muss du mal ins Log deines Webservers schauen, was genau das Problem ist.

Warum versuchst du http://localhost/ExampleConfiguration.php aufzurufen, wenn du in den anderen Screenshots aber ExampleScanForTags.php zeigst? Müsstest du dann nicht eher http://localhost/ExampleScanForTags.php aufrufen?

Das ist leider nicht gut genug dokumentiert. Damit du von normalen Settern den Return Callback musst du folgenden Aufruf vor ipcon.Connect() einfügen: rs.setResponseExpected(Tinkerforge.BrickletRemoteSwitch.FUNCTION_SWITCH_SOCKET_B, true);

Für das "NFC/RFID Bricklet Scan For Tags" Beispiel musst du WebSockets für Brick Daemon aktivieren (hast du schon) und die Tinkerforge.js und ExampleScanForTags.html Datei in den gleichen Ordner kopieren (sonst findet ExampleScanForTags.html die Tinkerforge.js Datei nicht). Wenn du dann "Start Example" klickst siehst du erstmal nichts in der Ausgabe des Beispiels, bis du einen Tag an den Reader hältst. Dein zweiter Screenshot könnte also einen funktionierenden Zustand anzeigen, bei dem du einfach noch keinen Tag an den Reader gehalten hast.

This really depends on your use-case. stepper_enable/disable enables/disables the stepper motor driver circuitry on the Brick. If the driver is disabled then the stepper motor coils are not powered and you can move the stepper motor shaft by hand or by what ever is mounted to it. This might be okay if there is no external force acting on the stepper motor. But if you have some mechanical load on the stepper motor like some kind of pulley system, then you might want to have the stepper motor powered all the time to make it keep its position and stop it from being moved by the force from the pulley system.

The code does more than connect and release. You're calling stepper_disable which disables the stepper motor driver. You should call stepper_destroy instead. The memory leak comes from not calling stepper_destroy. It seems that these destroy calls are missing in all our C/C++ examples. I'm going to fix that now.

The modified version of ip_connection.c I gave you can resolve "localhost" to its IPv6 address, but brickd doesn't bind to an IPv6 address by default. To make ip_connection.c resolve "localhost" to its IPv4 address you need to replace AF_UNSPEC with AF_INET in your ip_connection.c.

Actually, non of these are errors. They are all just deprecation warnings that can be ignored. Anyway, here's a version that has those warnings fixed for you to test. Also the next release of the C/C++ bindings will have those warnings fixed. ip_connection.c

Ein GSM Bricklet steht durchaus auf der Liste der Bricklets die wir irgendwann gerne hätte. Momentan ist da aber nichts in Arbeit, sprich kurzfristig passiert an der Front leider nichts.

Der Schrittmotor mit Getriebe hat einen 8mm Schaft, die Zahnriemenräder haben eine 5mm Bohrung. So direkt passt das also nicht. Du könntest aber die "Achskupplung 5mm / 8mm" und das "Achsreduzierstück 5mm / 3mm" nehmen um den 8mm Schaft auf 5mm zu verjüngen. Alternativ, falls du passendes Werkzeug hast, kannst du die 5mm Bohrung im Zahnriemenrad auch auf 8mm aufbohren.

benoit, please check the black cables that connected the sensor to the PCB. Are they properly seated in the black press fit connector on the PCB? You need the proper soldering equipment to do it. A simple soldering iron won't help you much. How badly is the pin bend? If the pin is only slightly bend you can straighten it again. But you can also ship the Bricklet back to us and we'll replace the connector for you.

Ah! Du musst das Programm noch herunterladen. Das steh in der Anleitung (noch) nicht explizit drin: wget https://raw.githubusercontent.com/Tinkerforge/brick-mqtt-proxy/master/brick-mqtt-proxy.py Ich füge das gleich in die Anleitung mit ein.