Nic Geschrieben July 6, 2012 at 10:11 Share Geschrieben July 6, 2012 at 10:11 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 ? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 6, 2012 at 10:30 Share Geschrieben July 6, 2012 at 10:30 Du redest von einem Monoflop für die drei? Oder meinst du jetzt was anderes? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 6, 2012 at 11:05 Autor Share Geschrieben July 6, 2012 at 11:05 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 6, 2012 at 11:21 Share Geschrieben July 6, 2012 at 11:21 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 6, 2012 at 12:01 Autor Share Geschrieben July 6, 2012 at 12:01 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 6, 2012 at 14:14 Autor Share Geschrieben July 6, 2012 at 14:14 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 6, 2012 at 16:24 Share Geschrieben July 6, 2012 at 16:24 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben July 6, 2012 at 21:48 Share Geschrieben July 6, 2012 at 21:48 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 7, 2012 at 08:41 Autor Share Geschrieben July 7, 2012 at 08:41 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 7, 2012 at 09:05 Share Geschrieben July 7, 2012 at 09:05 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 ^^ Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 7, 2012 at 09:12 Autor Share Geschrieben July 7, 2012 at 09:12 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 7, 2012 at 10:20 Share Geschrieben July 7, 2012 at 10:20 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Nic Geschrieben July 8, 2012 at 08:44 Autor Share Geschrieben July 8, 2012 at 08:44 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben July 8, 2012 at 11:43 Share Geschrieben July 8, 2012 at 11:43 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 ^^ Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.