Nic

Ja aber dafür einen RaspPi ! Aber Spaß beiseite, das kann ich mir nicht so recht vorstellen. Zumindest gibt es ev. einen AkkuSchrauber, oder aus alten Elektronik-Tagen kenne ich noch die Handbohrer für Leiter-Platinen um das Kupfer abzureiben. Also wirklich ein bisschen Handwerk gehört dazu, son paar Löcher sind schneller gebohrt als eine For-Schleife im Code geschrieben Zumal man mit Markierungen nix mehr ausmessen muss.

Ich möchte nur noch schrauben, aber nicht bohren. Jo, aber so eine Bequemlichkeit hat Ihren Preis, damit wird der Herstellungsprozeß länger, anfälliger und für jedes Löchlein wird gezahlt. Auch wenn wir es nicht brauchen, und vom gezeigten Prototypen benutzt Du garantiert nur höchstens 10 % aller Bohrungen Andererseits da schon mehrfach nachgefragt im Hinblick auf wettertaugliche Gehäuse oder Wandungen, wäre mir die Schweizerkäse-Löchervariante des Guten zu viel.

Das kann gut möglich sein, aber das wird für alle Thermoplaste gelten. Hatte neulich ein POM-Platte über die Bucht besorgt, und die war auch verspannt. Selbst unter hohen Temp. keine Chance das Teil jemals gerade zu bekommen. Vorschlag: Mir würden Einkerbungen oder Markierungen (wie mit einem Körner) auf der Oberfläche durchaus reichen, und an den Stellen wo ich es brauche würde ich die Bohrungen selbst machen. Im Prinzip muss das keine Durchgangsbohrung sein. Zum Anfang würde ich ev. nur festen Plattengrößen empfehlen, die Verbindungslogik würde ich erstmal weglassen, und ev. nur Winkelverbinder anbieten, die ein Gehäusebau zulassen.

Sag mal rifet, welche XE4 Version setzt Du ein ? Pro oder Enterprise ?

Hilft das ev. weiter: https://forums.embarcadero.com/message.jspa?messageID=480211 In dem Zusammenhang wurde bisher auch nur die Indy-Komponenten genannt, dass ist für die OpenSource-Bindings nicht ideal Aber zumindest nutzt Indy die WinSock unter Windows, Posix auf Mac, libc unter Kylix, etc. Wie gesagt die mobile-Erweiterung auch im Hínblick auf Android wird anscheinend bald erscheinen, ev. wird das o.g. Problem dann lösbarer. Unter IOS wird für die TCP Sockets das CFNetwork Framework genannt: http://oreilly.com/iphone/excerpts/iphone-sdk/network-programming.html

In der Tat scheint die neue XE4 ein echter Quantensprung zu sein. Ich würde noch weiter gehen, und die nächste Version abwarten, die in Kürze erscheint, und dann auch die Android-Platform (!)unterstützen soll. Für die Cross-Entw. muss man sich von der VCL verabschieden und den Firemonkey-Framework verwenden.

Prima, sogar mit SD-Card-Slot... Für den Preis sind frei definierbare Tasten und Schalter incl. ? Von den 3 Step-Down-Supplies habe ich das Step-Down-Feature noch nie gebraucht. Ev. gibt es mal eine Step-Up oder ganz banal ein Power-Supply-Light zum Durchleiten der angeschlossenen Spannung. Da ist dann gewiss Platz zum Anschluß von div. Schaltern, DC-Jack, USB-Voltage-IN etc. So ein simples Power-Supply-Brick könnte dann auch als Sockelboard/Bodenplatte verwendet werden.

D.h. der Text bleibt solange persistent im Eprom bis die FW ein Update erfährt bzw. erneut per SetDefaultText überschrieben wird ?

Mein lieber Schwan, da gibt es doch tatsächlich so was simples wie ein oder mehrere Schalter: http://www.cooking-hacks.com/indexa.php/shop/shields/digital-push-button.html Man beachte das "Easy Plug and play" http://www.cooking-hacks.com/indexa.php/shop/shields/adkeyboard-module.html Meine Intension ging noch weiter als irgendwas an einem IO zu verschrauben, sondern man sollte sich ev. eine 3.Stecker/Buchse-Verbindungvariante überlegen, die es Anfängern ermöglicht ohne Werkzeug Schalter, Taster u.a. anzuschließen. Beim o.g. Einzelschalter beachte man den kleinen Formfaktor der Anschlußbuchse, ev. passt sowas auch auf Bricks und Bricklets und man kann sich die Lötpunkte u.a. sparen. Wie eben die Taster bei cooking-hacks es zeigen. Was eine Folientastatur angeht würde ich noch weitergehen und LCD-Bricklet mit Touchpanel konzipieren: http://www.reichelt.de/?ARTICLE=115640;PROVID=1024 Dann sollte der Terz mit Lötpunkten und/oder Anschluß externer Schalter obsolet werden. Kostet zwar ne Stange Euros, aber mit der OnDevice-API zusammen, könnte man ev. die Host-PCs in Rente schicken Soviel E-Technik ist mir bekannt aber warum kann der Hauptschalter nicht am Stack im Brick oder Bricklet sein, jedes in sich geschlossene E-System wie z.B. Handy oder Meßgerät hat einen integr. Hauptschalter. Wenn die Zielgruppe auch Anfänger und Laien sein sollen, wie sollen sie einen Hauptschalter löten, basteln, schrauben ?

Wieso gibt es das https://www.tinkerforge.com/de/shop/bricklets/rotary-poti-bricklet.html als Bricklet, man könnte ein normales Poti genauso gut an das AnalogIn anschließen. Warum hat das Lcd Lötpunkte ? Wenns doch über das IO4/16 irgendwie auch geht ? Wenn Du Deine Wetterstation mittelfristig via OnDevice-API anpasst, sprich die Station braucht keinen Host-PC mehr, wie schaltest Du den ganzen Stack ein oder aus ? Übers IO4 ?

Mein Vorschlag bezog sich nicht auf die Teile im Einzelnen, sondern erstmal verkleinerte universelle Stecker-/Buchsen an die Bricklets vorsehen, also analog zu den Anschlüssen bei Power-Supply bzw. Bricks zum Verbinden von Stromquellen und Motoren. Nach dem gleichen Prinzip (zum Einspannen in die Federkontakte) könnte man so später Einzeltaster bzw. Schalter mit Endlitzen anbieten. Bzw. dem Bastler ist es selbst überlassen, ob er mal schnell eine Endlitze an einen Schalter anlötet. Sowas ist schneller gemacht als einen ganzen 2x3 Block zu verlöten. Wenn ein einzelner Dreh/Schiebe-Poti als Bricklet möglich ist warum nicht auch ein einzelner Schalter oder Taster ? Spätestens wenn mal die OnDevice-API steht und die ersten Standalone-Stacks in Betrieb gehen sollen, kommt die Frage wo hab ich den Hauptschalter ?? Also wieder Löten ? Ansonsten hingt der Gedanke etwas, man könne mit TF ohne Lötkolben auskommen, zumindest würde das nur für sehr einfache TF-Experimentierbauten zutreffen. Mir fällt dazu noch der Wunsch nach einem Bricklet-Verteiler ein, um mehr als nur 4 Bricklets an einen Master anzuschließen. Aktuell habe ich hier ein Funk-Stack, wo alle Ports schon belegt sind. So ein Switch wäre da sehr hilfreich.

Wie war das nochmal mit der Bauklötzenfraktion, die ohne zu Löten auskommen sollen Vielleicht macht man sich beizeiten auch Gedanken über solche banale Teile wie Taster, Schalter, LEDs etc. mittels Stecker-System o.ä. die TF-Sachen zu Universalisieren ?!

Ah, interessant, da wäre noch die Möglichkeit des .net Micro Frameworks: http://de.wikipedia.org/wiki/.NET_Micro_Framework Würde mich mal interessieren inwieweit dass mit den .net Bindings kompatibel ist.

Sorry, aber nach einer Philosphie-Std. über Echtzeitsysteme hatte ich nicht gefragt Es da schon etwas irritierend, im ersten Moment von Linux abzuraten, und wenig später dann doch wieder Linux und den PI ins Spiel zu bringen. In seinem Konzept gibt es m.E. mehrere Schwachpunkte und einer davon dürfte auch das OS sein, wenn es hier um zeitsensible Sachen geht. Ich würde hier Linux und auch Win Echtzeitfähigkeiten nicht pauschal absprechen. Das gibt es zum einen Linux-RT oder für Hochsprachen spez. Realtime-Frameworks, die durchaus einer zuverlässigen Echtzeit nahe kommen. Wenn man also solche zeitkritischen Sachen schafft, wäre ein spezielleres OS oder API ev. eine sinnvolle Ergänzung. Was hier überhaupt nicht berücksichtigt wurde, dass er schon viel Arbeit in die SW unter Win gesteckt hat. Wenn es zur Entkoppelung und zuverlässigerem Regeln geht, würde alternativ z.B. ein Nano/Pico-ITX mit x86-Kern ihm Zeit einsparen. D.h. eine ZBOX AD10 von Zotac (http://www.heise.de/preisvergleich/zotac-zbox-nano-ad10-zboxnano-ad10-e-a677171.html), incl. WIFI, auf den Schlitten montiert ein Leichtgewicht, kostet zwar ein paar Euros aber spart ne Menge Zeit ohne vollständige Neu-Programmierung. Sorry aber die ständigen Empfehlungen für den PI sind mir langsam zu penetrant.

Also kein Linux. Doch wieder Linux Um ev. Missverständnisse auszuräumen, wo ist der grav. Unterschied zw. Linux normal und Pi-Linux ?

Ev. ist das noch nicht bekannt, http://www.golem.de/news/raspberry-pi-fahrrad-projiziert-seine-geschwindigkeit-auf-die-strasse-1303-98280.html aber ein sehr interessantes Projekt, dass sich für TF-Sachen ev. auch anbietet. Statt dem PI lieber OnDevice... Das bringt mich auf die Idee, ob man so ein Mini-Projektor nicht auch als Bricklet entwickeln könnte Wäre eine prima Alternative zum LCD.

Ich tippe mal, dass er die SW auf einer Windows-Umgebung implm. hat und u.U. in einer Sprache, die nicht so ohne weiteres auf Linux portierbar ist. Für so ein Echtzeitsystem, einen Kameraschlitten, der mit 50km/h auf einem Seil ev. über die Köpfe von Zuschauern rauscht, würde mir ein Windows-OS da schon schlaflose Nächte bereiten. Sorry, aber da würde ich ein paar Sicherheitsfaktoren mehr einplanen. OnDevice-Programm., Ardunio oder eben den Pi als Umgebung anvisieren. Die TF-Sachen befinden sich (noch) in den Kinderschuhen. Für solch ambitionierten Projekte ev. zu früh.

Wiki kann das besser erklären als ich http://de.wikipedia.org/wiki/Spannungsstabilisierung Für die TF Stecker benutze ich einen Schlitzschraubenzieher, um die (orangenen) Federkontakte im Stecker vorsichtig einzudrücken, dann die Draht-Litzen einstecken und Federn wieder loslassen. Was die Stromversorgung angeht, würde ich für kurzweilige, verbrauchsarme Sachen ev. über USB-Buchse einen externen 5V-Akkupack (Notnagel für Mobiles) anschließen.

Hmmh, im ersten Moment war ich geneigt mich für Phyton auszusprechen, aber wenn hierzu ein totes OpenSource-Projekt reaktiviert werden muss, frage ich mich ob es nicht sinnvoller ist, die Zeit und Ressourcen lieber gleich in die Entwicklung einer vernünftigen C-API zu investieren. Als Vorlage die Ardunio-API, aber ev. idiotensicherer -wenn das überhaupt geht- , dass C-Abstinenzler wie z.B. ich, schneller einen Einstieg haben und weniger graue Haaare bekommen. Solche Fallstricke wie Speichermanagement etc. könnte man ev. kapseln und vom Normalo-Programmierer fernhalten ?! Ich verwende TF erstrangig für mobile Anwendungen da ist es mir wichtiger, mich auf eine robuste API zu verlassen als mit einem besch...Betriebssystem oder unausgereiftem, wackeligen OnChip Interpreter in der Pampa zu ärgern. Meinetwegen beiße ich auch dafür in den "sauren" C-Apfel .

Für eine integr. JVM im Brick wurden max. realistische 200 N/s genannt. Ist der Benchmark von max 1000 N/s nur über eine C-basierte OnDev-API gewährleistet oder auch durch den Phyton-Interpr. im Brick machbar?

Die Callbacks natürlich nur wenn die Information im Host-PC aufschlagen soll. Ansonsten gehört das zum Thema Direkte Kommunikation zw. Brick und Bricklets und da fallen mir 1000 Möglichkeiten ein.

Beides war gemeint, die Bauklötzchen gehen mir auch nicht mehr aus dem Kopf und gute Bilder von Euch gehören einfach dazu. Ich würde -wenn ich über den Webauftritt meine Produkte vermarkten möchte- niemals den Faktor Mensch bei der Außenwirkung unterschätzen. Auch bei solchen technischen Dingen ist der persönliche Auftritt oder Darstellung des Unternehmens immer sympathischer und u.U. auch verkaufsfördernd. Als wenn man das Gefühl hat, ob da ev. eine Roboter-Gang im Hintergrund werkelt oder ob es überhaupt eine Form von (irdischem/ausserirdischem) Leben in der Firma existiert. So allein nur übers Forum kann man das nicht "transportieren". Vor allem Neukunden dürften zu Beginn keine Ahnung haben wer zur Firma oder nur zum Kundenstamm gehört.

Mussten es unbedingt Bauklötzchen sein Wieso Ihr braucht doch nur ein Schnappschuß von Eurer Bude zu schießen, wie hier z.B.: Die Wand mit den Werkzeugen, die Bauelemente-Regale, alles da. So ein Bild von den Tagen wo Ihr neue Prototypen ausprobiert etc. Dann sehen die Kunden auch dass hinter TF auch Menschen gibt Ahm, ich hatte in der Vergangenheit auch schon bei der Suche die 5sec Warteschleife erlebt, ev. ein Hinweis dass der Server überlastet ist...

Das würde am einfachsten zu lösen sein, wenn es die OnDevice-API gibt, dann könnte bei einem Disconnect, eine Statusmeldung direkt vom Master ans LCD geschrieben. Ansonsten bieten sich die neuen Callbacks des Master-Bricks für einen Watchdog ev. an.

Kosmetisch ist wirklich nichts auszusetzen, aber beim Bild zum Bastler, musste ich unweigerlich an einen Prospekt für frühkindliche Fördermaßnahmen wie manchmal in Kitas ausliegen, denken. Sorry, aber das mit den Bauklötzen wirkt auf mich etwas irritierend Da würde ev. ein Bild von Daniel Düsentrieb mit Lötkolben und Schraubenzieher besser passen