Nic

Hmmh, ich meinte ein zentrales Register, um Bugs im Allgem. zu melden. Für uns Kunden ist es ev. nicht immer klar ob ein Fehler in der Hardware oder Software (Firmware/Viewer) vorliegt. In dem Ticket könnte z.B. die genaue Beschreibung des Fehlers abgelegt werden. Nimm als Beispiel das Problem mit den Slaves im Funknetz, zudem ich Dir eine Mail schrieb. Im Forum oder per Mail alles zu melden, macht es ev. zunehmend schwierig die Übersicht zu behalten, was schon bekannt ist oder nicht.

Das würde eine 2.Baustelle aufmachen, die TF-API nochmals zu kapseln, um z.B. strukturelle Schwächen zu beseitigen !? Und wer pflegt das ganze dauerhaft ? Praktischer wäre die notwendigen Anpassungen im Code-Generator vorzunehmen. Die Kapselung/Interfaces kann jeder später je nach Anwendungsfall für sich machen.

So nebenbei entstanden, um unabhängig von externen Stromquellen zu sein. Zweckentfremdet wurde ein externer Akku-Pack von YAYAGO, ca. 10 Euro (Kapazität ca.1400mAh) zum Handyaufladen, der 5V ausgibt. Brick-Stack wird über die Board2Board-Connector versorgt. Mini-USB zum Wiederaufladen bleibt bestehen.

Oh, das habe ich übersehen. Können wir dort also Hardware Bugs melden ? Oder betrifft das nur die Firmware bzw. Software.

Ist mittelfristig geplant ein Issue-Tracking System (z.B. JIRA) online ins Portal zu stellen. Ev. lässt sich damit die zahlreichen Bugs, Must-Have, Nice-to-Have Themen, gem. Projekte zentraler und koordinierter erfassen. Hier im Forum ist ja allerhand los, aber ev. verlieren wir bald die Übersicht.

@Olaf Da hat M$ eben gepennt, dass C# sowas zulässt Und in der Konsequenz muss so ein schlechtes Paradigma, auch wenn die Sprache es hergibt, nicht unbedingt pauschal bei allen Methoden genutzt werden, egal ob es in Phyton-Welt so üblich ist. Beruflich und privat sind mir out-Parameter in C# äußerst selten begegnet. Während der Anwendungsentw. vom Stepper habe ich erstmal die Klasse abgeleitet und umständlich zusätzliche Funktionen geschaffen, um in der Anwendung zahlreiche Werte als Status per Einzeiler zurückzugeben. Ich sehe einfach keinen Sinn, Methoden die jeweils nur 1 Rückgabewert eines einfachen Typen liefern als Prozedure statt Funktion anzubieten.

Also beim Brick-Stepper sehe ich keinen Grund pauschal out-Parm. zu verwenden, dort werden zB. bei GetMaxVelocity oder GetCurrentVelocity jeweils nur ein Wert zurückgegeben. D.d. bei Phyton so möglich oder üblich ist, sollte in der Folge aber nicht für andere Programmiersprachen übertragen werden. Dort bitte Rücksicht auf deren Eigenheiten bzw. Paradigmen nehmen. Im Falle des IMU könnte man aber genausogut eine neue Klasse schaffen bzw. ein Array verwenden, die als Rückgabewert die 5 Floats kapselt.

@photron Ich vermute mal Du bist der neue "Unsichtbare 3" bei Tinkerforge !? Bei den C# Bindings ist mir noch aufgefallen, diese seltsame Verwendung von out-Parametern in einigen Gettern. Ev. könnte man das durch Funktionen und Rückgabewerte ändern. Ich glaube AuronX hat dazu einen neuen Thread eröffnet.

@insidERR Wäre C# eine Alternative ? Wir werden eher mit PHP, Ruby Bindings mittelfristig zu rechnen haben als für VB. Der Schritt von VB.net zu C# sollte nicht so groß sein wie z.B. von VB.net nach C++ oder Java. Für mich war die Umstellung von Delphi zu C# und VisualStudio nicht die Welt. Zumal VisualStudio als kostenlose Express-Version für C# gibt. Die kleinen dokum. Beispiele hier im Portal helfen durchaus um einen schnellen Einstieg in C# zu finden.

Der Slave muss in Betrieb sein bevor du den Master-Chibi anschaltest. Nach der Angabe des Slaves im Master, sollte der Master resettet werden, wobei der Slave schon an sein muss.

Auch richtig, aber die Türen sollten zu Beginn für alles offen sein. Und bitte erst an die Essentials denken und als Bindings anbieten. Im Anschluss daran und damit kann man ja gerne Webservices und sonstige Exoten bauen. Wäre schade wenn Tinkerforge nur innerhalb von Schule, Uni und Hobby-Kiste ernst genommen wird. Hier schlummert durchaus Potenzial für industrielle Lsg. PS: Wenns unbedingt einen Webservice sein soll, dann ev. in REST Architektur und nicht als SOAP-Dienst. http://jnb.ociweb.com/jnb/jnbNov2004.html http://en.wikipedia.org/wiki/Representational_state_transfer

Per Zufall als die Funk-Verbindung zusammenbrach, zuckelte der Stepper munter weiter, auch als der Win-Host abgeschaltet wurde. Für einen Dauerbetrieb hatte ich StepForward (10steps/sec) an den Stepper gesendet. Ich vermute mal, das der Impulsgeber im Brick selber steckt. Ich frage mich nur, ob es nicht möglich wäre, ganze Programmfolgen an den Stepper als einen Block zu übertragen, die dann autonom abgearbeitet werden. Z.B. 1000 steps forward im Anschluss 10 sec stop 2000 steps backwards Fertig und Schluss und warten bis zum nächsten Befehl über USB.

Mag ja sein, dass Win selbst (noch) nicht RT-fähig ist, z.B. für Delphi/C++ gibt es seit einigen Jahren Frameworks, die RT Fähigkeiten ermöglichen: http://www.kithara.de/ Dazu will ich sicher keinen Webservice nötigen, sondern die Bindings für Delphi nutzen. Also wozu einen Webservice ? Kann man die Energie dafür nicht lieber in die Bindings für die 3 wichtigsten Programmiersprachen investieren ? Andererseits kann man Kunden nicht immer dazu zwingen, Betriebssysteme zu verwenden, die für mich als Entw. praktischer sind. Aber nur um den größten gem. Nenner für alle zu finden und pauschal ein Webservice zu nehmen, für die Ansteuerung von Hardware-Kompon. wie die Bricks und Bricklets ist einfach zu grenzwertig. Und zur poppeligen Ansteuerung von Hausautomation oder Wetterstationen braucht es nicht unbedingt WinCE oder Linux.

@Nifity, wenn ich Olaf richtig verstanden habe - siehe Thread BrickD für Android - wird man spätestens zum WLAN Modul auf den BrickD verzichten. Ist so ein Long Polling Call zuverlässig genug für Echtzeitverarbeitung von Daten ? Und werden durch das Soap-Protokoll hier nicht unnötig ein Datenoverhead (Envelopes) geschaffen ? Und macht sich das so gut bei der Performance ?

Nifty, inwiefern soll ein Webservice (WS) die Programmierung in jeder beliebigen Sparche unterstützen ? Ein WS erfordert einen Host ? Welche Soft- oder Hardware soll das übernehmen ? Und wie unterstützt der WS die Callbacks ?

Eine Command-Line-Utility würde als Alternative gut reichen, um die Sprachen zu unterstützen für die es noch keine Bindings gibt. Zum Steuern von digitalen Kameras ist sowas recht üblich: http://s10sh.sourceforge.net/; gphoto Nicht zu verachten exiftools, auch eine sehr leistungsf. shell.

Prinzipiell sicher eine gute Sache eine Software zu entwerfen., die es Laien ermöglichen soll, die nötigen Projekte für die Bricks nach dem Lego-Prinzip zu entw. Aber m.E. wird das an seine Grenzen stoßen, wenn es darum geht unterschiedliche Betriebssysteme, proprietäre Schnittstellen/Frameworks, bzw. Hardware oder Treibergeschichten zu unterstützen. Für so ein kleines Startup-Unternehmen wie Tinkerforge ev. zu ambitioniert. Lieber bitte die Energie in die Neu/Weiterentwicklung der Bricks, Bindings und Firmware investieren. Eine pfiffige Gehäuse-Lösung für die Bricks und Bricklets ist auch noch so eine Baustelle.

Bei mir war es die Meldung in Golem, Dez.2011 http://www.golem.de/1112/88320.html

@Olaf Prima, darauf können wir sicher warten ! Denkst Du bitte aber auch daran, den vermutl. Bug wg. nicht eingeschalteter Slaves im Funk-Chibi-Netz zumindest ein Feedback zu geben. Ich hatte Dir letzten Montag eine kurze Mail geschreiben, dass der Master-Chibi im Viewer nicht zu sehen ist, falls einer der Slaves nicht eingeschaltet ist.

Ohne BrickD ? Habe ich mich verlesen Das wäre genial ! Gilt das auch für einen WinPC ?

Keine Ahnung ob schon bekannt, z.K.: http://www.heise.de/hardware-hacks/artikel/Angetestet-TinkerForge-Elektronik-Baukasten-1500925.html

Olaf, ist schon klar. die Hardware Einschränkungen waren nicht bekannt, und ev. auch bei anderen Tinkerforge-Kunden. Ein 2.PC als Host scheidet aber aus, falls man ein mobiles Projekt anstrebt. Bestes Beispiel heute ist von dem Kamerahersteller Nikon eine neue DSLR D3200 auf den Markt geworfen worden, die einen 60 Euro teuren WLAN-Adapter als Zubehör anbietet, der es ermöglicht ausschließlich per Smartphone oder Android Tablet die Kamera via remote zu steuern. das ist klasse aber im Verbund mit Tinkerforge-Module derzeit als mobile Anwendung unpraktisch.

Wenn die Einstellungen nix bringen, könntest Du alternativ in den Projekt-Properties einen sogen. Post-Build-Event festlegen. Dort trägst Du z.b. typische DOS xcopy befehle ein um bestimmte Dateien von A nach B zu kopieren etc...

Hi swws, Klasse, super Umsetzung. Welche Lampen verwendest Du ? Ich setze für mehrtägige Zeitraffer Blitze ein. Nic

Danke Nifty, jetzt verstehe ich. Bei der Fülle von Android-TabletPCs bietet es gerade zu an, diese zum Steuern, Messen und Anschauen der Tinkerforge-Module einzusetzen.