jgmischke

Hi Nic, ja, ist schon klar, das der Puffer auf dem Host laufen muss, es ging und geht nur darum, dass es einfachen eine zusätzliche Funktion für das LCD Bricklet gibt, wo halt ein Timer vom Host gesetzt wird. Geht auch mit setitmer oder timercreate, aber manche Signale bringen das NCurses durcheinander, zumal wenn es multithreaded läuft. SIGALRM ist da völlig unbrauchbar. Naja, prog ich mir halt einen Timer füs LCD zusammen, aber danke fürs mitdenken und helfen.

Da ich in nackten C programmiere, stell dir das gnaze so vor: Beispiel ist ein Rasenmäher, der anhand von GPS und anderen Sensordaten fröhlich durch die Gegend mäht. ( Die ganze Logik und Auswertung wird von einem Raspberry erledigt, der an den Bricks hängt ) Und jeder Sensor meldet nun ab und an oder wenn ein Ereignis eintrifft: Da steht was im Wege, es regnet oder ähnliches. Und dies soll halt die LCD anzeigen. Im einfachsten Fall etwa so: GPS-Brick sprintf(zeile[0],"Ko: 13.23.45 43.32.12"); wobei dann die Zeilenpuffer einfach für alle global erreichbar sind. Dann sprint irgendwann der Callback des LCD an und die Meldung erscheint unabhängig von dem, was alle anderen Teile gerade machen. Deswegen braucht das LCD auch nichts von den andren Teilen wissen, es bekommt statt dessen seinen Puffer gefüllt und hat diesen dann abzuarbeiten. Ich habe mir schon ein Grundgerüst gebaut, welches selbstständig alle Bricks erkennt, diesen Namen zuweist, alle Device initialisert, die UID speichert etc. Und da habe ich gemerkt, das so ein LCD Timer eben ganz nett wäre. Aber das ist im Prinzip auch noch ganz am Anfang, das Grundgerüst jkann ich dann eben je nach Anwendung immer wieder nutzen, ob nun fürs Teleskop oder als Rasenmäher.

"Nein wieso, muss es es auch nicht. Warum ist das ein Problem ?" Es ist auch kein richtiges Problem, aber ein einfacher Callbackaufruf nach TF Manier wäre eben nur "einfacher", bzw. passt halt.

Die Astronachführung ist nur ein(!) Projekt, welches relativ einfach von der Anwendung her ist. Ist ja im Prinzip nur ein wenig Schrittmotorsteuerung und das hab ich soweit schon fertig. Nächsten Monat kommt eine Untersetzung 1:3900 und dann teste ich das ganze mal-. Wie gesagt, ein Timer für die LCD Anzeige wäre halt in der TF Umgebung einfacher. Etwa so: Alle Sensoren liefern ihre Werte in einen Puffer ( Zeile 1 -x ) und machen dann weiter mit der Arbeit. Alle X Sekunden schaut dann die Anzeige nach, was sie ausgeben muss. ( Also etwa ein Rasenmäherbot oder sowas in der Art, mal sehen, der braucht schon einiges an Sensorik. )

Ja, da hab ich mich ungeschickt ausgedrückt. Ich habe das LCD Display eingeplant, um sämtliche Meldungen aller Sensoren auszugeben. Dies kann ich natürlich machen, indem ich bei jedem Sensor die Werte mit lcd24_write... wegschicke. Das wird aber bei einer Vielzahl von Sensoren unübersichtlich. Einfacher wäre es, etwa die Werte in einen belibig grossen Puffer zu schreiben, der dann regelmässig via Timer vom LCD selber abgearbeitet wird. ( Dort könnte man auch noch Meldungen nach Prioritäten sortieren und was weiss ich. Über den direkten Aufruf ist das alles nicht möglich. ) Es ist ja kein Problem, unter C einen eigenen Timer zu bauen, aber dieser könnte mit der TI Software kollidieren und wäre eben nicht Bestandteil der TI Software. So wäre es halt einfacher und eleganter, zumal alle TI-Timer ja von der TI Software gesteuert werden.

Wäre es möglich, auch für den LCD Bricklet ein Timercallback wie bei vielen anderen Bausteinen zu ermöglichen. Die Idee wäre, etwa alle XX Sekunden nachzusehen, ob in einem Puffer Texte für die Darstellung auf dem LCD sind, diese könnten dann aktualisiert werden, ohne dass die Darstellungsfunktion aus anderen Funktionen heraus genutzt werden muss. So könnten mehrere Daten zusammen fliessen und dann dargestellt werden.

Jupp, alle Bricks angeschlossen, beide Master und alle anderen Teile werden erkannt und arbeiten einwandfrei. Schön das es so gut funktioniert.

Einmal mehr DANKE. Das wusste ich nicht, dass der Master dann nicht leuchtet. Hab ihn neu geflasht und mit der neuen Version geht alles. Jetzt meldet er sich ganz normal und funktioniert auch wieder. Tja, so lerne ich jedesmal was dazu und bin immer mehr begeistert, wie glatt das alles läuft, wenn man weiss, wo man was drücken muss. SUPERARBEIT!

Ups... So, das Problem mit dem ersten Master hat sich ja geklärt, jetzt hab ich meinen anderen Master genommen und der lief ja bisher ohne Probleme. Also angeklemmt, ein bisschen mit den Bricklet dran rumprobiert und da dachte ich, ok, jetzt pack ich mal die neue Version drauf. Wurde angezeigt, ich flash das ganze, packe den Master jetzt wieder dran ... Schweigen im Walde. Zuerst dachte ich ja gleicher Fehler, da die LEDs nicht wollten. Allerdings ist das Fehlerbild komplett anders! Ich habe auch alle Anschlüsse durchgeschaut, alles ok. Der Master behindert auch die anderen nicht, er ist nur ohne Funktion. ( Wenn ich im Stapel mit dem "kaputten" Master auf Reset drücke, reagiert der Stapel auch .) Den Master also abgeklemmt und mit dem Bootmodus probiert, der beschrieben wurde. Erase Taste drücken, USB dran , Taste loslassen. Nichts! Der Master wird auch im brickviewer nicht erkannt, weder im Stapel noch allein. Wobei der Stapel mit dem defekten Master weiter funktioniert, aber nicht angezeigt bzw. erkannt wird. Gut, ich hab ja noch einen Master, aber was mach ich jetzt. ( Und die neue Version pack ich erst mal nicht mehr an )

Die Polhöheneinstellung werde ich im ersten Schritt erst mal nur mit dem Schwenkkopf vom Stativ machen, um zu sehen, wie die Bilder werden. Ungenauigkeiten der Ausrichtung kann man ja gut erkennen. Sollten die Aufnahmen gut werden, wird es eine feste Ausrichtung aus Metall geben, die von einem Kollegen exakt "zubereitet" wird. Die kommt dann fest in die Erde. Aber soweit bin ich nicht, erst mal klein anfangen und ausprobieren. Jedenfalls danke für deine Hinweise.

Naja, da hab ich schon rumprobiert. Die Poleinstellung ist nicht so schwer, da gibt es ja genügend Methoden, um möglichst exakt einzunorden. Das ganze käme auf ein Berlebachstativ ( stabil und durch nichts zu erschüttern, das Teil ist fast 40 Jahre alt, aber sowas von fest im Stand , da wackelt nix ... ) Ich hab mal ausprobiert, mit einem 10mm Objektiv kann man so um 25-30 Sekunden OHNE Nachführung fotografieren, dann wird es aber eng mit der exakten Abbildung. Das wäre dann so mein erster Versuch mit dem beschriebene Aufbau. Mal sehen was da mit 10mm so geht.

Gut, der Nema 17 ist nur unwesentlich teurer. Und mal sehen, was ich dann so dranhängen kann. Wenn die Auflösung von 1.8 Schritten pro Sekunde beim 500der nicht reicht ( was ich fast befürchte ) werde ich mal noch ein 2. Getriebe dranhängen, falls möglich. Auf jeden Fall bin ich mal gespannt drauf.

Ok, danke(!!!) für den Tipp mit dem 1:100 Getriebe, der Motor sieht ganz gut aus, ich denke ein NEMA11 sollte für erste Versuche reichen. Ich habe mal so ungefähr 1.8 Schritte pro Sekunde ausgerechnet, mal sehen ob das reicht. Naja, und wenn das 500er zu gross ist, hab ich auch noch ein paar andere Objektive im Keller.

So, heute morgen hat mir ein Kollege aus unserer Elektronikabteilung die Beinchen gerade gebogen. Und der Master geht wieder. Nach dem Update hatte ich auch sofort ein Bricklet eingestöpselt und da ist wohl was verklemmt worden. Nochmal danke!

Ja, hab den fehler gefunden. An einem der Brickanschlüsse liegt ein Beinchen auf dem anderen. Da muss man erst mal draufkommen. DANKE.

Naja, im Moment will ich erst mal nur mit der DSLR und einem 500er Russenspiegel ein paar Aufnahmen machen. Später würde ich ganz gerne noch meinen Dobson mit einer Steuerung versehen, aber erst mal geht es ums Erfahrungen sammeln. Es gibt ja für >300 Euro so eine kleine Nachführung die über USB läuft und ich denke für das Geld kann man auch besser hinbekommen. ( Hiess glaub ich Skywatcher oder so )

Hier wäre ja mal interessant, wieso diese Geräusche entstehen??

An den Kablens kann es nicht liegen, alle anderen Bricks laufen ja ohne Probleme mit dem gleichen Kabel / USB Port. Ich werde das mit dem Erase Button mal testen.

Dumm gelaufen, ich kann den kaputten Master ja nicht neu flashen, da dieser überhaupt nicht mehr erreichbar ist. USB geht gar nicht, die LEDs bleiben aus und NICHTS passiert. Von daher steh ich jetzt etwas dumm da.

Ja das ist ja das Problem, das die Bewegung die Rotation der Erdachse ausgleichen muss und damit genau so "rund" laufen muss wie die Erde selber, sonst sieht das auf den Fotos nicht so prall aus. Also muss ich wahrscheinlich wie von dir beschrieben heftig untersetzen. Gibt es da irgendeine Adresse, wo man solche Getriebeuntersetzungen bekommt?

Genau, das war die Frage. Aber bei 20000 Schritten / Sekunde brauche ich mir da ja keine Sorgen machen. Nur zum Verständnis, weil ich da keine Ahnung von habe: Der Motor dreht aber permanent, also nicht etwa -> Schritt -> Pause -> Schritt. Weil dann würde die Nachführung nicht funktionieren.

Prima. D.h. wenn ich jetzt etwa eine 1:4 Untersetzung nehme, könnte ich 2 Schritte pro Sekunde machen. ( oder im gleichen Verhältnis auch mehr, ich muss mal sehen, wie genau die Nachführung sein muss .) Wenn ich jetzt die 2 Sekunden / einen Schritt nehme, könnte ich somit bei einer weiteren Untersetzung noch genauer arbeiten, indem ich etwa 12 Schritte / Sekunde oder so nehmr. Wo liegt denn da die Grenze des Motors?? Das ganze lässt sich dann über den Stepperbrick steuern, indem ich die Motorgeschwindigkeit anpasse? D.h. aber auch, wenn ich etwa merke, dass die Nachführung nicht eakt ist, kann ich die Geschwindigkeit per Programmierung ja jederzeit anpassen oder? Und bis zu wieviel Kilo darf ich dann die Achse belasten. ( DSLR und Objektiv dürften so um maximal 1,5 kg liegen )

Ich habe vor, mir eine Nachführung für ein Stativ zu bauen, wobei sich der Motor über ensprechende Untersetzung 1(!) mal am Tag komplett um seine Achse dreht. ( Dient als Nachführung für Astrofotos, d.h. auf einem Stativ wird der Motor aufgesetzt, eingenordet und der Fotoapparat nebst Objektiv wird dann nachgeführt ) Aber welche Art von Motor ist da besser geeignet. Ich würde ja eher zum Schrittmotor neigen. Wo könnte man eine solche Übersetzung beziehen, die üblichen Zahnräder scheinen mir da eher schlecht geeignet zu sein?

OK, probier ich heute Abend.

blockiert einer meinen ganzen Stapel und auch die USB Maus ( vom Rechner, den ich über USB angeschlossen habe ) geht nicht, solange der Master Brick am USB hängt. ( Nehm ich den Master vom USB geht auch die Maus wieder ?!) Sobald ich den einen "kaputten" Master vom Stapel nehme geht der Stapel wieder, aber der 2. Master hat immer noch die alte Softwareversion. ( Und die lass ich auch erst mal drauf.) Und der "kaputte" Master alleine geht auch nicht, also unabhängig vom Stapel. Was nun???