photron

Wir planen dazu folgende Erweiterungen: Kamerasteuerung (auslösen/fokussieren) ist mittel Industrial Quad Relay vorgesehen. Unsere Kamera hier hat für den kabelgebundenen Auslöser einen 2,5mm Standard Stereoklinken-Anschluss bei dem man einfach nur 2 Kontakte kurzschließen muss zum auslösen/fokussieren. Was wird dann auch die dazugehörige Software können. Zum Beispiel X Schritte fahren, auslösen, Y Sekunden warten und dann wieder X Schritte fahren usw. Endschalter für automatische Kalibrierung der möglichen Fahrstrecke. Ohne Endschalter muss beim Start einmal manuell die möglichen Fahrstrecke kalibriert werden.

Definitiv nur auf einer Seite die Abschirmung auf Masse legen, nicht auf beiden Seite. Vorzugsweise an der Bricklet Seite die Abschirmung auf Masse legen.

Okay, dann scheint da wohl der I2C Port Expander auf dem Bricklet ein Problem zu haben. Melde dich mal mit deiner Bestellnummer bei info@tinkerforge.com

Du könntest ein altes geschirmtes Ethernet oder USB Kabel dafür opfern und damit dein bisheriges Kabel ersetzen.

Die 3V Angabe im Shop ist leider falsch, sorry. Wir verkaufen die Variante mit Status LED, für die die Mindest-Eingangsspannung bei 4V liegt. Ich habe die Angabe im Shop korrigiert. Daher solltest du die IO-16 im 5V Modus verwenden, um auf der sicheren Seite zu sein.

ceraner, was ist das andere funktionierende Bricklet, das du hast? Funktionieren am LCD Bricklet die Knöpfe, oder tun's die auch nicht?

Die Tags die wir verkaufen sind alle vom Typ "NFC Forum Type 2". Bei diesem Typ sind Page 0-1 nur lesbar und in Page 3-4 stehen Lockbits die man nicht einfach so überschreiben sollte: http://www.tinkerforge.com/de/doc/Hardware/Bricklets/NFC_RFID.html#page-groszen-und-andere-dinge-die-man-wissen-sollte Da könnte brickv schlauer sein und die Start Page auf 5 setzen. Wenn du versucht Page 0-3 zu schreiben solltest du als Fehler "Could not write page 0" in Textfeld stehen. Das ist leider in grau geschrieben und daher nicht unbedingt sofort erkenntlich. Wenn du das mit Page 5-8 testest wird es gehen. Wenn du auf den Tag Text schreiben willst dann muss du dir überlegen in welchem Encoding. Die Tags speichern einfach nur Bytes, was diese Bytes bedeuten ist deine Sache. Der String "tag=color|content=red" (ohne Anführungszeichen) in ASCII encodet und hexadezimal dargestellt: 0x74 0x61 0x67 0x3d 0x63 0x6f 0x6c 0x6f 0x72 0x7c 0x63 0x6f 0x6e 0x74 0x65 0x6e 0x74 0x3d 0x72 0x65 0x64 Diese Byte Folge kannst du auf den Tag schreiben.

Ah, sorry, mein Fehler. Da waren noch zwei Bugs drin. Ich denke du hast schon alles richtig gemacht Hier noch eine Version zum testen, mit der sollte es jetzt endlich klappen. tinkerforge_delphi_bindings_2_1_2_eef9bdd8d1fcf525095bf3dfa2de32d8c14db322.zip

Hast den den Host auch entsprechend angegeben? Standardmäßig wird in den Beispielen immer localhost (127.0.0.1) verwendet. Die Beispiele verbinden sich also immer zu brickd auf dem lokalen Rechner und haben damit Zugriff auf die lokal per USB angeschlossenen Bricks. Wenn du das Beispiel also mit localhost auf Windows ausführst und der Master Brick auch an diesem Rechner angeschlossen ist dann klappt die Kommunikation. Wenn du das Beispiel aber mit localhost auf Mac OS X ausführst, dann muss der Master Brick auch am Mac angeschlossen sein und dort brickd laufen. Oder du muss im Beispiel die Host Einstellung auf die IP Adresse des Windows PCs ändern, um die dort angeschlossenen Bricks zu erreichen.

Hast du in Zeile 21 des ExampleStackStatus Beispiels die UID deines Master Bricks eingetragen: UID = 'ap8MjSchCcU'; { Change to your UID }

Nic, danke für den Test. In der angehängten Version wird jetzt wieder der vorherige Code für Windows verwendet und der neue Code nur noch für nicht-Windows. whes, das 'Deklaration suchen' klappt hier bein manchen Funktionen, bei machen passiert nichts und manchmal kommt eine Fehlermeldung über fehlende Dateien. Etwas komisch, aber auch nicht so wichtig. Liegt wahrscheinlich an meiner Installation hier. tinkerforge_delphi_bindings_2_1_2_7d2e81f35aa7502fa2e6ed6fd47651cc373674ac.zip

remotecontrol, du verstehst das richtig.

Hier die nächste Version zum testen. Diese verwendet jetzt getaddrinfo statt gethostbyname. tinkerforge_delphi_bindings_2_1_2_3e2a3debec6336db653a4f367e9a0b7bea21e433.zip

Hier unter Delphi XE6 kommt gethostbyname aus Posix.NetDB für OSX32. Mal sehen was ich da alternativ für XE3 nehmen kann, wenn gethostbyname da wirklich fehlt. Woher weißt du welche Funktionen in welchen Units sind? Aus der Dokumentation, oder gibts da eine Möglichkeit, dass die IDE mir für jede Unit, die eingebunden wird, das anzeigen kann? Für die Posix Module kann ich nur raten/annehmen welche Funktionen diese anbieten.

Das muss einfach 6V lauten. Ist jetzt korrigiert. Danke für den Hinweis.

Okay, hier eine erste Version zum testen. tinkerforge_delphi_bindings_2_1_2_40737439d7c1882d1395ec4a006bdceccd660fe4.zip

Richtig, die bis zu 27V, die du an der Step-Down Power Supply einspeist, werden über den Stack übertragen. Der Stepper Brick nutzt diese dann für die Versorgung des Schrittmotors, wenn an seinem eigenen schwarzen Stecker keine Spannung anliegt.

Eigentlich sollte sich brickv auf 1024x768 noch normal bedienen lassen. Zumindest war das mal das Ziel, möglicherweise müssen wir das mal nachkontrollieren, ob das noch alles hinkommt. Die Knöpf auf dem Setup Tab nach oben zu verlegen ist dann ja keine allgemeine Abhilfe. Wenn das brickv Fenster zu hoch ist, dann kommst du ja auch auf anderen Tabs nicht unbedingt an alle Bedienelemente. Als Workaround kannst du einfach den Update Dialog schon aufrufen bevor du die Verbindung zum Stack herstellst. Dann sollte das Fenster noch klein genug sein, oder?

Die API des NFC Chips auf dem Bricket ist so, dass man bei der Anfrage ob ein Tag in der Nähe ist angeben muss mit welchem Protokoll der NFC Chip nach Tags suchen soll. Die verschiedene Tags haben verschiedene Protokolle. Dein Smartphone geht einfach alle Protokolle zyklisch durch. Genau das kannst du auch mit dem Bricklet tun. Dies wird z.B. in den Beispielen des NFC/RFID Bricklet demonstriert. Du hast recht, tag_type ist nicht ausreichend dokumentiert. Das werde ich verbessern. Fürs erste: Mifare Classic = 0 NFC Forum Type 1 = 1 NFC Forum Type 2 = 2

I released 2.0.2 today, see the announcements thread. You pointed out a missing feature that was easy to add, so I added it. Changing the changelog format is not that easy, so that won't happen today

Piezo Speaker Bricklet Plugin 2.0.2 now treats beep() with a duration of 0 as "stop current beep" and beep() with a duration of 4294967295 (UINT32_MAX) as "beep forever".

Plugin: Piezo Speaker Bricklet 2.0.2 Duration 0 stops beep, duration 4294967295 (UINT32_MAX) results in an infinite beep Download: Piezo Speaker Bricklet

Plugin: Piezo Speaker Bricklet 2.0.2 Duration 0 stoppt den Piepton, Duration 4294967295 (UINT32_MAX) erzeugt einen unendlich langen Piepton Download: Piezo Speaker Bricklet

Die Demo Anwendung für die Wetterstation ist in Python geschrieben, nicht in C. Da gibt es nichts zu kompilieren. Einfach demo.py mit Python aus einem Terminal heraus ausführen: python demo.py

... CONTINUE. Irgendwie habe ich mich beim Schreiben verhaspelt und einen halbfertigen Beitrag gepostet. Also weiter mit Problem 2). Mittels einer Queued-Signal-Slot Verbindung kann man aus jedem Thread heraus eine Funktion so aufrufen, dass sie mit dem GUI arbeiten darf. Dazu hier ein Beispiel Programm: mainwindow.h: #ifndef MAINWINDOW_H #define MAINWINDOW_H #include <QtGui/QMainWindow> #include <QtGui/QLabel> #include "ip_connection.h" #include "bricklet_temperature.h" #include "bricklet_segment_display_4x7.h" class MainWindow : public QMainWindow { Q_OBJECT public: MainWindow(QWidget *parent = 0); signals: void temperatureChanged(int temperature); private slots: void displayTemperature(int temperature); private: static void temperatureCallback(int16_t temperature, void *user_data); IPConnection ipcon; Temperature temp; SegmentDisplay4x7 sd4x7; QLabel *label; }; #endif // MAINWINDOW_H mainwindow.cpp: #include "mainwindow.h" static const uint8_t digits[] = { 0x3f, 0x06, 0x5b, 0x4f, 0x66, 0x6d, 0x7d, 0x07, 0x7f, 0x6f, 0x77, 0x7c, 0x39, 0x5e, 0x79, 0x71, 0x63}; // 0~9,A,b,C,d,E,F,° MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) { label = new QLabel(this); QObject::connect(this, SIGNAL(temperatureChanged(int)), this, SLOT(displayTemperature(int)), Qt::QueuedConnection); ipcon_create(&ipcon); temperature_create(&temp, "dX3", &ipcon); segment_display_4x7_create(&sd4x7, "iX8", &ipcon); ipcon_connect(&ipcon, "localhost", 4223); temperature_set_temperature_callback_period(&temp, 1000); temperature_register_callback(&temp, TEMPERATURE_CALLBACK_TEMPERATURE, (void *)MainWindow::temperatureCallback, this); int16_t temperature = 0; temperature_get_temperature(&temp, &temperature); displayTemperature(temperature); } void MainWindow::displayTemperature(int temperature) { temperature = temperature / 100; uint8_t segments[4] = { digits[temperature / 10], digits[temperature % 10], digits[16], digits[12] }; segment_display_4x7_set_segments(&sd4x7, segments, 7, false); label->setText(QString::number(temperature) + " deg C"); } void MainWindow::temperatureCallback(int16_t temperature, void *user_data) { MainWindow *that = (MainWindow *)user_data; emit that->temperatureChanged(temperature); } Die MainWindow Klasse hat ein temperatureChanged Signal und einen displayTemperature Slot. Diese beiden werden dann Queued verbunden. Dadurch kann die temperatureCallback Funktion dann die displayTemperature Funktion so aufrufen, dass die mit dem GUI arbeiten darf und die Temperatur in ein QLabel schreiben kann. Das sind jetzt möglicherweise ein paar viele Qt Konzepte und Details auf einmal. Wenn du noch Fragen hast, immer raus damit