Nic

TBaseArray = array of byte; Worauf willst Du eigentlich hinaus ?

Yes, und genau deshalb frage ich nach, denn die Tage sind um. Aber die sind immer noch nicht da oder wurde nur vergessen, aus der Shopseite vom Stepper das Ausverkauft wieder rauszunehmen !?

Wieso doppelt ? In meinen Delphi Bindings nenne ich es TBaseArray und nicht TByteArray. Die wichtigsten Typen, die in allen Klassen verwendet werden, kommen in eine eigene Unit BaseData. BaseData.pas

Doch, den TByteArray gibt es schon. Ich würde i.d.R. aber immer nur eigene Typen deklarieren und nur diese (Ausnahme natürl. wenn einfache Standard-Typen reichen) in den Prozeduren verwenden. Falls der Typ doch mal geändert wird, muss nicht der gesamte Code durchpflügt werden.

Holla, das gute Stück ist ausverkauft, wollte gerade eine Bestellung machen, sehe aber der ist nicht lieferbar. Wann wird der Brcik wieder verfügbar sein ?

Verstehe ich nicht, in D7 deklariert man zu Beginn der Unit i.d.R. die Typen, die später benutzt werden. Siehe meinen Prototypen der Delphi-Bindings. Warum sollte das noch restriktiver in FPC sein ? Im Prototypen hatte ich die meisten Typen in BaseData, also in eine seperate Unit verschoben. Ev. sammelst Du die Typen gemeinsam in einer Unit. Im Allgemeinen hatte ich mit den Restriktionen durch Delphi wenig zu kämpfen; Ausnahme vielleicht die Device-Klasse in eine eigene Unit zu verlagern, aber auch das klappte. In diesem Forum werden recht professionell auch andere Pascal-Compiler Probleme behandelt: http://www.delphipraxis.net/forum.php Woher kennt Dein Compiler eigentlich den Typen TByteArray z.B. in der IpConnection ?

dynamic für Speicheroptimierung, virtual Geschw.optimiert. I.d.R. virtual.

Ein paar Anmerkungen zur Preview 1: Im LEConverter würde ich statt array of byte den deklarierten Typen TByteArray verwenden. Falls die Brick-Klassen und Prozeduren später ableitbar sein sollen, müssen im Vorfahr hinter jeder Prozedur das Keyword virtual oder dynamic angegeben werden. So ist das zumnindest in Delphi 7.

Hab es getestet indem ich meine Delphi-Bindings erweitert habe. NewState klappt prima, AllData eigentlich auch nur sehe ich zumindest im C# Binding (das ich immer als Referenz zur Migration nehme) einen Fehler beim Getter der Period-Time. Diese ist dort als Procedur und nicht als Funktion implm. und gibt keinen Rückgabe-Wert. (siehe Screenshot) Ich habe das im Delphi-Bind. korrekt impl. und zur Laufzeit läuft das zumindest bei mir prima PS: Was ich ganz bestimmt nicht migrieren werde ist die Fkt. GetChipTemperature; daß ist so interessant wie einer Waschmaschine beim Schleudern zuzuschauen

Die 1.2.2 habe ich benutzt, sowohl auf dem Master wie auch den Slaves.

Ich weiß die Todo-Liste ist groß und die Zeit zu kurz, aber dieser Bug ist einige Monate alt, seitdem ich den Fehler gemeldet habe (so um April) http://www.tinkerunity.org/forum/index.php/topic,276.msg1395.html#msg1395 und über Mailaustausch genaue Beschreibung. Benutze 3 Slaves, die im Master-Chibi in der Liste (1,2,3..) deklariert sind. Ist Salve 2 nicht eingeschaltet, bricht der Brick die Suche nach weiteren Slaves ab und es wird zu Nr.3 keine Funk-Verbindung aufgebaut. Ev. ist das nur ein einfaches Schleifen-Problem. Stelle ich Nr.2 wieder an und löse das praktische SW-Reset am Master-Chibi-Brick aus, bekomme ich Verbindung zu allen Slaves. Auch in der aktuellen FW ist noch nichts gefixt. Ist zwar kein Show-Stopper, aber es ist auf Dauer nervig, die Liste bzw. Slave-Adressen zu ändern. Wenn möglich bitte lösen.

Nicht ersetzen, eher ergänzen; also flashen mit Viewer oder SAM-BA. Falls es mal mit dem Viewer überhaupt nicht klappt, hilft ev. noch das SAM-BA Utility alternativ. Das würde ich nicht unterschlagen.

Zuallererst den BrickD Service im Betriebssystem installieren: http://www.tinkerforge.com/doc/Software/Brickd.html#brickd

Ich habe jetzt zum ersten Mal statt SAMBA über den Viewer geflasht. Eine enorme Verbesserung und Erleichterung für den User. Klasse !!! Nur eine Kleinigkeit: Beim Download-Dialog der FW würde ich noch vorher prüfen ob eine aktive Webverbindung vorliegt, ansonsten bleibt der Dialog dauerhaft aktiv und man wartet ohne Ende.

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.

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.

Also ich mache die Bestellungen immer über den Shop, bisher gab es dort keine Möglichkeit WIFIs zu bestellen. Was es dort nicht gibt, kann man auch nicht bestellen und hat später keinen Grund sich zu grämen

Verstehe. Und für die Wiederholbarkeit oder Intervalometer gibt es da keine Einschränkungen ? 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.

Habe ich das irgendwie verpasst ? Wo und wann im Shop wurden die WIFI-Extension zur Bestellung angeboten ?

Nun, aus den vielen Forenbeiträgen und aus http://www.tinkerunity.org/forum/index.php/topic,451.msg3127.html#msg3127, ist zu entnehmen, dass es u.U. als nächstes das WIFI-Modul geben wird. Einfach mal per Suche recherchieren... Gibt also keinen Grund Frust zu schieben, und wenn der Porsche in der heimischen Garage mal ein bissl länger ohne Räder stehen muss, who cares Bei mir in der Garage steht nur ein Fahrrad mit Platten, nun dann habe ich Zeit am WE mal wieder etwas zu basteln. Aber bei dem Wetter fällt das schwer...

Erstmal nur zu 3) allgemein muss man einen Callback nicht registrieren, dann nerven die auch nicht Zumindest gilt das für die C# Bindings und in meiner Delphi-Implementation. Ich vermute, beim o.g. handelt es sich um Perl-Bindings. Sind die wasserdicht getestet ?

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.

@webster7567 Wie wolltest Du die Seilkamera mit den TF-Teilen überhaupt steuern ? Von welchen Entfernungen sprechen wir hier ?

@Markus: Sag mal, um welche Kamera handelt es sich hier ? Ist das eine mit Zeilen- oder Flächensensor ?

Nun, ich bin hier schon eine Weile dabei und erinnere gerne die Newbies, daß TF ein kleines Startup-Unternehmen ist mit gerade mal 3 Mann Besetzung. Zum Lösen von Bugs, neuen Features und neuer Hardware hier mit Sportwagen-Geschwindigkeit zu hoffen, ist doch etwas illusionär.