Nic

Prinzipiell spart man also nur die Master+Chibi-Kombination, die als Transeiver am PC verbunden war.

Verstehe ich das richtig du möchtest nur mit 1 Servo Brick per Impuls Ventil auslösen und in einem Folgetakt die Kamera ?

Ich frage mich auch ob das exakte Delay mit Genauigk. von 0.1ms so zuverlässig auf einem Windows-system sein kann...

Wenn ich Markus richtig verstehe möchte er auf das Event des Ventils mit einer zeitl. Verzögerung von z.B. 231,3 ms genau die Kamaera auslösen.

Welches Betriebssystem soll den benutzt werden ?

@Paul

Also ich arbeite auch an einer Kamerasteuerung durch Bricks/Bricklets und habe über die Funk-Erweiterung keine Probleme. Durch die WLAN-Extension soll die direkte Steuerung ohne BrickD möglich sein. Allerdings brauchst Du auch hier ein Hardware-Gerät das das Interval steuert und die Kamera auslöst.

Soll der Zeitraffer über Std. oder gar Tage dauern ?

Welche Schnittstelle zur Kamera nutzt Du ? Proprietäre Treiber des Kameraherstellers über Windows, oder gPhoto unter Linux ? Auch so, sollen die Bilder auf der Kamera verbleiben oder sofort auf ein Notebook übertragen werden ?

Interessant, geht es hier um Hochgeschwindigkeitsaufnahmen, z.B. von einem fallenden Wassertropfen ?

http://www.cognisys-inc.com/stopshot/stopshot.php

Ich bezweifel, dass die derzeitige Brick-Hardware und Design in der Lage ist µs genaue Steuerung zuzulassen. Wobei das Timing-Problem Echtzeitfähigkeit des Betriebssystems voraussetzt.

Ev. sieht das anders aus wenn die OnDevice-Programmierung möglich ist: http://www.tinkerforge.com/doc/Programming_Interfaces.html#pi-hlpi

Die RPY Ergebnisse orientieren sich nach dem NS-Magnetfeld der erde, wonach soll sonst die Winkelabweichung sich beziehen. Um das Kalibrieren kommt man nicht herum. Interessant wirds wenn unterschiedl. Drehzahlen gefahren werden, dann dürfte die Kalibrierung ev. verschieden sein.

Wenn es irgendwie geht, so flexibel wie möglich das WIFI gestalten.

Ich hatte in der Verg. öfters die Situation, z.B. den Stepper unter, dann wieder über den Chibi zu stecken. Nur on the top schränkt die Stackfreiheiten zu sehr ein. Und das der Stecker bündig zur Platinenkante sein soll, wäre prima.

Da i.d.R. das Konstruieren und Programmieren doch weit mehr Zeit verschlingt, habe ich kein Problem, 1-3 Tage -in Ausnahmen auch mal 1 Woche oder länger- zu warten. Wenn es u.a. auch der Qualität dient, um so besser.

Um Missverständnisse vorzubeugen, würde ich den Kunden ein Feedback geben, falls mal die Lieferung etwas länger als geplant dauert. Also z.b. als Message hier im Forum, Hint im Shop "Zur Zeit ist mir einer Wartezeit von x Tagen zu rechnen..." oder im Blog. Ich schätze zuverlässige, rechtzeitige Infos und die damit result. Planbarkeit mehr.

z.K.

http://www.golem.de/news/tinkerforge-im-test-elektronik-zum-stapeln-1205-91624.html

Danke Jan,

aber das ist mir erstmal zu umständlich bei dem lauen Interesse.

Aber mit dem offiziellen Delphi-Bindings ist ev. bald zu rechnen Den Anfang dazu habe ich schon mal geleistet...

SVN und Jira Erfahrungen.

Gab es oder gibt es hier im TF-Portal jemals eine kurze Einweisung wie wir Github im Hinblick auf Mitarbeit beim Source-Code für TF-Produkte zu benutzen haben ?

Sicher kann ich mir die Online-Hilfe reinziehen, aber das klärt nur die techn. Benutzung von Github, aber wie soll z.B. die Source-Code Formatierung aussehen, welche Ansprüche hat man zwecks Organisation und Handhabung der Sourcen für die TF-Produkte etc...

Und wenns dann mal mehr Aufklärung gegeben hat, welchen der Account-Arten von Github habe ich zu wählen um für die TF-Gemeinde "produktiv" zu sein ?

Reicht der kostenlose OpenSource Acc ? Oder sind damit Einschränkungen im TF-Repos zu rechnen ?

Wäre es gar möglich zwecks guten Kundenservice die TF-Accounts gleich auch autom. bei Github anzulegen ? Sozusagen Github transparent im TF-Portal ist.

Und nicht nur was NEUES kommen könnte oder soll oder möchte, sondern wann die schon vor laaaaanger Zeit gemeldeten Bugs gefixt werden und die Erweiterungswünsche -absichten zu den schon existierenden Soft- und Hardwareprodukten

Für den Github brauche ich einen eigenen Account ?

@TF

Gibt es auf Github ein Repository wo ich die Prototypen ev. ablegen kann ?

Für ein Update von 1-2 Klassen möchte ich ungern ein neues Post mit Attachment ablegen.

Nur so ein Gedanke warum steht vor und nach dem enumerate ein usleep ?

Du schreibst der Slave steht im Nachbarzimmer... also ich hatte Empfangsprobleme wenn ne dicke Betonwand und der Durchgang nur im die Ecke war, obwohl Luftline höchstens 2m.

Da hast Du recht, danke für Dein Feeback !

Dann würde das etwa so aussehen:

begin
    result := false;
    writeLock.Acquire;
    job:=CreateEvent(nil,false,false,nil);
    try
      try
        tick:=GetTickCount + DWord(timeout);
        while (true) do begin

          writeLock.Acquire;
          if (Count > 0) then
            break;
          state := MsgWaitForMultipleObjects(1,job,false,timeout,QS_ALLINPUT);
          writeLock.Release;

          if (closing) or (timeout < Timeout_Infinite) or (state=WAIT_TIMEOUT) then begin
           result := false;
           exit;
          end;
          timeout := tick-GetTickCount;
        end;

        p:=queue.Pop;
        item := p^;
        dispose(p);

        result := true;
      except on E: Exception do
        raise Exception.Create('TBlockingQueue.TryDequeue:' + e.Message);
      end
    finally
      CloseHandle(job);
      writeLock.Release;
    end;
end;

Was ist aber mit dem WriteLock zu Proc-Begin bzw. Ende ?

Anfangs hatte ich die CriticalSection (WriteLock) zu Beginn und Ende von TryDequeue eingetragen, aber das führte dazu, dass der HauptThread, der nur dort reinläuft, das Enqueue vom Recv-Thread aber solange blockiert, bis die 2.5 sec abgelaufen sind. Das führte dazu, adss nie ein Device geadded wurde.

Deshalb der Lock erst später wenn von der Queue gepoppt wird. Innerhalb der Zeitschleife wird aber auf das geblockte Count geprüft und zur Laufzeit wird dort die Count = 1 aber festgestellt.

Das lock(writeLock) in C# entspricht m.W. den Acquire und Release in Delphi

writeLock.Acquire;
try
...
finally
  writeLock.Release;
end;

Das Monitoring wird in Delphi 7 noch nicht unterstützt, mir ist allerdings noch ist ganz klar wie man das durch D7 Bordmittel alternativ lösen könnte. Aber ich schaue mir mal Deinen Ansatz heute abend genauer an. Danke fürs Code Review.

Hmmh, ich sehe gerade das die Funktion Count in den C#Bindings überhaupt nicht benutzt wird, es wird immerzu das Property queue.count abgefragt, hat das ev. mit der o.g. Situation zutun ?

Ich werfe mal in die Arena einen Entwurf (Delphi7 Prof., seit 2002) zumindest der kompletten Haupt-Klasse IPConnection, ohne die nix geht und die Komponenten BrickStepper(unvollständig) und BrickletIO4 (vollständig).

Basierend auf der C#-Implementation, wurde versucht die Struktur weitgehends ähnlich umzusetzen. (Ausnahme z.B. die Delegates in C#). Hinzugefügt habe ich einige Basis-Klassen bzw. Typen oder Records, wo es sich u.U. anbietet den Code zu vereinfachen, um z.B. Redundanzen zu vermeiden.

Ob das implem. threadsichere FIFO-Pattern (BlockingQueue) so zuverlässig ist wie in C# oder Java sollte als erstes begutachtet werden.

Die Units lassen sich prima zu einer x32-Exe compil. und zumindest auf einem i5,Win7x64 ausführen.

Ob es mit älteren bzw. jüngeren Delphi-Versionen als D7 compilierbar ist, muss geprüft werden.

Es wird kein Anspruch auf Vollständigkeit erhoben noch die lehrbuchmässige Umsetzung von Delphi-Code.

Das alles hat experimentellen Charakter und sollte erstmal nur von erfahrenen Delphi-Entw. in einem Code-Review gesichtet und getestet werden. Verwendung des Source-Codes also auf eigenes Risiko !

entwurf.zip

Hilfreich wäre ein Callback in den Bindings, der darüber informiert das die Signalstärke unterschritten wird. Ähnlich zum CallbackUnderVoltage im Stepper-Brick.

Noch ne Ergänzung zum möglichen Akku-Brick und die Frage ob es im Brick-Formfaktor (< als 40x40) leistungsfähige Akkus geben könnte und wie lange die dann halten sollen:

http://www.elektor.de/elektronik-news/usb-akku-brennstoffzelle-bringt-14-fache-laufzeit.2160693.lynkx

Aha, das habe ich mir auch schon gedacht, aber dann wird er ev. durch die Motoren und deren Magnetfeld, wenn diese unterschiedlich angesteuert werden, Einfluß auf den Magnetometer bekommen !?

http://www.tinkerforge.com/doc/Hardware/Bricks/IMU_Brick.html#imu-calibration

@AuronX

Würde es die Arbeit erschweren, wenn in den Bindings, neue Klassen bzw. Typen hinzukommen, z.B. habe ich für die Transfer-Pakete einen eigenen Typen geschaffen, der sofort mit FktId, StackId und in der passenden Dimension initialisiert wird. In sämtliche Funktionen wird für meinen Geschmack immer die gleiche Paketstruktur redundant zusammengebaut.

Verstehe, kann mir aber jemand erklären auf welches Bezugssystem die RPY-Winkel ermittelt werden ?

Worauf referenziert sich der IMU, jetzt ist alles im Lot und er ist waagerecht ausgerichtet ?

@photron

Die Delphi-Bindings sind von Hand strukturell auf Basis der C#-Bindings erstellt. Auf Code-Generator ist soweit also nur indirekt Rücksicht genommen. Die Brick-Hauptklasse der IPConnection ist quantitativ komplett, Brick-Stepper erstmal nur die wichtigsten Fkt. wie DriveFor, Backw, Enable/Disable etc.

Ich schlage vor, ich lasse mein Ergebnis zuerst mit Hilfe der Delphi-Experten - ev. hat haentschman

Interesse - in einem Code-Review Korrektur lesen. Und stellen anschließend dann eine erste Beta ins Wiki, bzw. Forum oder wo auch immer.

Die Arbeit für Dich würde sich erstmal dann nur noch darauf beschränken, die Bindings der übrigen Bricks und Bricklets hinzuzufügen, und das in den Code-Generator einzubinden. Wenn ich mit den Delphi-Bindings also wie o.g. Unterstützung von Userseite bekommen könnte, wäre eine Beta nach dem WE möglich.

Es wäre vorteilhaft, wenn wir auch eine Übersicht hier im Forum hätten, die Hinweise auf Programmierkenntnisse der User zeigt. Ev. innerhalb im Profil festlegbar !?