borg

So, hab das mal gerade nachgestellt (siehe Anhang). Aufbau v.l.n.r.: Master mit RS485 Extension, versorgt über USB vom PC, konfiguriert als RS485 Master mit Slaves 2 und 3, Termination On (brickv1.jpg) Master mit RS485 Extension, versorgt über USB Power Supply, konfiguriert als RS485 Slave (Adresse 3) und Termination Off (brickv2.jpg) Master mit RS485 Extension, versorgt über USB Power Supply, konfiguriert als RS485 Slave (Adresse 2) und Termination On (brickv3.jpg) Das funktioniert einwandfrei bei mir. Ist das jetzt so äquivalent zu deinem Aufbau? Wenn nicht, wie kann ichs nachstellen ? Edit: Was mir da noch zu einfällt: Hast du auch die Slaves vor dem Master gestartet? Es gibt da kein "Hotplug".

Der Prozessor und RAM und weiterer kram ist auf einem kleinen Zusatzboard das aufgesteckt wird: http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G134032695534 Das ist 42x25mm groß und würde zwischen unsere board-to-board Stecker passen. Da kriege ich das große Leuchten in den Augen . Ist das erste Modul dass ich sehe, welches man verwenden könnte um ein "Linux-Master Brick" zu machen. Leider gibts zu dem Board keine Preise und noch nichtmal ein Pinout o.ä.

@Nic: Das glaube ich nicht. Zum einen hab ich das mit RS485 getestet und zum anderen hat er ja die Slaves beide beim Master angegeben. Ist mir nicht ganz klar was da los ist. @Salvo: Kannst du das ganze denn mit einem Teilnehmer einwandfrei nutzen oder gibt es da Timeouts o.ä.? Falls ja würde ich mal versuchen die Geschwindigkeit runterzustellen.

Welche Firmware Version haben die Master Bricks? Sind die Termination Schalter passend geschaltet?

Ah. Das ist schlecht. Eine neue Pulsweite wird erst nach ablaufen einer Periode gesetzt. Alles andere wäre für einen Servo auch nicht das richtige verhalten. Welche Auflösung braucht denn das PWM? 50Hz ließe sich ja auch mit einem IO4 Bricklet erreichen.

Wir sind da natürlich Abhängig vom Scheduling auf dem Linux Board. An und für sich sieht der USB Standard vor, dass einmal pro ms der Brick gepollt wird. Dadurch wäre eine maximale Verzögerungszeit von 1ms + 1µs (Bearbeitszeit auf dem Servo Brick) gegeben. Was der Linux Kernel jetzt aber macht wenn nicht genug Rechenpower da ist das ganze durchzuführen, kann ich nicht sagen .

Um andere RS485 Devices auszulesen? Das ist nicht vorgesehen. Wie würde das aussehen? Soll das über eine API vom PC möglich sein oder indem man Firmware verändert? Stell ich mir alles irgendwie nicht so einfach vor.

Der Modbus RTU kram ist eigentlich schon dokumentiert: http://www.tinkerforge.com/doc/Software/IPConnection_Modbus.html Dazu gibt es dann zu jedem Brick/Bricklet nochmal eine Seite mit den jeweiligen IDs etc: http://www.tinkerforge.com/doc/index.html#bricks

Im Moment gibt es das noch nicht. Wir haben schon mit dem einen oder anderen großen deutschen Elektronikversandhändler gesprochen. Die haben da zwar großes Interesse dran, allerdings erreichen wir die Margen die wir dafür bräuchten im Moment einfach noch nicht. Wir haben vor Ewigkeiten mal eine Preisliste angelegt für Reseller: http://www.tinkerforge.com/reseller_conditions Allerdings ist uns Mittlerweile bewusst, dass die Preise dort absolut uninteressant sind für Versandhändler. Wenn wir aber an jedem Brick/Bricklet nur wenige Cent verdienen sind die Händler für uns uninteressant. Wenn wir jetzt hergehen würden und die Preise für jedes Produkt um 25% erhöhen würden, würde hier vermutlich Chaos ausbrechen ! Das ist also auch keine richtige Alternative.

Auf den ersten Blick behandle ich das genau genauso wie bei RS485 (und da funktionierts). Muss ich mir dann nochmal genauer angucken .

Oh, Tatsache. Habs in der config gefixt: https://github.com/Tinkerforge/generators/commit/6cbee91682a19d5d1ad6f57ac42373717e936f28 Das nächste mal wenn es neuen Binding Versionen gibt ist der Fix mit drin.

Mh, hast du die neueste Master Brick Version getestet? Ich hatte anfangs den gleichen Bug bei RS485, hab dann aber herausgefunden woran es liegt und eigentlich sowohl für RS485 als auch für Chibi gefixt!

Alles klar, machen wir das so. In der Zwischenzeit einfach nach dem Disable ein FullBrake aufrufen, hat dann den gleichen Effekt. Danke für das Feedback .

@webster7567: Was du da rausgesucht hast ist definitiv geeignet. Eine Anleitung zum einrichten des Raspberry PI haben wir auch: http://www.tinkerforge.com/doc/Embedded/Raspberry_Pi.html Aber das hat sich ja dann jetzt vermutlich schon erledigt, schade .

Ah, jetzt verstehe ich dein Problem. Enable/Disable und Start/Stop sind einfach etwas anderes. Wenn du Disable aufrufst, wird quasi einfach die Verbindung zum Schrittmotor gekappt und er kann "Auslaufen". Wenn aber z.B. FullBrake aufgerufen wird, wird aktiv gebremst je nach Kraft des Motors und Drehzahl kann das richtig brutal sein. Bei Stop wird natürlich die eingestellte Debeschleunigung genutzt. Daher finde ich das verhalten bis dahin richtig: Du trennst die Verbindung zum Motor aber der Rest läuft intern weiter. Stoppen kannst du ja immernoch mit Stop oder auch mit FullBrake (nach dem Disable, danach ists ja nicht mehr "brutal"). Soweit so gut bis dahin. Wenn du jetzt aber her gehst und wieder Enable machst und der Motor läuft intern noch, dann kann ich die noch anliegende Geschwindigkeit eigentlich nicht auf den Motor geben, der kann mit dieser im Zweifelsfall nicht anfahren und vielleicht ist es nicht gewollt, also lasse ich es. Das ist jetzt sehr unschön war mir aber bekannt bis dahin. Richtig buggy wird es allerdings wenn du jetzt Stop aufrufst. Weil dann fängt der Motor doch mit der hohen Geschwindigkeit an zu drehen und beschleunigt von da aus runter. An der Stelle ist einfach die Stepper Brick interne State Machine kaputt. Jetzt stellt sich mir natürlich die Frage was hier das korrekte vorgehen ist. Ich tendiere gerade dazu einfach bei einem Aufruf von Disable intern ganz normal das Disable durchzuführen wie es jetzt ist und danach noch ein FullBrake aufzurufen. Dadurch wird intern die State Machine in einen vernünftigen Zustand gebracht. Natürlich ist die eingestellte Geschwindigkeit dann weg und Schritte hab ich mit hoher Wahrscheinlichkeit auch verloren (Schrittmotor läuft aus)! Meinungen dazu?

Mh, also das hier: Sieht so aus als würdest du versuchen 2 brickd gleichzeitig zu starten? Kannst du mal gucken ob da zwei laufen (ps aux)? Und evtl alle mit einem killall killen und nochmal versuchen? Wenn das nichts bringt wäre eine Logfile interessant wo das abstecken per USB mit drin ist. Hier ist es jetzt erst ab dem brickd neustart.

Also du hast deinen Stack und er funktioniert. Dann ziehst du USB ab und brickd ist weg? Das ist ja komisch. Kannst du mal in (vermutlich) /usr/share/brickd/config.py das LOGGING_LEVEL auf logging.DEBUG setzen und gucken was nach einem Absturz in /var/log/brickd.log steht?

Genau richtig was AuronX sagt. Für deinen Fall würde man einfach von high auf low setzen, dann einen Zähler nehmen der bis 75 zählt und dann wieder von low auf high (oder andersrum). Wie gesagt, gucke ich mir an. Hab mir vorgenommen einen Tag pro Woche zu investieren um neue API zu implementieren, die TODO Liste dafür ist ein wenig angewachsen . Letzte Woche hab ich ja schon ein bisschen API hinzufügen können.

Kann ich beides nicht reproduzieren. Wenn du im Brick Viewer auf "Stop" klickst wenn er im 0 Punkt ist, bewegt sich der Schrittmotor dann auch? Falls nein, guck doch mal wo der Unterschied liegt in den Daten die übertragen werden (am einfachsten vermutlich mit Wireshark). Mh, jo. Baue ich mal ein enable/disable für ein beim nächsten Update. Hab ich nicht so drüber nachgedacht, bei den ganzen anderen Callbacks gibt es ja eine Periode die man auf 0 stellen kann zum ausstellen.

Ne, dafür brauchst du keinen zweiten Master Brick (würdest du bei der WIFI Extension auch nicht brauchen). Grundsätzlich ist es ja so, dass eine TCP/IP Verbindung zwischen dem Brick Daemon und dem Programm was du schreibst aufgebaut wird. Ob diese Verbindung nun über WLAN, über das Internet, über UMTS oder wie auch immer aufgebaut wird ist vollkommen egal. Der Master am embedded Board verhält sich sozusagen so als wäre er bei dir am PC!

Den 4. Punkt auf der Startseite sollten wir entfernen, da gebe ich dir vollkommen recht! Kameraseite: embedded Board, daran per USB angeschlossen: Bricks und Bricklets und ein WLAN-USB-Stick. Auf diesem Board läuft brickd und es verbindet sich mit einem Access Point oder direkt per Ad Hoc mit deinem Laptop. Laptop: Die IP Connection in dem Programm auf deinem Laptop verbindet sich über den AP oder Ad Hoc mit dem brickd auf dem embedded Board (die IP des Boards angeben anstatt "localhost", genauso wie es mit der WIFI Extension auch wäre). Das ist alles. Von der Programmierung her ist alles exakt genauso wie es mit der WIFI Extension auch wäre. Anstatt die WIFI Extension zu konfigurieren musst du das embedded Board konfigurieren und dort den Brick Daemon installieren. Sonst ist alles gleich!

Ah, also ein "wiederkehrender Monoflop". Sowas ist technisch auf jedenfall möglich (solange wir in der 1ms Auflösung bleiben). Einmal zur Erklärung: Auf den EEPROMs auf den Bricklets sind Plugins gespeichert die von den Bricks beim starten eines Stacks eingelesen werden. In diesen Plugins gibt es eine "tick_task" die von dem Brick einmal pro ms ausgeführt wird. Maximale Ausführungszeit ist 100us. Alles was man damit machen kann ist auch möglich. Ich habs mir mal auf die TODO Liste geschrieben, gucke ich mir an wenn ich mir die Monoflop Geschichte für die IOs angucke.

Cool .

@webster7567: Ich würde dir empfehlen ein kleines embedded Board zu nehmen und dort den Stack dranzumachen. Dadrauf kann dann der brickd laufen und du kannst von außen steuern. Die Funkverbindung zwischen dem embedded Board und dem Steuer-PC kann über irgendwas passieren was TCP/IP spricht, z.B. ein USB-WLAN-Stick. Ein Raspberry PI + ein günstiger WLAN Stick wird noch nichtmal teuerer sein als Master+Chibi. Die Übertragung muss aber natürlich nicht per WLAN passieren, such dir halt etwas raus was die Reichweite und den Durchsatz schafft den du brauchst. Was bringt es dir wenn wir Chibi wieder auflegen aber deine 2000€ Seilkamera bleibt während des Events irgendwo stecken weil die Übertragung nicht stabil genug ist? Wenn ich ein kleines RC Modell steuere ist das nicht ganz so schlimm, einmal neustarten und weiter geht es. Aber gerade auf Grund von Anwendungsfällen wie den von dir beschriebenen haben wir Chibi erstmal gestrichen!

Du redest von einem Monoflop für die drei? Oder meinst du jetzt was anderes?