[Master-Brick] Timer für Bricklets ?

IO4, IO16 oder DualRelay haben im Gegensatz zu den Bricks keinen Microprocessor.

Ev. habe das Brick und Stack Prinzip noch nicht so richtig verstanden: Ist es möglich, daß ein Master mit einem seiner verbundenen Bricklets kommunizieren könnte, d.h. wenn die FW entsprechend erweitert wäre ?

Ich denke da an den Anwendungsfall einer Zeitschaltuhr (Einschalten einer Lampe zu einem best. Zeitpunkt etc.) oder das timergesteuerte und automatisierte Auslösen einer Digitalkamera wie z.B. bei Zeitraffer. Letztere könnte man natürlich für die Interval-Fkt. der Kamera nutzen, aber diese ist oft begrenzt auf max. 999 Auslösungen.

Wäre es möglich einen Timer-Feature ins Master-Brick zu integrieren, das die Ausgänge der o.g. Bricklets automatisiert und dezentral vom Host-PC steuert ?

Du redest von einem Monoflop für die drei? Oder meinst du jetzt was anderes?

Monoflop ? Ja, wenn ich auch nicht ganz sicher bin, ob der Monoflop exact das Gleiche meint.

Um kurz zu machen, ich nehme den IO4 um meine Digitalkamera im Interval auszulösen. Bis jetzt löse ich das über eine kleine Implementation in Delphi. Nachteil dafür brauche ich immer den Host-PC.

Du hast vor kurzem eine Zeitdehnung im Stepper eingebaut. Für Langzeit-Zeitraffer über Tage ist das jetzt ideal. Eine prima Ergänzung dazu, wäre ein PC-unabhängiger Timer zum Schließen eines Ausgangs-Pins am IO4 und damit Auslösen der Kamera.

Ah, also ein "wiederkehrender Monoflop". Sowas ist technisch auf jedenfall möglich (solange wir in der 1ms Auflösung bleiben).

Einmal zur Erklärung: Auf den EEPROMs auf den Bricklets sind Plugins gespeichert die von den Bricks beim starten eines Stacks eingelesen werden. In diesen Plugins gibt es eine "tick_task" die von dem Brick einmal pro ms ausgeführt wird. Maximale Ausführungszeit ist 100us. Alles was man damit machen kann ist auch möglich.

Ich habs mir mal auf die TODO Liste geschrieben, gucke ich mir an wenn ich mir die Monoflop Geschichte für die IOs angucke.

Maximale Ausführungszeit ist 100us

Was heißt das genau ?

Zwischen dem Schalten des Ausgangspins im IO4 von High wieder zurück auf Low, damit der Kameraverschluss überhaupt auslösen wird, braucht es i.d.R. eine Pause von durchschn. 75ms.

Die Auflösung von 1ms ist völlig ausreichend, ich vermute bei Funkbetrieb ist diese etwas geringer!?

Für Langzeit-Zeitraffer über die Gesamtzeit von Tagen löse ich die Kamera z.B. alle 5 Minuten aus.

Habe gerade das neue Feature Monoflop im DualRelay angeschaut: genau sowas wäre auch nützlich im IO4/16. ABER mit dem Zusatz, das sich das autom. wiederholt, also z.B. so:

SetMonoflop(byte pin, bool state, uint time, uint interval, uint loops)

Beispiel:

interval in sec=300

loops = 2000; -1 für unendlich

, d.h. der Monoflop wird 2000 mal alle 5 Minuten ausgelöst

Ev. noch durch eine Fkt. StopMonoflop ergänzen.

Maximale Ausführungszeit ist 100us

Was heißt das genau ?

Das Brick führt ja für alle angeschlossenen Bricklets das Event jede Millisekunde aus und viele andere Sachen.

Das heißt du musst definieren wie lange diese Tätigkeit dauern darf, weil deine Zeit ja insgesamt begrenzt ist. Das wäre ein Problem wenn du jeden Tick eine komplexe Berechnung machen möchtest, weil diese möglicherweise länger dauern würde als die 100 µs. Ich denke aber im aktuellen Fall spielt es aber keine Rolle.

Genau richtig was AuronX sagt.

Für deinen Fall würde man einfach von high auf low setzen, dann einen Zähler nehmen der bis 75 zählt und dann wieder von low auf high (oder andersrum).

Wie gesagt, gucke ich mir an. Hab mir vorgenommen einen Tag pro Woche zu investieren um neue API zu implementieren, die TODO Liste dafür ist ein wenig angewachsen . Letzte Woche hab ich ja schon ein bisschen API hinzufügen können.

Das Brick führt ja für alle angeschlossenen Bricklets das Event jede Millisekunde aus und viele andere Sachen.

Das heißt du musst definieren wie lange diese Tätigkeit dauern darf, weil deine Zeit ja insgesamt begrenzt ist. Das wäre ein Problem wenn du jeden Tick eine komplexe Berechnung machen möchtest, weil diese möglicherweise länger dauern würde als die 100 µs. Ich denke aber im aktuellen Fall spielt es aber keine Rolle.

Verstehe. Und für die Wiederholbarkeit oder Intervalometer gibt es da keine Einschränkungen ?

Für deinen Fall würde man einfach von high auf low setzen, dann einen Zähler nehmen der bis 75 zählt und dann wieder von low auf high (oder andersrum).

Nicht ganz richtig: Der Verschluss meiner Nikon Kamera wird beim Setzen auf High geöffnet und bei Low wieder geschlossen. Der Verschluss reagiert aber nur dann, wenn zw. High und Low ausreichend Latenz ca. 75ms gibt.

Bei Bulb oder Langzeitbelichtung gilt das prinzipiell genauso, nur wird dann z.B. bis in den Minutenbereich gedehnt.

Das heißt sozusagen, dass du mindestens zwei Zeiten brauchst, richtig?

HIGH
...80 ms (etwas mehr als 75ms ^^)...
LOW
...5 min...
--> wieder von vorn

bzw. für bulb dann villt eher sowas wie

HIGH
...60 min...
LOW
...1 min...
--> wieder von vorn

Letzteres ist jetzt frei erfunden um Nachts mehrere Bilder von einem sich bewegenden Sternenhimmel zu machen ^^

Letzteres ist jetzt frei erfunden um Nachts mehrere Bilder von einem sich bewegenden Sternenhimmel zu machen ^^

Ahh, da sind wir wieder beim Stacking von mehreren Bildern

Ja, richtig 2 Timer, einen für die High-Low-Latenz und den zweiten für das Interval. Ist das im Plugin machbar ?

Wenn nein, war ja mein erster Gedanke den Interval-Timer über den MPU vom Master zu steuern.

Disclaimer: Ich habe noch nie ein Plugin geschrieben und habe nur Forenwissen was das konkret angeht.

Ich denke das sollte im Plugin machbar sein, für eine offizielle TF-API muss man natürlich schaun, dass es auch "allgemein" nutzbar ist. Aber mindestens ein eigenes Plugin nur für dich wäre wohl auf jeden Fall möglich. Es passiert ja nicht sehr viel Magie, man muss sich zwei Startwerte für den Counter merken und halt gerade immer einen Counter runterzählen und bei 0 öffnen bzw. schließen.

Du bist gerade dabei mich dafür zu motivieren das erste Mal ein eigenes TF-Plugin zu schreiben und das obwohl ich C wie die Pest hasse

Mir geht es genauso, C ist im Vergleich zu C#, Java und Delphi "etwas" schwerer lesbar und verdaulich

Gibt es eigentlich schon Beispiele hier im Portal wie so ein Plugin strukturell aufgebaut sein muss, damit dieser problemlos vom Brick ausgeführt werden kann ?

Also ich meine NICHT C-Syntax sondern Vorgaben durch das TF-Framework.

Ich glaube das soll noch im Rahmen der on-device-API dokumentiert werden. Ich würde bisher auch nur die existierenden Plugins anschauen um das rauszubekommen ^^