Nic

Den Pascal-Bindings fehlt noch die Docu/Kommentare im SourceCode. Da kann man eigentlich analog zu den C#-Bindings verfahren und deren Doku ohne Einschränkungen in die Pascal-Bind. kopieren. Ab Delphi2006 wird XML-CodeDocu. wie in .NET unterstützt.

Aha, verstehe: http://stackoverflow.com/questions/556405/what-do-real-user-and-sys-mean-in-the-output-of-time1

verstehe nicht, was soll das heißen: real, user , sys ?

Wenn es geht, bitte die FW vom Master und Extension dahingehend zu erweitern, daß analog wie zum Steppper oder IMU ein neuer Callback GetAllData eingebaut wird: eine Zusammenfassung aller relevanten Daten GetStackVoltage, GetStackCurrent, Get-Chibi/WIFI-SignalStrength und Get-Chibi/WIFI-ErrorLog. (GetChipTemp. muss nicht sein ) Zwecks Betriebsmonitoring bzw. -sicherheit m.E. sehr hilfreich.

Also ich fand die Erklärung recht gelungen. Sehr gut, der Hinweis über "saubere" Programmierung bzw. Verwendung von vernünftigen Design Patterns. Damit wird der Code nicht nur übersichtlicher, und wartbarer sondern auch u.U. performanter. Keine Sorge, daß hier zuviel Infos rüberkommen. Im Forum wird m.E. eher viel zu wenig gepostet, als zu viel Keine Ahnung wie das interne Verhalten beim Delphi oder FPC ist, aber die Compiler erzeugen ohne Umweg von Byte-Code direkt platform-abhängigen nativen Code. Ich schätze mal ähnlich des C-Compilers, aber mit dem Overhead der VCL, Kapselung der WinAPI etc. PS: Habe die Zeit von der Fkt. GetChipTemperature kabelgeb. in Delphi gemessen, ich komme im Durchschn. auf 2ms auf einem i5,Win7 x64,8GB. Also die 1.5ms mit Java (abgesehen von JIT Optim.) entspricht kaum der Regel zur Laufzeit, ob es mit C dauerhaft erreicht möchte ich auch stark bezweifeln. Das Betriebssystem und seine zahlreichen bekannten und unbekannten Hintergrund-Prozesse/Threads dürften da Einfluß nehmen.

Ich muss aber dazu sagen, dass nur im BrickViewer zeitweise nach einem Master-Chibi Reset, mal der Slave-Master vom IO4 nicht gefunden wurde, bzw. mal nur der Ambient oder nur der IO4 geadded wurde. Anbei die Fehler-Logs. main.exe.bes.log main.exe.bes2.log

Ich bin kein Java-Experte, was meinst Du damit ?

Vorschlag um das FW-Upgarde der Bricklets narrensicherer (für solche Typen wie mich ) zu machen, die UID aus der Enum-Liste in die DropDown-Box mit verfügbaren Bricks mitzuübernehmen.

Alles Käse An der FW, brickD, viewer hat es m.E. nicht gelegen. Ich vermute mal ich habe das System unter schlechten Bedingungen ans Limit gebracht; ich steuere ausschl. über Chibi die Anwendung: Am 1. Slave-Stack ist + Stepper plus AllDataCallback bei Period 200ms, PositionReached, StepperNewState Am 2. Slave-Stack ist der + IO4 plus CallbackInterrupt mit DebouncePeriod von 100ms + AmbientLight plus IlluminanceCallback bei Period von 200ms, der Ambient wurde erst vor kurzem hinzugefügt Wenn der IO4/Ambient und Stepper Stack nicht über Chibi mit dem PC sondern über das USB-Kabel verbunden sind, werden die Stacks rasch erkannt. Über Chibi dauert das natürlich spürbar länger. Erst im FormShow Event des Anwendungsfensters erzeuge ich die IPConnection. Rufe anschließend Enumerate auf und erzeuge und adde Stepper, IO4 und Ambient erst beim Enum-Callback. Das IO4 Bricklet muss dabei allerdings über einen Extra-Timer zeit-verzögert erzeugt und hinzugefügt werden. Der Ambient kann im Gegensatz sofort geadded werden. Ansonsten bekomme ich den IO4 nicht in die Anwend. Habe die Periods der Callbacks auf 500ms reduziert; eigentl. Quatsch durch den Flaschenhals Chibi schnellen Datendurchsatz zu erwarten.

Die Zeiten gelten hier aber nur bei Kabelverbindung ! Ich messe über Chibi-Funknetz mit GetChipTemp-Call vom Stepper und Delphi-Bindings über Win7x64 eine Dauer zw. ca. 80 bis 160ms, im Mittel etwa 100ms.

Das dürfte verzinktes Stahlblech sein !? Mir würden Lochrasterplatinen mit 5mm in kleineren Abmessungen und aus Kunststoff praktischer vorkommen Bei RS gibt es zumindest Platinen mit RM 2.5mm: http://de.rs-online.com/web/p/prototyp-entwicklungsplatinen/4632819/ http://de.rs-online.com/web/p/prototyp-entwicklungsplatinen/5280661/

Der derzeitige Stand womit es problemlos klappt: Master 1.2.4, IO-4 1.1.0, und brickD 1.0.8 Mit Master 1.2.4, IO4 1.1.1 und BrickD 1.0.9 hatte ich Probleme. Mache ich. Master-Chibi am PC 1.Slave mit Stepper, StepDownSupply, 12V Akku 2.Slave mit IO4 und Ambient, direkt per USB-Kabel an 5V Akku

Mit Java nahe am theoretischen Limit ?! Boah , mit welcher Hardware und Betriebssystem. Kann das kaum glauben, mit einer nativen Sprache wie C ja, aber mit einer JVM

Programmcode wird etwas schwierig, dass ist schon sehr umfangreich, und kabselt die Delphi-Bindings mit zusätzlichen Callbacks. Master mit der aktuellen 1.2.4, der Brick Daemon und die FW mussten zurückgesetzt werden, und dann funzt alles wie vor dem Upgrade. Ich überlege wie ich das so dokum., daß man zumindest den Unterschied sieht, ev. mach ich ein Demo-Video, einverstanden ?

Das habe ich mir schon gedacht, aber denkt mal an ein Modul, womit man direkt Schalter abfragen kann ohne Umweg BrickD und Betriebssystem. Ahh, 38 Euro, das mit dem Pack of 5 habe ich übersehen, danke, muss zum Augenarzt...

Hmmh, ich glaube er meint die Zeit für 1 Function-Call getTemperature oder so ähnlich

Ich lese hier http://www.gainspan.com/gs1011mees mit Überraschung, dass das Teil über GPIOs verfügt, könnte man die ev. im geplannten WIFI-Modul für den User anbieten. Ich denke da an div. Steuerungs und Endlagenschalter: http://www.tinkerunity.org/forum/index.php/topic,593.0.html PS: Sehe gerade den Preis von $190 nur für das Modul da dürfte der spätere Endpreis grob bei mind. 150 Euro liegen ? Das dürfte für die meisten hier zu teuer sein...

Ich denke hier mehr an die Möglichkeit der Mobilität und gewisser Unabhängigkeit von Kabeln. Vorausgesetzt man betreibt eine Funk-Verbindung dazwischen. Man denke nur mal daran bei Anschluss des kleinen RaspPi oder eines x86-konformen Zotacs, dass dann mobile Anwendungen erst praktischer sind. Auf dem Rechner läuft der BrickD und die Steuerung bzw. Kontrolle erfolgt über das Display. Noch besser wird es mit der geplannten WIFI-Extension und der Migration des BrickD auf den Master... Aber irgendwie habe ich das Gefühl, ich mache mir als einziger darüber Gedanken und i.d.R. sind fast alle User hier Stubenhocker und basteln was für die Bude

Hmmh, verstehe, aber könntet ihr dann diesen Workaround auch nicht gleich einbauen, dass dieser autom. im Viewer stattfindet ? Intern die UID laden und abprüfen, und einen Quervergleich machen, zw. der Liste im Viewer und dem ausgewählten Bricklet aus der Dropdown-Box im Flash-Fenster ? Ev. ist das erstmal ein kleineres Übel als bis zur API-Anpassung zwecks Topologie zu warten.

Ja das kann sein, ev. habe ich das Enable auch über meine Anwendung gesetzt. Pardon Du meinst vorher den Load Button im Flash-Fenster drücken, um die UID zu anzuzeigen und dann diese mit den Viewer-Angaben vergleichen ?

Die spannende Frage gibt es überhaupt Lochrasterplatten im 5mm Raster zu kaufen ? Ich bin da nirgends fündig geworden...

Eine neuere Version des LCD kann ich nur unterstreichen: 1) Die Tasten sind zu klein, für eigene Taster fehlen Lötanschlüsse 2) mehr Tasten ließe mehr Möglichkeiten zu wie z.B. Menüsteuerung 3) Im besten Fall könnte so ein LCD einen PC-Monitor ersetzen 4) In der Deluxe Variante ev. mit Toucscreen Tasten/Feldern könnte man sogar die Maus ersetzen 5) und nur über einen LCD die Anwendung steuern bzw konfigurieren Andere Farben oder Beleuchtungen, Schriftarten etc. wären für mich banal und nicht wirklich wichtig.

Der Monoflop zumindest im Viewer scheint prima zu funktionieren. Allerdings scheint die neue FW den alten Interrupt Callback zu stören. Ich musste wg. meiner Anwendung die FW wieder zurückrollen weil das Auslösen des Interrupt Callback nicht zuverlässig oder gar nicht ausgelöst wurde ! In meiner Anwednung setzte ich zu Beginn ein Interupt auf PIN 1 als Input, damit verbunden ist der Ausgang eines Kameraverschlusses. Wird der Kamera-Verschluss geöffnet bzw. geschlossen konnte ich per Callback prima in der Anwendung darauf reagieren. Nach dem Einspielen der FW und BrickD Treiber wird der Callback sehr unzuverlässig oder gar nicht ausgelöst. Erst nach dem Zurückrollen jeweils auf die Vorgänger-Version, hatte ich das Verhalten wie gehabt.

1) Autom. Enable des Steppers beim Anklicken des Card-Reiters Das erste was mir in den jüngsten Veröff. aufgefallen ist, wenn man den Cardreiter des Stepper-Bricks auswählt, der Brick sofort auf enable gesetzt wird. Klickt man einen anderen Cardreiter an, bleibt diese Einstellung bestehen, und der Bricks verbraucht unnötig Strom. 2) Beim Einspielen der FW prüfen ob der richtige Typ am richtigen Port hängt Es wäre ganz praktisch wenn man zumindest im Viewer Auskunft darüber bekommt an welchem Port eines Brick ein Bricklet hängt, oder umgekehrt in der Zeile eines Bricklet eine Spalte mit der Portnummer anzeigen: verbunden mit Port A,B,C, oder D etc. Das macht es einfacher die Bricklet-FW einzuspielen. Vor langer Zeit habe ich die Bricklets angeschlossen und den Stack komplett so tief verbaut, das ich keine Lust habe alles auseinander zu schrauben. Denn mir war es versehentlich möglich, den falschen Port auszuwählen und die neue Fw für den IO4 "in ein Ambient-Bricklet" (landet ja in Wirklichk. im Brick) zu übertragen, und siehe da, ich hatte plötzlich 2 IO4 statt einem IO4 und Ambient-Bricklet. Ev. lässt sich spätestens beim Einspielen der FW auf einen Bricklet prüfen, ob dieser dem gleichen Typen des angeschlossenen Gerätes entspricht. Die Deluxe-Variante wäre auch hier dem User den Hinweis zu geben, wollen Sie die Version überschreiben etc...

Neues Monoflop-Feature im IO, prima ! Verstehe ich das richtig mit dem periodischen Aufruf des Monoflops im IO4 hätte man so was wie eine Ausfallsicherheit wenn der Slave-Stack z.B. über Chibi-Funk ausfällt ? Wird dann in diesem Fall der Callback OnMonoflopDone ausgelöst ?