Jump to content

photron

Administrators
  • Gesamte Inhalte

    3.206
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    56

Alle erstellten Inhalte von photron

  1. 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
  2. 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.
  3. 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?
  4. 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?
  5. 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.
  6. 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.
  7. Komischer Fehler, habe ich noch nie gesehen. Was nimmst du denn als brocker_host und brocker_port in Zeil 885 angegeben? Ich denke da passt was nicht.
  8. Funktioniert hier mit Brick Viewer 2.3.3 unter Linux. Funktioniert es denn, wenn du eine ältere Brick Viewer Version installierst? Hast du mal versucht das Remote Switch Bricklet über den Brick Viewer neu zu flashen?
  9. Aus der Dokumentation des Bricklets: Normales PMMA/Plexiglas lässt diese Wellenlänge durch, solange es nicht speziell UV blockierendes PMMA/Plexiglas ist.
  10. New products: OLEDs, Thermocouple and CO2 Blog Entry
  11. Neue Produkte: OLEDs, Thermoelement und CO2 Blogeintrag
  12. Hast du vielleicht ein altes Ambient Light Bricklet und versuchst das Beispiel für das neue Ambient Light 2.0 Bricklet zu verwenden? Das würde zur Fehlermeldung passen. Das alte Bricklet hat die Helligkeit als uint16 (2 Byte) übertragen. Das neue Bricklet überträgt die Helligkeit als uint32 (4 Byte). Das passt zur Fehlermeldung, dass 4 Byte erwartet wurden, aber nur 2 Byte empfangen wurden. In dem Fall muss du einfach nur, dass Beispiel für das alte Ambient Light Bricklet nehmen: http://www.tinkerforge.com/de/doc/Software/Bricklets/AmbientLight_Bricklet_PHP.html#simple
  13. Brick Logger 2.0.3 Add authentication support Add support for CO2, OLED 64x48 and 128x64, Thermocouple and UV Light Bricklet Downloads: Windows, Linux, Mac OS X, RED Brick
  14. Brick Viewer 2.3.3 Add authentication support for data logger Add support for CO2, OLED 64x48 and 128x64, Thermocouple and UV Light Bricklet Downloads: Windows, Linux, Mac OS X
  15. Brick Logger 2.0.3 Support für Authentication hinzugefügt Support für CO2, OLED 64x48 und 128x64, Thermocouple und UV Light Bricklet hinzugefügt Downloads: Windows, Linux, Mac OS X, RED Brick
  16. Brick Viewer 2.3.3 Support für Authentication zum Data Logger hinzugefügt Support für CO2, OLED 64x48 und 128x64, Thermocouple und UV Light Bricklet hinzugefügt Downloads: Windows, Linux, Mac OS X
  17. Bindings: C/C++ 2.1.9, C# 2.1.8, Delphi/Lazarus 2.1.9, Java 2.1.7, JavaScript 2.0.7, LabVIEW 2.1.7, Mathematica 2.1.7, MATLAB/Octave 2.0.7, Perl 2.1.7, PHP 2.1.7, Python 2.1.7, Ruby 2.1.7, Shell 2.1.7, VB.NET 2.1.7 Add support for CO2, OLED 64x48 and 128x64, Thermocouple and UV Light Bricklet Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, VB.NET
  18. Bindings: C/C++ 2.1.9, C# 2.1.8, Delphi/Lazarus 2.1.9, Java 2.1.7, JavaScript 2.0.7, LabVIEW 2.1.7, Mathematica 2.1.7, MATLAB/Octave 2.0.7, Perl 2.1.7, PHP 2.1.7, Python 2.1.7, Ruby 2.1.7, Shell 2.1.7, VB.NET 2.1.7 Support für CO2, OLED 64x48 und 128x64, Thermocouple und UV Light Bricklet hinzugefügt Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, VB.NET
  19. Hast du die richtige UID im Beispiel eingetragen?
  20. Ist korrigiert. Danke für den Hinweis.
  21. Der Code sollte so funktionieren. Du musst allerdings noch den Receiver Enable Pin auf Output-Low setzen, um den Receiver zu aktivieren, siehe init_rxe_pin_state in red_rs485_extension.c.
  22. Wenn dann muss es sudo chown tf ~/.Xauthority lauten. Mit chwon änderst du den Besitzer einer Datei. Den Nutzer user gibt es nicht auf dem RED Brick. Der Nutzer heißt tf. Das wird potentiell nicht helfen. Du kannst testweise xauth auch abstellen mittels "xhost +". Damit hat dann jeder Zugriff auf den X Server. Dafür "startx ./Touch" durch xhost +; startx ./Touch für das Starten deines Programms ersetzen.
  23. Damit Brick Daemon auf dem RED Brick eine RS485 Extension nicht nutzt, musst du sie mit einem Master Brick und Brick Viewer auf Extension Type None konfigurieren. Die RS485 Extension ist so angeschlossen, dass sie auf UART3 gemuxt werden kann. UART3 taucht als /dev/ttyS0 auf. Der TX Enable Pin des RS485 Transceivers kann auf RTS von UART3 gemuxt werden. Der RX Enable Pin an einem GPIO Pin angeschlossen. Da Brick Daemon jetzt nichts mehr mit der RS485 Extension macht (wegen Extension Type None) musst du selbst das Pin Muxing richtig einstellen. Details kannst du dir im Brick Daemon Code (red_extenstion.c) ansehen. Das kann mit libmodbus funktioniert, getestet hat das meines Wissens nach aber noch keiner. Ein RS232 Bricklet taucht nicht als eine serielle Schnittstelle des Betriebssystems auf.
  24. Mit "startx ./Touch" startest du dein Touch Programm als graphische Oberfläche anstatt des LXDE Desktops. Das ist so von uns erstmal nicht direkt vorgesehen. Vorgesehen ist, das der LXDE Desktop startet und dann dein Programm darauf angezeigt wird. Was du testen kannst ist folgendes: - Auf dem Services Tab den Desktop abstellen - Dein Programm als Shell Programm hochladen - Beim Shell Programm "Command" statt "Script" wählen und dort "startx ./Touch" eintragen - Unter Environment nicht DISPLAY angeben, weil dann der redapid darauf wartet, dass der LXDE Desktop gestartet ist, bevor er dein Programm startet. Das sollte so funktionieren, ich habe es aber nicht getestet.
  25. Ist das ein GUI Programm? Hast du DISPLAY auf :0 gesetzt?
×
×
  • Neu erstellen...