photron

Du machst da gar nichts falsch! Ich kann das Problem hier reproduzieren, sieht nach einem Problem in der Firmware des Bricklets aus. Muss ich mir genauer ansehen.

Hrm, bin ich etwas ratlos. Mach mal testweise aus dem illuminance/10.0 ein illuminance/10 um zu sehen ob das deinen Unterschied macht.

Welche Version des Compilers verwendest du denn, also was gibt "msc --version" aus? Der Fehler bezieht sich auf Zeichen 77 in Zeile 18. In WeatherStation.cs steht dort: string text = string.Format("Illuminanc {0,6:###.00} lx", illuminance/10.0); Wenn die Tabs als jeweils ein Zeichen gezählt werden dann ist Zeichen 77 die schließende Klammer nach 10.0. Ergibt so richtig keine sinn warum das ein Problem sein sollte. Steht bei dir etwas anderes in Zeile 18 in einfache_Wetterstation.cs?

Did you test this yet? Any feedback on this?

Dass heißt jedes dieser drei Bricklets einzeln am Servo Brick angeschlossen macht kein Problem. Sobald du aber irgendein zweites Bricklet anschließt funktioniert die WLAN Verbindung deutlich schlechter? Ist die Kombination der Bricklets egal, oder gibt es eine spezielle Kombination die das Problem erzeugt? Wie lang sind die Bricklet Kabel die du verwendest? Funktioniert es besser wenn du kürzere Kabel verwendest, unter der Annahme dass du noch nicht die kürzesten Kabel verwendest?

Komische Fehlermeldung, vom Text her. Was ist der genau Text der Fehlermeldung? Hört sich an als ob der System.Net Namespace fehlt. Der kommt aus der System.dll (oder der System.Net.dll (?)), die sollte aber eigentlich automatisch zu deinem C# Projekt hinzugefügt worden sein.

Sprichts du denn das Protokoll auch so wie hier beschrieben: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/Modbus.html#requests-and-responses Sprich pollst du den Slave für Responses nachdem du ihm den Request gesendet hast? Slaves dürfen von sich aus keinen Response senden, sondern nur als Antwort auf einen Request. Edit: Hätte mal richtig lesen sollen. Wie handhabt dein RS485 Wandler den Transmitter und Receiver Enable? Steuerst du das von Hand, oder passiert das automatisch? Wenn der Transmitter auf der Master-Seite aktiviert ist wenn der Slave antwortet dann kann die Antwort verfälscht ankommen.

Welche Bricklets hast du denn am Servo Brick getestet?

Hrm, da ist wohl einiges schief gelaufen mit dieser Funktion. Ich hab mir die Dokumention gar nicht angesehen, sondern die Firmware. Die Dokumention ist schlicht falsch, sorry. Ich habe sie jetzt korrigiert, danke für den Hinweis.

Hast du schon mal getestet, ob es einen Unterschied macht, wenn du den Stack in einer anderen Reihenfolge zusammensteckst? Step-Down und Master müssen ganz unten bleiben, alles andere darüber kannst du beliebig vertauschen. Wenn du nur Master Brick und WIFI Extension verwendest und über USB versorgst, funktioniert dann die WLAN Verbindung auf dauer besser?

is_light_on() ist nicht negiert. is_light_on() gibt keinen bool zurück, sondern einen uint8 mit 2 definierten Werten LIGHT_ON = 0 und LIGHT_OFF = 1. ilor.light = PIN_LED.pio->PIO_PDSR & PIN_LED.mask ? LIGHT_ON : LIGHT_OFF; Wenn du das als bool betrachten willst dann ist das negiert, ja. Man hätte da einen bool zurückgeben können. So ist es aber nicht definiert worden und jetzt ist es zu spät das zu ändern, sorry.

Das init Script wird als root ausgeführt. Funktioniert Folgendes? sudo java -jar /home/pi/FerienHaus.jar

Ein JAR ist keine ausführbare Datei. Die --exec Option des start-stop-daemons erwartet aber eine ausführbare Datei. Es sollte funktionieren, wenn du DAEMON=/home/pi/FerienHaus.jar OPTIONS=--daemon durch DAEMON=java OPTIONS=-jar /home/pi/FerienHaus.jar ersetzt. Unter der Annahme, dass dein FerienHaus.jar einen Main-Class Eintrag im Manifest hat.

Dein Problem liegt hier: $VALUE_ON = (1 << 3); $iqr->setMonoflop($VALUE_ON, 1, 500); Die Signatur ist so: setMonoflop(int $selection_mask, int $value_mask, int $time) Für die selection_mask nimmst du 1 << 3, also eine 1 um 3 Bit nach links geschoben, in Binär 0b1000 (0b als Prefix für Binär, so wie 0x für Hexadezimal). Damit hast du das Relais 3 (von 0 gezählt) ausgewählt. Für die value_mask nimmst du 1, in Binär 0b0001. Damit gibst du für Relais 0 vor dass es eingeschaltet werden soll und alle anderen ausgeschaltet. Da du mit der selection_mask von 0b1000 aber gesagt hast, dass über haupt nur Relais 3 geschaltet werden soll passiert nichts, da Relais 3 schon aus ist. Die selection_mask sagt welche Relais überhaupt geschaltet werden sollen und die value_mask sagt wie geschaltet werden sollen. 0b1000 selection_mask 0b0001 value_mask In der value_mask werden also nur die Stellen betrachtet, für die in der selection_mask eine 1 steht. Du schaltest also Relais 3 aus und alle anderen bleiben unverändert. Um Relais 3 einzuschalten muss es so aussehen: 0b1000 selection_mask 0b1000 value_mask und daher so in PHP: $SELECT_3 = (1 << 3); $VALUE_3_ON = (1 << 3); $iqr->setMonoflop($SELECT_3, $VALUE_3_ON, 500); Bitmasken können verwirrend sein

Leider nein, das hatte ich schon beim eigenen Ausprobieren getestet, Fehlermeldung "adress already in use" Doch doch, das geht, du musst dann nur für den zweiten Listen Aufruf einen anderen Port nehmen. Standardmäßig lauscht Listen auf Port 4217 auf eingehende Verbindungen von NetIO. Hier mit lauscht das zweite Listen auf Port 4218 für die zweite Ethernet Extension: tinkerforge --host 192.168.2.242 --port 4222 listen --port 4218

Wenn du den Listen Modus so startest tinkerforge --host 192.168.2.241 --port 4222 listen dann werden all Befehle die von NetIO eingehen an 192.168.2.241:4222 geschickt. Für deine zweite Ethernet Extension kannst du jetzt die Shell Bindings in zweites Mal im Listen Modus mit der anderen IP Adresse starten. In NetIO verwendet du dann auch zwei verschiedene Connections. Du kannst aber auch die --enable-host und --enable-port Option des Listen Modus nutzen. Dann kannst du von NetIO aus für jeden Befehl --host und --port setzen. Also tinkerforge listen --enable-host --enable-port und dann in NetIO statt "call ..." --host 192.168.2.241 --port 4222 call ...

Okay, nehmen wir mal an die Verschraubung ist wirklich das Problem. Wie fest hast du die Bolzen angezogen? Wenn du die sehr stramm anziehst dann kann es vorkommen, dass du die Platine etwas verbiegst. Vielleicht ist das Verbiegen das eigentliche Problem. Was passiert, wenn du die Bolzen nur sehr locker verschraubst? Eigentlich sollten alle Bauteile auf den Bricks so gesetzt sein, dass du mit den Bolzen in jeglicher Stellung keine Bauteile berühren kannst und damit auch keine Kurzschlüsse machen kannst. Schau dir dennoch mal an ob du nicht irgendwo eine Bolzen hast der ein Bauteil oder ein Lötstelle berührt.

Dass heißt also, ob es funktioniert oder nicht hängt davon ab wie du das ganze mit Strom versorgst? Dein Stack besteht aus Step-Down Power Supply, zwei Master Bricks und einem DC Brick. Wenn du den Stack mit 5V über USB versorgst und den Lüfter mit 12V über den schwarzen Stecker des DC Bricks, dann funktioniert es. Sobald du aber den Stack über die Step-Down Power Supply versorgst geht es nicht mehr. Frage 1: Versorgst du den Lüfter und die Step-Down Power Supply mit dem gleichen Netzteil? Und was ist das überhaupt für ein Netzteil: Spannung, maximaler Ausgangsstrom, etc? Frage 2: Hast du ein zweites Netzteil zur Hand, so dass du als Test Step-Down Power Supply und Lüfter aus zwei verschiedenen Netzteilen versorgen könntest?

Wenn es das Problem aus dem Stepper Brick Thread ist, dann sollte es helfen, wenn du auf allen Brick im Stapel die aktuellen Firmware Versionen hast: Master Brick 2.2.2, DC Brick 2.0.3. Wenn du schon die aktuellen Firmware Versionen verwendest und das Problem besteht weiterhin, dann ist es wahrscheinlich nicht direkt das Problem aus dem Stepper Brick Thread.

Dass heißt, sobald du enable aufrufst wenn der Drive Mode auf Drive/Coast stehst oder du auf Drive/Coast umstellst während enabled=true ist dann startet der DC Brick neu. Der Neustart ist dann daran zu erkennen, dass der Drive Mode auf Drive/Break zurückgesetzt wurde und is-enabled false ausgibt. Ich nehme an, in den Fällen wo get-drive-mode einen Fehler ausgibt, hast du get-drive-mode direkt nach set-drive-mode oder enable aufgerufen, so dass du den DC Brick im Neustart erwischt hast und er noch nicht antwortet konnte. Tritt das Prpblem nur auf, wenn der Lüfter angeschlossen ist, oder auch wenn der Lüfter nicht angeschlossen ist?

Du hast den EN Eingang des I2C Trenners ICs mit dem ADDR Ausgang des Bricklet Steckers verbunden. Das funktioniert nur am Master Brick. Der Master Brick setzt den ADDR Ausgang auf High für das Bricklet mit dem er I2C sprechen will, und sonst auf Low. Bei allen anderen Bricks mit zwei Bricklet Ports ist der ADDR Ausgang des einen Bricklet Ports fest auf High und des anderen Bricklet Ports fest auf Low. Das Problem kannst du lösen indem du den EN Eingang des I2C Trenners ICs nicht mit ADDR, sondern mit IO_1 verbindest. Der A03 Eingang des EEPROMs muss aber mit ADDR verbunden bleiben.

Callbacks werden nicht per IP Connection eingestellt, sondern die Callback Einstellungen sind auf dem Brick(let)s und somit global über alle IP Connections hinweg. Daher können sich zwei Programme die die gleichen Callbacks nutzen in die quere kommen.

setChipType() ist neu in Java Bindings Version 2.1.1. Verwendest du vielleicht unter Linux eine ältere Version der Bindings?

Vielleicht haben AB440S und AB440SC verschiedene Toleranzen für das gesprochenen Protokoll und wir treffen die Timings nicht immer gut genug für die AB440S Version. Müssen wir uns genauer anschauen.

Hrm, die interessante Zeil aus dem Log ist diese: libusb: warning [windows_get_device_list] could not retrieve port number for device '\\.\USB#VID_16D0&PID_063D&REV_0110#3&2CD4FE1F&0&A277F366-0B82-494C-9CF6-4FBCD4D47C5F', skipping: [13] Die Daten sind unzulässig. libusb fragt hier Windows bzw. den USB Hub Treiber nach der Portnummer des Bricks am USB Hub und bekommt als Antwort ERROR_INVALID_DATA, was laut Dokumentation bedeutet, dass die angefragte Information nicht vorhanden oder ungültig ist. Da bin ich jetzt etwas ratlos, sorry. Wie ist den der Aufbau des ganzen? Irgendwo steht ein Window Server auf dem unter Hyper-V Windows VM laufen. Du verbindest sich von einem anderen Windows Rechner zu so einer VM. An deinem lokalen Windows Rechner ist ein Brick per USB angeschlossen und über RDP reichst du den in die VM rein. Stimmt das so? Wenn ja, funktioniert der Brick den dann im lokalen Windows?