borg

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?

Ich gucke mir das mit der Frequenz nochmal an, das ist aber an der Stelle leider wirklich nicht so einfach wie es aussieht. Die PWM und Timer Counter Hardwareeinheiten haben 16bit register, von daher gibt es dort eine Beschränkung auf 65535. Das ist an der Stelle erstmal Einheitslos, da kommt es dann jetzt drauf an auf welche Frequenzen die Clocks usw stehen. Dort könnte man evtl. noch dran drehen und die Frequenzen nach Bedarf umstellen, es ist aber keine Sache von 5 Minuten.

Das ist eine Zener Diode.

@Wumpus: Ich hatte eigentlich gehofft das die neuen Stepper Bricks heute ankommen, sind sie aber leider nicht. Ich würde also von morgen ausgehen.

Überprüf nochmal ob der Port den du eingestellt hast korrekt ist und dann nochmal mit anderem Kabel probieren (wie Wumpus schon gesagt hat).

Wir haben damals gesagt wir gucken uns Chibi nochmal an wenn WIFI draußen ist und dazu stehen wir auch . Zumindest mit unveränderter Software werden wir die Chibi Extensions nicht nochmal verkaufen, dazu gab es einfach zuviele Probleme. Ob eine neue Hardware notwendig ist oder nicht wird sich zeigen.

müsste ich mir angucken. Bei der IO4 geht das bestimmt, für die IO16 bräuchte ich vermutlich mehr counter als ich platz auf dem Plugin hab .

@Ts2004: Ich würde nicht ausschließen das wir ein RS232 Bricklet auf Dauer haben, wird allerdings noch ein bisschen dauern.

Mh, ist das Rotary Poti Bricklet vielleicht nicht geflasht? Dazu einfach mal den Master alleine nehmen, anmachen und dann das Rotary Poti Bricklet dranmachen und über den Brick Viewer flashen. Edit: Wenn es gar nicht geflasht ist fehlt vermutlich auch die UID, die solltest du dann auch ein setzen.

In der neuesten Stepper Brick Firmware gibt es jetzt die Möglichkeit eine Zeitbasis zu setzen (1s - 2^32s). Damit ist es jetzt möglich bis runter auf 1 Schritt pro 136,2 Jahre zu gehen. Ich hoffe das ist jetzt langsam genug .

GetAllData und state Callbacks gibt es jetzt in der neuesten Stepper Brick Firmware .

Bindings: C/C++ 1.0.15, C# 1.1.8, Java 1.0.14, PHP 1.0.9, Python 1.0.17, Ruby 1.0.6 Firmwares: Stepper Brick 1.1.6 Add time base all data function/callback and state callback to Stepper Brick API Download Bindings: C/C++, C#, Java, PHP, Python, Ruby Download Firmwares: Stepper Brick

Bindings: C/C++ 1.0.15, C# 1.1.8, Java 1.0.14, PHP 1.0.9, Python 1.0.17, Ruby 1.0.6 Firmwares: Stepper Brick 1.1.6 Fügt time base, all data function/callback und state callback zu Stepper Brick API hinzu Download Bindings: C/C++, C#, Java, PHP, Python, Ruby Download Firmwares: Stepper Brick

Ein Monoflop für das Dual Relay ist jetzt implementiert, und auch von der neuesten brickv Version unterstützt .

@Nifty: Ah, verstehe. Da hast du natürlich recht. Bei Chibi ist das wirklich blöd gelaufen, wurde sehr unprofessionell von uns geregelt . Ich hoffe das wir sowas in Zukunft nicht mehr haben. Das Problem löst sich jetzt aber so ein bisschen von selbst, da wir Mittlerweile erheblich größere Stückzahlen produzieren lassen. Bei den Current Bricklets schaffen wir es hoffentlich die neuen fertig zu haben bevor die alten komplett ausverkauft sind, da gibt es dann eine vernünftige Übergangsphase. Für das Piezo Buzzer Bricklet wird es eine alternative geben, diese etwas längliche "undefinierte Wartephase" die wir da gerade haben sollten wir in Zukunft wirklich versuchen zu vermeiden.

Bei kurzer google Suche finde ich zwei Extensions die ein "estimated shipping date" anzeigen können, z.B.: http://www.magentocommerce.com/magento-connect/chadjmorgan/extension/4085/configurable_product_custom_stock_status Das kann ich aber nicht einfach so installieren und fertig, das muss ich erst in unserem Testshop testen usw. Wir haben schon einige schlechte Erfahrungen mit Magento Extensions gemacht .

In der neuesten Servo Brick Firmware können alle 7 Pinne eine minimale Periode von 1us! Die Auflösung der Pulsweite lässt hierbei jetzt natürlich nach im unteren Periodenbereich.