borg

Das Projekt was du da gefunden hast ist sehr cool, das kannte ich noch gar nicht! Zu deiner Frage: Das sollte gehen, der csharp code sollte ja fast genauso auch in Java funktionieren, ich wüsste nicht was dagegen spricht. Von Unity3D selbst hab ich leide keine Ahnung .

Vermutlich ist der Master einfach im Bootloader und muss neu geflasht werden: http://www.tinkerforge.com/doc/Software/Brickv.html#brickv-flash-firmware

Master Brick 2.0 ist jetzt verfügbar! http://de.blog.tinkerforge.com/2012/11/27/master-brick-2-0-und-geschirmte-bricklet-kabel

Mh, probier nochmal das "generate_makefile" Script auszuführen und ruf dann nochmal make auf. Aus irgendwelchen Gründen findet cmake manchmal arm-none-eabi-objcopy nicht, deswegen wird dann keine .bin erzeugt. Ich konnte aber noch nie herausfinden was da wirklich Sache ist, beim zweiten mal geht es aber dann für gewöhnlich. Ich glaube das sich am Debug Brick nichts am Layout geändert hat zwischen 1.0 und 1.1 (nur am Silkscreen). Bin ich mir aber nicht sicher, da muss Bastian morgen was zu sagen.

Es gibt leider keinen schraubbaren Stecker der flach genug wäre um die Bricklet Ports vom Stepper Brick noch zu benutzen, ansonsten würden wir sie verkaufen. In Theorie sollten diese beiden hier kompatibel sein: http://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=1840382&library=dede&tab=1 http://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=1840366&library=dede&tab=1 Bzw bei Mouser: http://de.mouser.com/Search/ProductDetail.aspx?qs=ChwaSN6Xm49EQ7SgFVITdA%3d%3d http://de.mouser.com/ProductDetail/Phoenix-Contact/1840366/?qs=sGAEpiMZZMv8kklI404QlYhPqHChqbP9 Aber ich garantiere für nichts, wir haben das nie getestet.

Standardmäßig ist JTAG aus, da die JTAG Pinne verwendet werden. Du kannst JTAG aktivieren, indem du in der config.h die "#define DISABLE_JTAG_ON_STARTUP" Zeile auskommentierst.

Mh, muss ich mir angucken. Für das Protokoll 2.0 muss ich da sowieso nochmal dran rumfummeln.

Das sollte in Theorie funktionieren. Kannst du mal einmal zum Testen die Reihenfolge von Chibi und RS485 tauschen? Also Master -> Chibi -> RS485?

Mh, schick mal eine Email an info@tinkerforge.com mit der Bestellnummer die zum dem Master Brick gehört. Wir tauschen den dann aus.

Protokoll 2.0 hat damit soweit erstmal nichts zu tun. Ich habe die Hoffnung, dass die neuen geschirmten Bricklet Kabel das Problem endgültig lösen. Falls diese nichts bringen, können wir da mit Hardware wohl nichts gegen unternehmen. Wir müssen dann wohl eine Firmware bauen mit der man zwischen den 100 und 400khz umstellen kann.

Prinzipiell geht das. Der Sensor gibt einen analogen Wert zurück und mit steigender Kabellänge fällt die Spannung und somit die Entfernungsmessung. Bei 50cm wirst du kaum einen Unterschied merken, bei 2m wird es sich bemerkbar machen.

Ja, also: bytes = read(sizeof(Header)); while(len(bytes) != bytes[4]) { bytes += read(bytes[4] - len(bytes)); } vs bytes = read(sizeof(Header)); while(len(bytes) != (bytes[4] + sizeof(Header))) { bytes += read((bytes[4] + sizeof(Header)) - len(bytes)); }

I can't imagine a system where we ever return an answer for the same FID in a wrong sequence. I think we can safely add that to the spec. A Brick that returns responses to requests to two different Bricklets in a "wrong order" could however easily happen if we ever have a multicore Brick or add real threading to the Brick firmwares. However, the Bindings could implement the sequence number per FID and then the 4 bit would likely suffice again, even if we didn't guarantee the correct order for requests with the same FID. Implementing something like "Future Objects" as a general concept in all of our Bindings would be cool, but i really don't know if it is worth the effort. Especially if we consider that the first steps will get harder for someone that just starts to learn programing.

Da hast du natürlich recht. Dann würde ich vorschlagen wir machen aus dem einem Error Bit gleich zwei Error-Bits, dann können wir 4 Fehlerzustände zurückgeben: * 0 = OK * 1 = BAD_PARAMETERS (Index out of range or similar) * 2 = FUNCTION_NOT_SUPPORTED * 3 = TODO

Es mag den Fall geben, dass man ein "echtes" Paket mit einer nicht-existierenden Funktions ID bekommt. Ich denke aber dass es wahrscheinlicher ist, dass einfach irgendein Programm schrott auf den Port schreibt (absichtlich oder unabsichtlich). Da würde ich dann eigentlich nicht drauf antworten wollen. Zwischen Paketen mit falscher FID und "Schrottpaketen" kann ich aber nicht unterscheiden. Ich bin mir aber auch nicht zu 100% sicher was hier die beste Vorgehensweise wäre.

Die Idee bei den 4-20mA Sensoren ist ja gerade, dass man mitbekommen kann wenn der Sensor nicht angeschlossen oder defekt ist (da er dann 0mA zurück gibt). Also werden wir natürlich auch runter bis 0mA messen können, sonst hätten wir dieses Feature ja verschenkt. Ich denke die API wird (wie bei uns üblich) einfach wieder eine SI-Einheit zurückgeben. Vermutlich einfach den Messwert in µA.

Uns ist da gerade ein Implementierungsdetail aufgefallen, dass wir vorher noch nicht so genau bedacht hatten. Wenn wir das neue Protokoll durchziehen, so wie es bisher gedacht ist, ändert sich das verhalten beim add_device. Im Moment ist es ja so, dass ich mitbekommen wenn ein Brick/Bricklet nicht im System ist während ich add_device aufrufe. Nach der aktuellen Planung des neuen Protokolls wäre es so, dass add_device lediglich intern die UID speichert. D.h. ich würde dort erstmal nicht mitbekommen wenn ein Brick/Bricklet nicht da ist. Das hat aber noch mehr Konsequenzen: Im alten Protokoll wurde an der Stelle z.B. auch überprüft ob das hinzugefügte Bricklet überhaupt zum Objekt passt. Des weiteren wollten wir auf Dauer implementieren, dass dort die FW Version mit der Binding Version abgeglichen wird, um zu überprüfen ob Funktionen vorhanden sind oder nicht. Das würde natürlich alles wegfallen. Jetzt könnte man an der Stelle hergehen und wieder eine Funktion auf den Bricks implementieren die diese Informationen zurück gibt. Dann wäre an der Stelle wieder alles beim alten. Vorteil: * Überprüfung ob Brick/Bricklet vorhanden * Versionsüberprüfung Nachteil: * Wir haben wieder einen "Zustand" im System. Beispiele für den Nachteil: * Ich bekomme einen Fehler wenn ein Brick/Bricklet während des Hinzufügens kurzzeitig nicht erreichbar ist. * Wenn ich z.B. einen RS485 Slave Stack nehme und die Bricks/Bricklets in diesem aktualisiere und dann wieder an den RS485 Bus hänge, hat das Brick/Bricklet Objekt falsche Versionsnummern und neue Funktionalität ist im laufenden Programm nicht vorhanden. Was meint ihr dazu?

Mhh, ich weiß nicht. Du musst ja erstmal über den Socket die komplette length empfangen. An der Stelle muss ja eigentlich keine Konstante drauf. also ich denke an sowas wie (Pseudocode) bytes = read(sizeof(Header)); while(len(bytes) != bytes[4]) { bytes += read(bytes[4] - len(bytes)); }

Arg! Werde doch mal ein bisschen präziser . Wie nah liegt es denn dran? Ist es nur 1-2° daneben oder weit daneben? Kannst du mal deine Kalibrierung anhängen?

Inwiefern passen sie nicht? Passt denn die Darstellung im Brick Viewer? Wenn nicht, sag mal ein Beispiel wo sie wie daneben liegt.

No. 2 meters will be the longest cable there too, at least available from us. For longer distances you just need a differential signal (like the RS485 Extension has).

Wie macht sich das denn bemerkbar? Hast du schonmal versucht das Magnetometer in deiner Umgebung zu kalibrieren?

Blog entry is ready: http://en.blog.tinkerforge.com/2012/11/5/introduction-of-industrial-bricklets

Damit sind wir im Prinzip wieder bei der Gehäusefrage. Wir brauchen auf Dauer einfach Gehäuse. Ich denke wenn wir Gehäuse anbieten, sollten diese auch für Ambient Light/Barometer/Humidity Bricklet benutzbar sein. Also im einfachsten Fall eine Art "Guckloch", wo man entweder ein Stück Glas oder ein Stück Schaumstoff o.ä. drauflegen kann?

I intend to write a longish intruduction blog entry regarding the Industrial Bricklets in our blog tomorrow morning (with availability dates).