Jump to content

Nic

Members
  • Gesamte Inhalte

    1.425
  • Benutzer seit

  • Letzter Besuch

Posts erstellt von Nic

  1. Ok, danke.

    Das ist prinzipiell unabhängig vom Silent Stepper Brick und könnte entweder mit einer speziellen Platine...Sonderfunktion des IO-4 Bricklets

    ... beide Varianten erfordern aber FW Anpassung. Dann würde ich die Sonderfkt. des IO4 präferieren :), da muss nix extra angeschlossen werden, und mir bleibt ein Port frei für weiteren Sensor.

  2. Ja das ist schon richtig mit der Build Umgebung, allerdings ist das nicht so banal und mal eben schnell erledigt :(

     

    Ein gcc ist im Entware repo aber dabei, der Rest anscheinend nicht:

     

    admin@nas:/tmp/home/root# pkg-config --modversion libusb-1.0
    Package libusb-1.0 was not found in the pkg-config search path.
    Perhaps you should add the directory containing `libusb-1.0.pc'
    to the PKG_CONFIG_PATH environment variable
    No package 'libusb-1.0' found
    
    admin@nas:/tmp/home/root# pkg-config --list-all | grep libusb
    
    admin@nas:/tmp/home/root# gcc --version
    gcc (OpenWrt GCC 5.4.0) 5.4.0
    Copyright (C) 2015 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    

     

    Das repo gibt sonst nur

    admin@nas:/tmp/home/root# opkg list | grep libusb*
    libhid - 0.2.16-1 - libhid provides a generic and flexible way to access and interact with USB HID devices, much like libusb does for plain USB devices. It is based on libusb 0.1, thus it requires no special HID support in the kernel. Furthermore, it aims to support all operating system supported by libusb.
    libusb-1.0 - 1.0.20-1 - libusb is a C library that gives applications easy access to USB devices on many different operating systems.
    libusb-compat - 0.1.4-2 - libusb is a C library that gives applications easy access to USB devices on many different operating systems.
    

     

    Wenn ich den gcc schon habe, ließen sich die libusb-1.0-0-dev über das Sourcen Paket von libusb https://github.com/libusb/libusb ggf. compilieren und install. ?

  3. Ich versuche auf dem Asus Router RT-AC56U mit freier FW Asuswrt-Merlin und Entware/Opkg den BrickD zu installieren. libusb wird aber nicht in der passenden Version gefunden,

    Makefile:305: *** Could not find libusb-1.0 >= 1.0.6.  Stop

    obwohl die 1.0.20 darauf ist:

    admin@nas:/tmp/mnt/Optware/_test/brickd/src/brickd# ldconfig -v | grep libusb*
    ldconfig: Path `/lib' given more than once
    ldconfig: Can't link /usr/lib/libtmrg.so.0 to libtmrg.so.0.1
    ldconfig: Can't link /usr/lib/libprotobuf-c.so.1 to libprotobuf-c.so
            libusb-1.0.so.0 -> libusb-1.0.so.0.1.0
            libusb-1.0.so.0 -> libusb-1.0.so.0.0.0
            libusb-0.1.so.4 -> libusb.so
    admin@nas:/tmp/mnt/Optware/_test/brickd/src/brickd# make
    Makefile:305: *** Could not find libusb-1.0 >= 1.0.6.  Stop.
    admin@nas:/tmp/mnt/Optware/_test/brickd/src/brickd# opkg list | grep libusb
    libhid - 0.2.16-1 - libhid provides a generic and flexible way to access and interact with USB HID devices, much like libusb does for plain USB devices. It is based on libusb 0.1, thus it requires no special HID support in the kernel. Furthermore, it aims to support all operating system supported by libusb.
    libusb-1.0 - 1.0.20-1 - libusb is a C library that gives applications easy access to USB devices on many different operating systems.
    libusb-compat - 0.1.4-2 - libusb is a C library that gives applications easy access to USB devices on many different operating systems.
    admin@nas:/tmp/mnt/Optware/_test/brickd/src/brickd# opkg install libusb-1.0
    Package libusb-1.0 (1.0.20-1) installed in root is up to date.

    Muss ich die Makefile noch anpassen oder was ist da los?

  4. Ich werde mich u.U. unbeliebt machen ;D, aber egal fragen kostet nix.

    Den Vorschlag von Luxor http://www.tinkerunity.org/forum/index.php/topic,3701.msg22534.html#msg22534 finde ich gar nicht so schlecht.

     

    Den Silent Stepper möchte ich u.a für einen Kamera-Schlitten einsetzen, und mit 1 oder 2 Endlagen Stopper wäre man auf der sicheren Seite. Natürlich könnte man einen IO Bricklet verwenden, aber wenn es so zeitnah und sicher auslösen muss, wären mir Endlagen-Schalter direkt am Brick lieber.

     

    Wenn ich die finale Platine vom Silent anschaue: http://www.tinkerforge.com/de/blog/2016/12/8/silent-stepper-brick So ist da noch etwas Platz übrig weil der Kühlkörper fehlt. Könnte man in die freie Fläche 1 oder 2 Anschlüsse ähnlich wie beim IO4 und als Input-Pullup integrieren?

     

    Wie genial die USB-Kommunikation und TF-Architektur auch ist, die Zuverlässigkeit für den o.g. Fall steht und fällt mit dem Betriebssystem. Wenn z.B. bei einem CNC Projekt ein Timeout zwischenzeitlich zuschlägt oder irgendein Service bremst, wäre da ein zusätzlicher mechanischer Trigger eines Stops/DirectionChange nicht auch hilfreich? Justierbar z.B. mittels einer API Funktion ob ein Stop oder Richtungswechsel beim High-Low Wechsel des Inputs stattfinden soll. Fertig.

     

    Ist das noch technisch (und moralisch ;)) machbar?

  5. Ja, mit Cron wäre das ev. besser. Zumal bei so langer Periode Ungenauigkeiten bei den Bricklets zunehmen, wie hier besprochen:

    http://www.tinkerunity.org/forum/index.php/topic,3622.msg21936.html#msg21936

     

    Wenn du einen RTC-Bricklet nimmst könntest du das sehr genau über seine Callbacks steuern, und dort den Getter auf dem Ambi callen.

     

    PS: Da fällt mir noch der Brick-Logger http://www.tinkerforge.com/de/doc/Software/Brick_Logger.html#brick-logger ein, da hast du quasi den Cron incl.

  6. get_stack_voltage bzw. get_stack_current geben nur Werte zurück wenn der Stack über das StepDown-PowerSupply http://www.tinkerforge.com/de/doc/Hardware/Power_Supplies/Step_Down.html#step-down-power-supply versorgt wird.

     

    Interessant dass in der Doku http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_Perl.html#BrickMaster->get_stack_voltage auch eine sogen. StepUp-PowerSupply erwähnt wird. Die gibt es (noch) nicht, war mal angedeutet, ist aber eine Ewigkeit her ;)

     

    Alternativ falls die Versorgung über USB erfolgt, gibt es noch http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_Perl.html#BrickMaster->get_usb_voltage Funkt. allerdings nicht mit Master 2.1.

     

    Eine Berücksichtigung und Rückgabe der Spannung/Strom bei POE wird hardwaretechn. und von der API nicht supported.

  7. Externe Clock müsste der Takt/Pulsgeber gemeint sein für die Schrittauslösung, mE. geht es hier nicht um Synch. mit anderen Stepper-Bricks. Da müsste die TF Architektur generell angepasst werden.

     

    @Batti: Was heißt "externe Clock" jetzt genau: müssen wir das selbst triggern?

  8. Ja, ist ein Fehler hier, man muss CompilerVersion >= 20 abfragen Generics sind erst ab Delphi 2009(v20) eingeführt worden, v14 bedeutet D6, darum bei uns der Fehler:

    unit BlockingQueue;
    
    {$ifdef FPC}{$mode OBJFPC}{$H+}{$endif}
    
    {$ifndef FPC}
    {$ifdef CONDITIONALEXPRESSIONS}
      {$if CompilerVersion >= 20.0}
       {$define USE_GENERICS}
      {$ifend}
    {$endif}
    {$endif}

    Alle CompilerVersion Abfragen müssen mit ifend und nicht endif beendet werden.

    Bekomme sonst den "ifend" Fehler auch in IPConnection.

×
×
  • Neu erstellen...