Nic

Gehäuselösungen für Bricks und Co sind hier ein gerngesehenes Thema, denn dafür wird noch nix angeboten. Ist Dein Gehäuse ein DIY oder ein Fertigteil zum Kaufen ?

Verstehe nur Bahnhof. Wozu ein Bricklet Port zum Verbinden eines Schrittmotors an den Stepper-Brick ? Bricklet Buchse und Stecker git es hier auch zu kaufen: https://shop.tinkerforge.com/accessories/bricklet-connector-header.html https://shop.tinkerforge.com/accessories/bricklet-connector-crimp-socket.html Aber ohne Bastelei wird das nicht zum gewünschten Ziel führen.

Geht es ein bisschen genauer ? Sollen der Brick-Stack und die Kamera kabellos betrieben werden ? So würde ich in der Tat über eine IP-Kamera nachdenken und beides über WIFI ansteuern. Bedingt aber für den Stack die WIFI-Extension. Andererseits gibt es jede Menge USB-Webcams - groß und klein - die per Kabel verbunden werden oder via WUSB eben kabellos. Den Brick-Stack über WUSB anzusprechen ist nicht möglich. Das An- und Ausschalten dieser Webcam über Brick ist zu umständlich, da der Stream ohnehin vom PC verarbeitet werden soll. Ich würde dann nach Webcams schauen die über vernünfige SDKs oder ausreichende Treiber-Schnittstellen verfügen, die rudimentäre Befehle zur Ansteuerung vermitteln. Einige professionelle USB-Kameras haben oft GPIOs zum Triggern. Die Programmierung dafür erfolgt am Host-PC, das ließe sich prima mergen mit der Implementation der Bricks.

Bei Rugged Displays für den Gebrauch unter Extrembedingungen wird nur ein Temeraturbereich von bis zu 55 Grad angegeben: http://www.tl-electronic.de/de/news/2012-11-06/ Bei Temp. ab 60° und höher werden solche Geräte dann abgeschaltet. Die Brownsche Bewegung (Wärmebewegung der Moleküle) sollte bei zu hohen Temperaturen die Ausrichtung der Moleküle in der Flüssigkeit (Liquid Crystal Display) zunehmend verhindern und den Kontrast verschlechtern. Auf dem Display befinden sich Polarisatoren, die eine genaue Ausrichtung erfordern. Werden solche Anzeigen i.d.R. nicht eher außerhalb der Saunakabine angebracht ?

Also ich habe das mit zusätzlichen Schraub-Klemmböcken (RM 3.5mm) von C http://www.conrad.de/ce/de/product/732154/Loetbare-Schraubklemme-mit-Drahtschutz-Rastermass-35-mm-175-A-15-A-Polzahl-4-Grau-PTR/6130115&ref=list gelöst, die ich vorsichtig rechtwinklig an den Lötstellen der Klemmbuchse (Motoranschluß) an der Unterseite des Stepper-Bricks angelötet habe. Entlöten per Entlöt-Sauger bzw. -litze hatte nicht geklappt, da die Lötstellen einfach zuviel Material haben.

Erste Sahne :)

Hast du das Projekt von rifmetroid starten können ?

Hmmh, erklärt aber nicht, warum es nicht unter Win7 geklappt hat... Aber egal. @TF Ich empfehle eine Ergänzung in der Doku zu den Treibern unter Win8. Das wird zunehmen, je mehr Leute auf Win8 wechseln. Dazu immer das Forum zu konsultieren, ist doch etwas umständlich.

Mach das Beispiel, und vergleiche dieses strukturell mit Deinem Projekt. Dazu würde ich noch ein 2.VisualStudio aufmachen und die Projekte via Solution-Explorer vergleichen.

Ansonsten fällt mir als Witterungsschutz spontan Plasti-Dip ein. Ein Flüssiggummi der alle möglichen Materialien versiegelt und schützt: http://www.plastidip-gmbh.info/produkte/plasti-dip-flussiggummi/

Hast Du das Beispiel-Projekt von rifmetroid probiert ?? Ich habe es getestet und das klappt sofort und ohne Probleme. Die Solution-Datei (*.sln) einfach per DragDrop in das VisualStudio ziehen. Dann in Datei CPP-Konsole-TF.cpp die Host Addresse und UID ändern und run. Sehr unspezifisch... Ansonsten empfehle ich den Besuch spezieller Foren zu C/C++, ev. haben die dort produktivere Vorschläge.

Also ich würde mich an Deiner Stelle für eine Sprache festlegen. Egal ob es nun sofort oder später klappt. Einen Eiertanz zw. den Hochsprachen zu machen, wird dich m.E. nicht wirklich weiterbringen. Du möchtest später mal Spiele programmieren, also dann los mit C/C++. Aber zu Beginn laß den ganzen TF-Kram mal weg, und beginne ganz von vorne mit den elementarsten Dingen in VisualStudio und C++. Neues Projekt anlegen usw. ersten Code schreiben etc. Wenn das sitzt, versuch dich an den TF-Sachen in C++. Hast du eins der Tutorials angeschaut ? Nu habe extra Filme rausgesucht und nix zum Lesen, damit es schneller hilft... PS: Ich sehe gerade in Deinem Screenshot, daß die Headerdateien unter dem Knoten Quelldateien aufgelistet sind. Sollten die nicht unter dem Knoten Headerdateien wandern ?

Achso, das hatte ich vergessen. Um einen Brick (im Bootloader) vom Betriebssystem (OS) zu erkennen, wird das OS den Treiber dazu autom. laden. Eine manuelle Installation ist nicht notwendig. Dann ist anzunehmen, dass er diesen Schritt übersehen hat: http://www.tinkerforge.com/doc/Software/Brickd.html#windows-driver-installation

Siehst Du im Solution Explorer des VisualStudios, die beiden Dateien ? Über einen Button "ShowAll" kann man sich alle Dateien des Projektverzeichnisses anzeigen lassen. Dateien die noch nicht dem Projekt hinzugefügt wurden, werden transparent dargestellt. Diese Dateien kann man per Rechtsclick und via "Include in Project" permanent hinzufügen. (Sorry meine Umgebung für C# läuft unter eng.) So mache ich das in C#, ev. reicht die Zeile mit dem Include noch nicht aus. Auch wenn du hier eine einfache C-Datei hast, ist diese i.d.R. Bestandteil eines Projekts. In der Projektdatei sind Verknüpfungen und Referenz-Pfade hinterlegt.

Falls ein Brick dem Betriebssytem noch nicht als solches Brick-Device bekannt ist (Treiber), kann ich den Brick dennoch - vorausgesetzt er ist im Bootloader-Modus - im Viewer flashen ?

Wie konnte er flashen, wenn er den Brick niemals im Viewer sah ?

Hmmh, ev. hilft eines von vielen Tutorials z.B. auf youtube: Ich frage mich manchmal, ob es nicht klüger gewesen wäre, von Beginn an in C zu programmieren, um so wertvolle Erfahrungen für das spätere OnDevice-Programming zu sammeln. Für den einen oder anderen Brick oder Bricklet fallen mir da so einige Erweiterungen der FW ein, die man doch gerne mal schnell selber schreiben würde.

Was meinste denn damit ? Ich dachte C++ ist auch eine Hochsprache. Hochsprache (high level language) umfaßt traditionell alles, was über Assembler hinausgeht...

Vielen Dank, Bastian. Hat sofort geklappt. Habe statt dem TCST2103 eine EE-SH3 von Omron mit fast den gleichen Merkmalen verwendet. Emitter (blau) über einen 150 Ohm-Widerstand an die 3,3V des IO4, Kathode (rot) an GND. Fototransistor(weiß) auch an die 3,3V. Detector(rosa) aufgesplittet mit 1k auf GND bzw. direkt auf den Pin 1 des IO4. Pin 1 als Input und Pull-Up konfiguriert. Unterbricht man die Lichtschranke ändert sich das Eingangssignal von High auf Low (gemessen etwa 2.5V auf 0.5V). Und fertig ist ein Endlagenschalter für den Schrittmotor.

Wie müsste man diese Gabellichtschranke Typ TCST2103 ( http://www.produktinfo.conrad.com/datenblaetter/175000-199999/184250-da-01-de-CNY_37_TCST_2103.pdf) am IO4-Bricklet anschliessen, damit beim Unterbrechen der Lichtschranke ein Input-Signal am IO4 ausgelöst wird. Der TCST2103 müsste auch über den IO4 versorgt werden. Programmierung etc. ist mir klar, aber nicht die Elektronik-Ecke...

Nur so am Rande einen kleinen Tip: Wenn es persönlich werden soll oder muss, empfehle ich die Personal Message Funktion hier im Forum.

Damit ich nicht falsch verstanden werde, der Callback im Master-Brick soll nicht nur zum Zweck eines Pings eingebaut sein. Es soll und muss nicht eine spezielle Ping-Fkt. eingebaut sein. Wenn der Master-Brick nun über irgendein beliebigen, periodischen Callback verfügt (wie ein GetAll-Data http://www.tinkerforge.com/doc/Software/Bricks/IMU_Brick_CSharp.html#BrickIMU::AllData__short-.short-.short-.short-.short-.short-.short-.short-.short-.short- im IMU) könnten wir diesen zweckenentfremden und auf das Event oder Ausbleiben des Callbacks reagieren. Ansonsten müsste man vorhandene Callbacks von anderen Bricks oder Bricklets dazu nutzen. Mein Gedanke war nur, dass m.E. der Master-Brick sozusagen den Stack repräsentiert. Von diesem ist letztendlich die Funkverbindung abhängig. Und nicht immer hängt an einem Funk-Stack Brick oder Bricklets, die mir einen Callback liefern, den ich als Signal "Hallo Dein Stack ist noch da" interpretieren könnte. PS: Von den vielen Gettern in der Master-API sind bestimmt mehrere Werte von Interesse, die man periodisch überwachen möchte: Signalstärke, StackVoltage, IsWifiPresent etc... PSS: Ich bin auch nicht der große Experte von C, aber ein einfacher Timer der den Callback auf dem Master auslöst und 2-3 Werte mitliefert, kann nicht so viel Speicher brauchen.

Mir fällt bezgl. Ausfallsicherheit eines Funk-Slaves noch eine andere Möglichkeit ein. Der Master-Brick ist das zentrale Element im Stack, hat aber im Gegensatz zum IMU- oder Stepper-Brick keine Callbacks. (Ausnahme der Enum) Warum sollte ich von Implementations-Seite den Ping (per Timer) an den Stack senden, per Callback könnte der Master-Brick diesen Ping quasi gleich selber schicken. Dieser Callback könnte zusätzlich Status Informationen über Signalstärke etc. mitgeben. Im Event-Handler des Callbacks würde immer ein Timer neu gestartet mit einem Interval bei 2 sec. Fällt der Slave aus, würde der Callback ausbleiben und der Timer zuschlagen, um z.B. Funktionen oder Kontexte im Programm abzuschalten.

Ein Hintergrund-Timer pingt zB. alle 2 Sekunden gegen den Master-Brick eines Slave-Stacks, ob dieser noch verfügbar ist. Wenn nicht, wird der gesamte abhängige Kontext im GUI gesperrt bzw. Disabled um weitere User-Interaktionen zu unterbinden. Die Idee des Pings war doch von Dir, zu welchen Zeitpunkt sollte dieser deiner Vorstellung nach ausgelöst werden ? Alternative sehe ich hier noch über den Monoflop eines IOs der im Slave-Stack integriert ist.

Ah, ok und danke. Daran hatte ich gar nicht gedacht. Das Ping ist ein guter Gedanke, allerdings wäre es praktischer, das am Device anzusiedeln. Bevor man also die eig. Funktionen aufruft, versichert man sich per Ping ob das Device noch verfügbar ist. Oder per Timer regelmässig und autonom. Eine Ausfallsicherheit (Watchdog) mittels Monoflop von einem IO müsste auch helfen.