photron

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

Zuerst solltest du die Signatur der cb_temperature Funktion korrigieren. Sie muss so sein: void cb_temperature(int16_t temperature, void *user_data) Dann brauchst du in der Callback Funktion die Temperatur auch nicht mehr zu erfragen, denn der Callback liefert sie dir. Dann solltest du cb_temperature nicht mehr aus on_verticalSliderlicht_actionTriggered heraus aufrufen. Wenn du hier die Temperatur abfragen und anzeigen solltest du dafür eine eigene Funktion erstellen die die Temperatur abfragt und anzeigt, anstatt die Callback Funktion dazu zu verwenden. Wenn dann die Callback Funktion so ist wie sie eigentlich sein sollte, dann kann es ans eigentliche Problem gehen, die Temperatur auf einem QLabel anzuzeigen. Dazu sind zwei Probleme zu lösen. 1) Die cb_temperature Funktion muss auf das MainWindow zugreifen können. 2) Die cb_temperature Funktion wird aus einem Thread aufgerufen. Qt GUI Elemente dürfen aber nicht aus Threads heraus benutzt werden. Das lässt sich aber alles lösen. Für Problem 1) kann das user_data Parameter der cb_temperature Funktion benutzt werden. du übergibst als letztes Parameter this an die temperature_register_callback Funktion. Dann bekommt die cb_temperature Funktion diese als user_data Parameter übergeben: void cb_temperature(int16_t temperature, void *user_data) { MainWindow *that = (MainWindow *)user_data; // ... } // ... temperature_register_callback(&t,TEMPERATURE_CALLBACK_TEMPERATURE,(void*)cb_temperature,this); TO BE CONTINUED...

Schaltfrequenzen im kHz Bereich, kannst du mit unserem KS33 SSR für DC 50V/80A nicht erreichen. Das hat eine maximale Einschaltzeit von 1ms und Ausschaltzeit von 0,5ms. Dadurch könnte es theoretisch mit maximal 666Hz geschaltete werden. Praktisch sieht das anders aus. Wir haben es mit 400Hz bei 10A Last getestet und die Hitzeentwicklung ist so enorm, dass wir den Test nach einigen Sekunden abgebrochen haben. Wir haben dann den Hersteller gefragt und der rät dazu 30Hz nicht zu überschreiten. Unabhängig von den Einschränkungen durch das eingesetzte SSR wirst du Schaltfrequenzen im kHz Bereich nicht erreichen können, weil du dem Bricklet nur 1000 Nachrichten pro Sekunde schicken kannst.

Brick Viewer 2.1.2 Add support for Color, NFC/RFID and Solid State Relay Bricklet Rename main.exe to brickv.exe on Windows Make rainbow work better on small LED counts and add moving-dot mode to LED Strip Bricklet plugin Allow double click anywhere in a device tree row to jump to the corresponding tab Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.1.4, C# 2.1.2, Delphi/Lazarus 2.1.2, Java 2.1.2, JavaScript 2.0.2, LabVIEW 2.1.2, Mathematica 2.1.2, MATLAB/Octave 2.0.2, Perl 2.1.2, PHP 2.1.2, Python 2.1.2, Ruby 2.1.2, Shell 2.1.2, Visual Basic .NET 2.1.2 Add support for Color, NFC/RFID and Solid State Relay Bricklet [all] Rename bindings/ folder to source/ in ZIP file [C/C++, Delphi] Replace System.console() usage with an Eclipse compatible pattern in examples [Java] Move NPM package into nodejs/ folder of ZIP file [JavaScript] Add main Tinkerforge.js script to simplify direct usage of the Node.js source code [JavaScript] Only use MSG_NOSIGNAL if it's really defined [Perl] Remove CPAN package from ZIP file, include relevant files into the source/ folder [Perl] Get rid of the egg and easy_install, use setuptools directly or pip instead [Python] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, Visual Basic .NET

Brick Viewer 2.1.2 Support für Color, NFC/RFID and Solid State Relay Bricklet hinzugefügt main.exe in brickv.exe umbenannt auf Windows Regenbogen-Modus für das LED Strip Bricklet funktioniert besser bei wenigen LEDs und Moving-Dot-Modus hinzugefügt Doppelklick irgendwo in einer Zeile Der Device-Tabelle springt zum entsprechenden Tab Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.1.4, C# 2.1.2, Delphi/Lazarus 2.1.2, Java 2.1.2, JavaScript 2.0.2, LabVIEW 2.1.2, Mathematica 2.1.2, MATLAB/Octave 2.0.2, Perl 2.1.2, PHP 2.1.2, Python 2.1.2, Ruby 2.1.2, Shell 2.1.2, Visual Basic .NET 2.1.2 Support für Color, NFC/RFID und Solid State Relay Bricklet hinzugefügt [alle] bindings/ Ordner in der ZIP Datei in source/ umbenannt [C/C++, Delphi] System.console() Aufruf in Beispielen mit einem zu Eclipse kompatiblen Aufruf ersetzt [Java] NPM Package in den nodejs/ Ordner der ZIP Datei verschoben [JavaScript] Tinkerforge.js Script zur einfacheren direkten Nutzung des Quelltexts der Node.js Bindings hinzugefügt [JavaScript] MSG_NOSIGNAL wird nur noch dann verwenden wenn es auch definiert ist [Perl] CPAN Package aus der ZIP Datei entfernt, stattdessen Makefile.PL im source/ Ordner [Perl] Python egg aus der ZIP entfernt, stattdessen setuptools direkt oder pip verwenden [Python] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, Visual Basic .NET

Das aktuelle Verhalten beim Überschreiben von Objekten können wir nicht so einfach ändern, da sich existierende Programme darauf verlassen könnten. Was wir aber machen können ist beim Aufruf von Gettern eines überschriebenen Objekts eine spezielle IchWurdeÜberschriebenException zu verwenden, statt einer TimeoutException. Dann ist dies leichter zu erkennen.

Ich habe mir dein Programm angesehen. Dein Problem mit dem IO-16 Bricklet liegt daran, dass du zwei BrickletIO16 Objekte für die gleich UID mit der gleichen IPConnection erzeugst. Im MainWindow Konstruktor erzeugst du ein ControllerDevice mit UID gpL und ein ChannelDevice mit UID gpL. Beide leiten von Device ab und erzeugen dadurch zwei BrickletIO16 Objekte für die gleich UID. Intern hält die IPConnection eine Tabelle, die UID auf Brick/Bricklet Objekt abbildet. Wenn du bei gleicher UID und IPConnection ein weiteres BrickletIO16 erzeugst, dann verdrängt das neu Objekt das alte aus dieser Tabelle. Der Effekt davon ist, dass Setter-Aufrufe auf dem alten BrickletIO16 Objekt noch funktionieren, die Antworten für Getter-Funktionen aber immer dem neuen BrickletIO16 Objekt zugestellt werden. Dadurch bekommst du einen Timeout beim Aufruf einer Getter-Funktion auf dem alten BrickletIO16 Objekt. Das ist auch der Grund warum es hilft, wenn du das BrickletIO16 Objekt vor dem Getter-Aufruf neu erzeugst, weil diese dann das bisherige Objekt verdrängt und die Antworten zugestellt bekommt. Wenn ich das richtig sehe, dann soll das ControllerDevice sich mit Port B und das ChannelDevice mit Port A eines IO-16 Bricklets befassen. Damit das klappt kannst du deiner Device Klasse beibringen, dass sich zwei Device Objekte ein BrickletIO16 Objekt teilen.

Dein Programm aktiviert den Count Callback nicht (siehe Callback Beispiel). Wenn du in brickv den Tab des Bricklets öffnest, dann aktiviert brickv den Callback und dadurch erhält in auch dein Programm. Dir fehlt folgende Zeile in __init__: self.encoder.set_count_callback_period(50)

Brick Daemon 2.1.1 Add live debug log view to logviewer.exe on Windows Include signed version of the Brick bootloader driver for Windows Workaround race condition in USB hotplug handling on Linux Fix crash if client with pending responses disconnects Fix possible mismatch while handling responses for identical requests Avoid broadcasting unexpected responses in most cases Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.1.1 Live Debug Log Ansicht zu logviewer.exe für Windows hinzugefügt Signierte Version des Brick Bootloader Treibers für Windows hinzugefügt Race Condition in der USB Hotplug Behandlung auf Linux vermieden Absturz behoben Im Falle, dass ein Client die Verbindung trennt bevor alle Responses gesendet wurden Mögliche Falschzuordnung in der Response Behandlung für identische Requests behoben Broadcast unerwarteter Antworten wird in den meisten Fallen jetzt vermieden Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Du machst da keinen Kurzschluss, solang du den Pin an dem der Schalter hängt nicht als Ausgang konfigurierst. Es ist kein Problem, dass so auch über längere Zeit zu betreiben. Dein Aufbau ist einer der typischen Anwendungsfälle der IO-4.

Loetkolben, der Kreis mit dem A drin ist ein Amperemeter. Das soll die Arbeitsweise der IO-4 symbolisiern, weshalb des auch in der IO-4 Box ist. tfRookie, wenn du einfach nur messen willst ob ein Schalter offen oder geschlossen ist, dann kannst den Schalter direkt zwischen einen der vier Pins und GND der IO-4 anschließen. Kein Vorwiderstand nötig. Die Pins der IO-4 sind standardmäßig als Input Pull-Up konfiguriert. Wenn du ihren Wert per get_value() Funktion ausließt bekommst du High zurückgegeben. Wenn der angeschlossene Schalter offen ist, dann ist es für die IO-4 als wäre er nicht da, get_value() liefert High. Wenn der Schalter geschlossen ist wird der Pin mit GND verbunden, get_value() liefert Low. Du kannst statt get_value() auch den Interrupt Callback verwenden, dann teilt dir die IO-4 von sich aus Änderungen des Pin-Zustands mit.

Das Linux für den RED Brick basiert auf Debian.