photron

Ohne brickd auf dem RED Brick würde dieser gar nicht im Brick Viewer auftauchen. Oder meinst du das mit "keine Konsole mehr"? Oder meinst du, das der Console Tab auf dem RED Brick Tab nicht mehr richtig funktioniert? Bzw. vom RED Brick kein serielles Device mehr auftaucht?

Auch für dich eine Version mit aktueller libusb zum Testen. brickd_macos_2_2_2_libusb1.dmg

Du muss die Temperatur nehmen und sie in ihre Stellen zerlegen nach dem Muster ($temperatur geteilt durch 10 hoch Stelle) modulo 10 Hier ein kombiniertes Beispiel dafür mit Temperature Bricklet: https://github.com/Tinkerforge/segment-display-4x7-bricklet/blob/master/software/examples/php/ExampleTemperature.php

Um welche Mac OS X Version geht es hier?

Okay, teste mal bitte die angehängt brickd Version. Diese verwendet jetzt die neuste libusb Version. brickd_windows_2_2_2_libusb1.exe

Mit usb_modeswitch hat das nicht zu tun. Der RED Brick ist ein USB Composite Device mit einem Vendor Specific Interface (Tinkerforge API) und einem CDC-ACM Interface (serielle Schnittstelle). Der RED Brick sollte als zwei Devices im Geräte Manager auftauchen: "RED Brick" und "RED Brick Serial Console". Taucht der problematische RED Brick nur als ein unbekanntes Gerät auf, oder taucht das "RED Brick" Gerät, aber das "RED Brick Serial Console" nicht auf? Ich würde auf ersteres tippen, das würde zu einem Hardwäredefekt passen. Da kannst du softwaremäßig nichts machen und nichts debuggen. Das zweite Log vom RED Brick sieht normal aus

Nicht so einfach. Über die R, G und B Leitungen wird höchstwahrscheinlich der Strom für die LEDs übertragen. Dabei wird die Helligkeit der 3 Farbkanäle über PWM geregelt. Das kann man auch über eine Leitung weniger machen. Dazu könnte man auf der einen Seite die 3 PWM Signale messen und digital (z.B. UART/Seriell) über eine Leitung an die andere Seite übertragen und dort das PWM für die LEDs wieder erzeugen. +-------------------+ +---------------------------+ +-------------------------+ +--------+ | R|----|R | | R|----| | | Steuergerät G|----|G PWM->Digital Daten|------------L--------|Daten Digital->PWM G|----| | | B|----|B Masse|------------N--------|Masse B|----| LEDs | | Masse|----|Masse Versorgung | +------E--------|Versorgung Masse|----| | +-------------------+ +---------------+-----------+ | +-------------------------+ +--------+ | | ---------------------+-----------------+ Ob's dafür allerdings schon was fertiges gibt weiss ich nicht.

Was man testen könnte, wäre die libusb Version die brickd mitbringt zu aktualisieren. Die Version die beiliegt ist relative alt. Ich habe mich bisher vor einem Update gescheut, weil es mit der Version bisher keine Problem gab und es in letzter Zeit viele Änderungen in libusb gab. Die Chance ist also halbwegs hoch sich mit der neuen Version auch neue Probleme einzufangen. Gerade gibt es aber auch einen Thread auf der libusb Mailing über Windows 10 und Transfer Stalls. Möglicherweise ist da was dran. Wenn ich heute noch dazu kommen baue ich eine neue brickd Version mit einer aktualisierten libusb Version zum Testen.

Virtualisierung ist eine Option, bringt aber auch einen weiteren Layer an möglichen Problemen mit sich.

Das gibt brickd aus, wenn ein USB Bulk Read Transfer (um Daten vom Brick zu lesen) mit dem libusb Fehlercode LIBUSB_TRANSFER_STALL endet. libusb gibt diesen Fehlercode zurück wenn WinUsb_ReadPipe mit dem Windows Fehlercode ERROR_GEN_FAILURE scheitert, siehe: https://msdn.microsoft.com/de-de/library/Windows/Hardware/ff540297(v=vs.85).aspx

Mit Windows 10 haben wir noch keine großen Erfahrungen, es sind mir aber auch keine aktuellen Probleme bekannt. Dennoch wäre das mein erster Ansatzpunkt. Besteht die Möglichkeit, dass du das auf einer älteren Windows Version testen kannst?

Richtig, das kleinste Fenster, das du setzen kannst ist 1x8 Pixel. Das liegt aber an der API des OLED selbst. Das ist keine künstliche Beschränkung unsererseits.

Den Fehler habe ich noch nie gesehen. Beschreibe mal deinen Aufbau genauer: - welche Windows Version? - wie ist dein Stack aufgebaut? - wie ist der Stack angeschlossen (USB2, USB3, Hub dazwischen etc.)? - wie häufig kommunizierst du mit dem Stack?

Das wird es.

Du hast also folgendes vor: 230V <---> Steuergerät <--- 3-adrige Leitung ---> 3 LED Strips parallel Die LED Strips haben aber 4 Anschlüsse (R, G, B und Masse, nehmen ich an), dir fehlt also die 4. Ader. Was spricht geben diese Anordnung? Ist das Steuergerät dafür zu groß? 230V <--- 3-adrige Leitung ---> Steuergerät <---> 3 LED Strips parallel

Das aktuelle Beispiel kann das nicht, das stimmt. Teste mal bitte diese verbesserten Beispiele. ExampleScribble_v2.php ExamplePixelMatrix_v2.php

Ich denke es handelt sich um diesen Debian Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568550#27 Ich sehe das auf meinem RED Brick hier auch. Folgende Package Installation sollte das beheben: sudo apt-get install snmp-mibs-downloader

Das ist Absicht. write() und clearDisplay() arbeiten immer auf dem zuletzt gesetzten Fenster. Die Dokumentation sagt das leider noch nicht, das werde ich gleich korrigieren. Danke für den Hinweis.

Das ist komisch. Anyway, wegen Rücksendung melde dich bitte bei info@tinkerforge.com und verweiß auf diesen Thread hier.

Die Daten erhältst du über die API Bindings des GPS Bricklets. Hier z.B. in C: http://www.tinkerforge.com/de/doc/Software/Bricklets/GPS_Bricklet_C.html

When you say "powered USB bridge", do you mean just a powered USB hub or a proper USB isolator? So you didn't yet fully separate the AC motor part from the Stepper Brick part? You always had some kind of electrical connection between the two parts and tried to apply filters or different means of tethered communication to solve the issue? Assuming this is some kind of EMC issue, I think you should figure out next if the issue is related to the electrical connection between the two parts or if just physical proximity is already enough to trigger the issue.

The special Brick Daemon version for the RED Brick can use an RS485 Extension as Modbus master to talk to another stack of Bricks. But this is highly RED Brick specific. The recent forum thread about RED Brick and RS485 Extension was about stopping Brick Daemon on the RED Brick from using the RS485 Extension to talk to another stack of Bricks. The goal in that thread was to use an RS485 Extension on a RED Brick to talk to some generic Modbus device, without having Brick Daemon involved. So this is something different. Also don't jump to conclusion. Replacing the USB connection to the Stepper Brick with an RS485 connection might not help at all, because the actual problem might be totally different from what you currently think it is. For example, did you try to run your laptop/Brick setup disconnected from AC mains? Try running your laptop from its battery and disconnect the switching power supply from the Stepper Brick. Now check if you can still reset the Stepper Brick by starting the AC motor. Another thing to try: connect the Stepper Brick to a second laptop/PC (if available) to check if the single laptop as a central connection point has an effect on this. Also, what about physical proximity? Does the Stepper Brick have to be near to the AC motor? Or can it be placed further way? Does it make a difference? Do you route your power and USB cabels in parallel? Can you route them differently? Does the AC motor have the required filters/snubbers/etc installed, if necessary/recommended for that type of motor? Did you try to power the Stepper Brick differently? For example with a Step-Down Power Supply (assuming you have one at hand), or with an active USB hub instead of the USB port on your labtop?

The RS485 Extension is meant to only connect to another RS485 Extension to connect two or more stacks of Bricks. It is not meant to be integrated with other Modbus devices. Using a RED Brick and an RS485 Extension to talk to other Modbus devices might be technically possible, but is not officially supported and there is no ready made software for this scenario. What you do with an RS485 Extension is this: PC <---USB---> Master Brick + RS485 Extension <========> RS485 Extension + Master Brick + other Bricks and Bricklets But back to your original problem. Can you describe in more details how all the parts are inter connected and how power is supplied to the different parts of the system?

Does the current directory already contain a file named brickv_linux_latest.deb? In this case wget will not replace it but download the new file as brickv_linux_latest.deb.1.

brick-mqtt-proxy.py kannst du einfach als weitere eigenständiges Programm auf den RED Brick laden und starten lassen. Genauso wie du dein dust_detector_500ms.py Skript als Programm hochlädst. Der Fehler besagt, dass vmiot01srv als Hostname nicht bekannt ist.