Nic

Ok, danke. ... 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.

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. ?

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?

Ich werde mich u.U. unbeliebt machen , 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?

Guter Bericht! Ich bin sehr gespannt auf den neuen Stepper, auch wenn es erst März wird.

Kurz überflogen: da gibt es mehrere neue 2130 spezif. Methoden; SetStepMode ist ersetzt durch SetStepConfiguration. Es werden allerdings noch keine Examples für die ergänzten Methoden erzeugt.

und möchte diese mit T genannten Treibern... Achso unter dem T hatte ich Tinkerforge Bausteine verstanden.

Zur Not kannst du einen Blick ins https://github.com/Tinkerforge/silent-stepper-brick werfen.Solange da kein Unterverzeichnis "Example" ist, sollte die Api noch nicht ganz abgeschlossen sein. Ev. gibt der C-Code auch einen Eindruck welche weiteren Methoden hinzukommen. Ein Blog-Beitrag wäre prima allerdings bitte noch vor Weihn.

Der Stepper Brick unterstützt nur bis max. 2.5A pro Phase! Beim endlos angekündigten, voraussichtlich 2017 erhältlichen Silent Stepper Brick mW. nur noch 1.2A.

Was ist perfect ? Ich würde das doch etwas konkreter wissen, i.d.R. werden die vielen billigen Displays für die Raspis über die GPIOs bzw. SPI verbunden, die HDMI Varianten sind da deutlich teurer und wuchtiger. Links?

@davidcomboni Zum RED kompatible Hardware bitte schließlich in diese Liste eintragen: http://www.tinkerunity.org/wiki/index.php/DE/RED_USB

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.

Wenn nicht explizit (aufgrund techn. Restriktionen etc.) angegeben, würde ich vom Maximum des Datentypen ausgehen.

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.

Das ist Basiswissen C# Dazu gibt es viele, speziellere Foren als hier (sollten i.d.R. tinkerforge relevante Aspekte behandelt werden) https://msdn.microsoft.com/de-de/library/w86s7x04.aspx

Zieh die beiden short Vars raus und lege sie als private Properties innerhalb der Main ab. Dann kannst du beide Werte im jeweils anderen CB nutzen. Gewöhnt Euch bitte an, den Source Code möglichst komplett im Posting zu zeigen. Macht die Fehlersuche bzw. Hinweise leichter.

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?

War es unter Mac http://www.tinkerunity.org/forum/index.php/topic,2280.msg15046.html#msg15046 oder Windows http://www.tinkerunity.org/forum/index.php/topic,2579.msg16808.html#msg16808

Jo klappt jetzt und zumindest bei mir

Für Tinkerforge Projekte und 32bit Progs reicht die Starter allemal

Wie lange kann man die kostenfrei benutzen Anbei die 3 geänderten Units aus den Bindings. IPConnection.pas LEConverter.pas BlockingQueue.pas

Ok, gefunden, schalte den Range Check aus, ist ja bei dir an, denn wenn ich z.B. im LEConverter {$R+} extra hinzufüge bekomme ich deinen 1091. Entweder in den globalen Compiler Flags oder so unit LEConverter; {$R-} {$ifdef FPC}{$mode OBJFPC}{$H+}{$endif}

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.

Ich komme gar nicht soweit: 2 Fehler beim Erzeugen eines neuen Projects innerhalb der Bindings: [Fehler] BlockingQueue.pas(17): $IFEND erwartet, aber $ENDIF gefunden [Fataler Fehler] BlockingQueue.pas(25): Datei nicht gefunden: 'Generics.Collections.dcu' Mit D7 Pro.

Interessant ich benutze idR D7, aber damit keine Probleme. Hast du Range Checking enabled?