borg

I am no OS X expert. I will have to ask my collegue tomorrow morning, perhaps he has an idea. Sorry for the problems!

Mh, i am surprised that nobody ever had this problem, the Brick Daemon beta1 for Protocol 2.0 was available for quite some time. The erorr means, that the binary contains instructions the version of OS X that you want to run them under does not understand. Unfortunately we only have OS X 10.8 here, according to google, one can fix this issue by compiling against older OS X SDK versions. I uploaded a .dmg that is compiled with -mmacosx-version-min=10.6: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_0_mmacosx_version_min106.dmg Could you try that? PS: You ordered the Bricks before Protocol 2.0 was released and got them after the release. That is a little bit unlucky, it means that you will have to update all of the Bricks and Bricklets. Just as a heads up .

Fehler gefunden und gefixt: http://www.tinkerunity.org/forum/index.php/topic,673.msg8262.html#msg8262 Ich hatte für den minimum voltage setter vergessen den neuen Header einzufügen (für das neue Protokoll), dadurch hat er die falschen Bytes als Spannung interpretiert Sorry!

Firmwares: Stepper Brick 2.0.1 Füge fehlenden Header zu minimum voltage Setter hinzu Download Firmwares: Stepper Brick

Firmwares: Stepper Brick 2.0.1 Add missing header to minimum voltage setter Download Firmwares: Stepper Brick

Kann ich tatsächlich reproduzieren, faszinierend . Gucke ich mir an!

1200mV sind 1,2V, du möchtest auf 12000mV stellen .

Sooo: Spritzgussformen für alle Bricks und Bricklets gemäß dem hier vorgeschlagenen Konzept (inkl. Bodenplatte, Seitenwand und Deckel, bei Bricklets Bodenplatte und Seitenwand in eins) würden netto 95000€ kosten (in China). Stückkosten für das Material sind bei ~0,30€ für normales ABS. Kurzum: Die Preisvorstellungen hier sind leider nicht einzuhalten, es sei denn wir verzwanzigfachen unsere Verkaufszahlen in nächster Zeit . Ich befürchte es muss entweder auf eine Lasercutter Lösung hinauslaufen (da dort die Anzahl der Bauteile völlig egal sind) oder auf ein großes Gehäuse, in dem man einen kompletten Aufbau verschrauben kann.

Der Treiber für den Bootloader Modus liegt im Brickv Verzeichnis. Der Treiber für den "normalen" Modus liegt im Brickd Verzeichnis. Hast du da für den Bootloader den richtigen genommen?

Wie meinst du das? Da 32 weniger ist als 64 würde ich spontan sagen, diese Aussage ist falsch unvollständig Bezieht sich das auf die bisher vergebenen UIDs? Oder ist es nur insgesamt unwahrscheinlicher geworden? (Denn Kollisionen sind ja unvermeidlich wenn der Wertebereich kleiner wird) Die UIDs kommen ja direkt aus dem Microcontroller und Atmel hat dort "Prüfbits" mit reingebaut. Zum Beispiel kommt alle 13 bits ein "1100000011". Hier einmal ein paar 64bit UIDs in binär: Da sind 32bit bei allen UIDs gleich, d.h. wir können (ausgehend von dieser Testmenge) 32bit streichen ohne Kollisionen zu erzeugen die nicht auch vorher mit der 64bit UID schon dagewesen sind. Wenn Atmel die ersten 4 Milliarden Microcontroller verkauft hat könnten sie natürlich anfangen die Prüfbits zu flippen, das halte ich allerdings für hinreichend unwahrscheinlich . in beta1 hatte ich mich mit den Masken vertan und die Maske für die ersten 32bit auf die hinteren 32bit angewendet und umgekehrt. Dadurch war ein Großteil der Bits in beta1 bei allen UIDs gleich . Die neuen Brick UIDs fangen übrigens binär alle mit "11" an (wie vorher auch). Dadurch ist sichergestellt, dass es keine Kollisionen zwischen den Bricks und den Bricklets gibt. Dort haben wir unten bei 1 angefangen hochzuzählen. Das natürlich auch unter der Annahme, dass wir weniger als eine Milliarde Bricklets verkaufen werden . Summa Summarum: Eine Kollision der UIDs ist praktisch unmöglich.

Die neue UID hat 32bit statt 64. Sie wird aus der alten 64bit UID berechnet. In der Berechnung dafür war in beta1 ein Fehler, daher haben sich die UIDs jetzt in der finalen 2.0 nochmal geändert, Sorry! Mit der UID Berechnung in der beta waren Kollisionen möglich, mit der neuen sind sie es nicht. Die Änderung war also leider notwendig. @Loetkolben: Du meinst die Shell Bindings? Die kommen, keine Panik. Aber eins nach dem anderen .

Welches Windows?

Protocol 2.0 veröffentlicht Bitte gemäß dem Transitioning Guide aktualisieren.

Protocol 2.0 released Please update according to the transitioning guide.

So, das neue Protokoll ist veröffentlicht. Wer die Beta installiert hatte muss nochmal einmal alles updaten auf die neuesten Versionen. Vielen Dank für die Hilfe!

Bei Shapeways ist man bei rund 25€ für die drei Teile die Bralph gedruckt hat. Finde ich ganz schön teuer. Ich hab mal angefragt was es kosten würde Formen machen zu lassen für dieses System. Wir bräuchten ja im Prinzip eine Form für jedes Brick, einen Deckel, einen Boden und zwei Teile pro Bricklet. Ich hab die schlimme Befürchtung, dass man sich für die Formen ein hübsches kleines Eigenheim kaufen könnte . Eine andere Frage: Was würdet ihr für Gehäuse dieser Art zahlen? Also je exakt passend für jedes Brick/Bricklet, stapelbar, festschraubbar, Option für Unterteil für Hutschiene usw. Also die "absolute Profilösung".

Oh, ich dachte du nutzt auch C#. Ich hab das mal gerade nachgestellt: import com.tinkerforge.BrickletIndustrialQuadRelay; import com.tinkerforge.IPConnection; public class ExampleSimple { private static final String host = "192.168.178.108"; private static final int port = 4223; private static final String UID = "cuw"; public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); BrickletIndustrialQuadRelay iqr = new BrickletIndustrialQuadRelay(UID, ipcon); ipcon.connect(host, port); long start; long end; for(int i = 0; i < 100; i++) { Thread.sleep(5000); start = System.currentTimeMillis(); int value = iqr.getValue(); iqr.setValue(~value); end = System.currentTimeMillis(); System.out.println("time: " + (end - start)); } } } Ergebnis: Das sieht also alles gut aus. Kannst du das mal bei dir ausführen (UID abändern)? Wenn das Problem damit nicht auftritt, kannst du es so abändern das es auftritt? Eine weitere Idee: Könntest du in der IPConnection.java zum Testen ein "socket.setTcpNoDelay(true);" hinzufügen? Direkt nach dem "socket = new Socket(host, port);" am besten.

Mh, gucke ich mir an. Wäre zumindest eine mögliche Erklärung. Interessant finde ich gerade auch das sowohl hier als auch im IO16 Thread C# verwendet wird, vielleicht ist es etwas C# spezifisches?

Im Brick Viewer? Wie sieht der Fehler aus?

There are 2 KS0066U on the LCD board. Unfortunately we cant change the charset of the display driver itself. An API for the programmable charset is already on the TODO-list !

Did you remove the "#define DISABLE_JTAG_ON_STARTUP" in config.h? We have to disable JTAG in the production firmwares, since some of the JTAG pins are dual purpose und used for other things.

@m0d: D.h. du erzeugst eine neue IP Connection? Mhhhh, die WIFI Extension kann 15 Sockets gleichzeitig aufhaben, danach ist Schluss und es wird ein "Connection Refused" geben. Wenn ihr es also irgendwie hinbekommt 15 Verbindungen aufzubauen die nicht wieder geschlossen werden (aus welchen Gründen auch immer), könnte es das hier geschilderte Problem erklären! Hat einer von euch Beispielcode den ich direkt ausführen kann? Oder ist das alles in größere Projekte eingebettet?

Ich kann das leider nicht reproduzieren. Meine Vorgehensweise: Ich stelle eine Verbindung her, öffne Brick Viewer und schaue mir eingehende Daten an (bin ein Raum neben dem AP). Dann schraube ich die Antenne ab und warte bis die grüne LED der WIFI Extension das blinken anfängt (das bedeutet sie versucht sich zu verbinden). Jetzt bekomme ich natürlich im Brick Viewer Timeouts und keine neuen Daten mehr. Dann schraube ich die Antenne wieder an, danach dauert es noch einen Moment bis der Socket merkt das er nicht mehr aktiv ist, es wird eine neue Verbindung aufgebaut und ich kann wieder eingehende Daten im Brick Viewer sehen. Ich betreibe das im Moment mit dem neuen Protokoll, ich meine aber das damals auch mit dem alten Protokoll genauso getestet zu haben.

Wenn ich das richtig sehe sind auf dem LED Flexband einfach 32 von diesem WS2801 ICs drauf, die man per SPI ansprechen kann. Dafür könnte man natürlich ein Bricklet machen. Die große Frage ist sicherlich wie die API für so ein LED Strip auszusehen hat. Bei 32 LEDs mit je 24 Bit Farbdaten machen das 96 Byte in Summe um alle einmal zu stellen. Das passt leider schon nicht mehr in unseren 64 Byte Payload und wir müssten schon aufspalten.

@thunderbird: Jo, guck ich mir gleich noch an. @Loetkolben: Wir erwarten einen Mehraufwand in Höhe von 2Mrd€, Veröffentlichung erfolgt in 2015 .