borg

Müsste ich mal ausprobieren, ich vermute das tackern kommt durch "Rundungsfehler" zu Stande . Bei Servos entspricht eine Position einer gewissen Pulsweite. Mit "keine Geschwindigkeit" ist hier gemeint das sofort das angegebene PWM gesetzt wird. die Pulsweite wird nicht mit einer Geschwindigkeit erhöht. Spannungsabschaltungen gibt es da nicht, die Geschwindigkeit entspricht der Rate mit der sich die Pulsweite der Zielpulsweite (Zielposition) annähert. D.h. °/s = Pulsweitenveränderung/Sekunde Die Beschleunigung entspricht der Rate mit der sich die Geschwindigkeit annähert. D.h (°/s)/s = °/s^2 = Pulsweitenveränderung/Sekunde^2 Auch so Mini-Servos haben große Anfahrströme, mit einem großen Kondensator könnte man den aber vermutlich auch über USB betreiben. Beim Servo Brick gibt es aber keine Verbindung zwischen der USB-Spannung und der Servo-Spannung.

So, gibt jetzt eine 2.0.4. Da sollte das Problem behoben sein.

Plugins: IO-16 Bricklet 2.0.4 Fix edge count bug, Save space to compile plugin with O2 again. Download: IO-16 Bricklet

Plugins: IO-16 Bricklet 2.0.4 Bug im Flankenzähler gefixt, Code umgestellt um Platz zu sparen damit Plugin wieder mit O2 compilierbar. Download: IO-16 Bricklet

Ich kann das Problem reproduzieren, bin gerade noch dabei herauszufinden was genau passiert. Gibt aber denke ich Heute noch eine neue Version!

We did think about a version of the Servo Brick that has power on the actual PWM pins (not only on the third VCC pin). The idea there was that you could control up to 7 high power LEDs with it, additionally to servos. You could also control small motors. But this won't happen in the next weeks, we currently have too many other open project.

Das hat mit der Ethernet Extension nichts zu tun. Das hängt mit einer Umstellung der Schnittstellen im Stack zwischen Hardware Version 1.1 und 2.0 zusammen. Wenn wir nochmal eine neue Master Brick Version machen werden wir das fixen, nur deswegen eine neue Version zu machen lohnt allerdings nicht.

Die Widerstände sind Spannungsteiler die wir entsprechend zuschalten/abschalten um eine größere Auflösung im niedrigen Bereich zu erreichen.

Das ist einfach mechanisch so, wie du schon selbst erklärt hast. Ich wüsste nicht was wir da in Software gegen machen sollten.

Mhhh. Ich hab mir gerade die Änderungen angeguckt: https://github.com/Tinkerforge/io16-bricklet/commit/7a3e84f33234a1e964b7d1639ff675c0766db09e Da ist jetzt eigentlich nichts bei was große Performance-Probleme verursachen sollte. Wir haben die Optimierung von O1 auf Os umgestellt damit die neue Flankenzähler-API noch auf das Bricklet passte, evtl macht das Probleme? Ich gucke morgen ob ich das reproduzieren kann.

Wenn man einen Callback aktiviert ist der für alle Programme aktiviert. Die Bricks/Bricklets selbst kennen keine mehreren Teilnehmer und können da auch nicht unterscheiden. Das Routing passiert an der Stelle im Brickd. Aber du kannst in den Programmen die einige Callbacks nicht brachen diese ja einfach ignorieren (also nichts auf dem Callback registrieren), das sollte ja gar keine Probleme machen oder verstehe ich dich da jetzt falsch?

Wir lesen einmal pro ms den aktuell anliegenden Wert. Wenn es eine Veränderung von Low auf High gegeben hat gehen wir davon aus das es eine steigende Flanke war, wenn es eine Veränderung von High auf Low gegeben hat gehen wir davon aus das es eine fallende Flanke gab. Dadurch können wir eine Frequenz von maximal 500Hz erkennen. Ohne Fehler können wir also eine Frequenz von 250Hz erreichen, siehe Nyquist-Shannon-Abtasttheorem.

New Accessories in our Shop: Blog entry

Neues Zubehör im Shop: Blogeintrag

Der Master Brick ist heute bei uns angekommen, er war lediglich nicht geflasht

Der Brick Viewer stellt an den Callbacks rum, das ist richtig. Kann es sein das du den Brick Viewer beendest und dann die Callbacks aufhören? Der Brick stellst die Callbacks auch wieder aus wenn du ihn schließt.

Jap, das Hall Effect Bricklet wird genau das tun: Magnetische Felder erkennen und Flanken zählen. Das Rotary Encoder Bricklet ist sowas hier: http://www.circuitsathome.com/wp/wp-content/uploads/rotary_encoder.jpg Das ist zum drehen per Hand gedacht. In Theorie könntest du aber natürlich auch versuchen das an einer Achse zu befestigen.

There is not much we can do here. If you add up the prices of the parts on the Ethernet Extension (with PoE) and apply our "standard formula" to calculate the retail price you will end up at ~50€, or ~60€ with VAT. Why is a USB-to-Ethernet converter or a USB Wi-Fi stick so much cheaper? Thats quite easy: These converters are totally dumb. They now nothing about TCP/IP or protocols or anything. All of that is done in the operating system kernel. In contrast to that: Our Wi-Fi extension has to know Ethernet, TCP/IP, UDP, DHCP, WPA, WEP and so on and so on. The same (without the encryption) applies for the Ethernet Extension.

Also wenn ich ein On-Device-Programming Interface erstellen wollte, würde ich "OnDevice" als weitere Kommunikationsschnittstelle in com.c/com.h hinzufügen. Solch eine Schnittstelle muss send, recv und init implementiere (siehe none.c in com/none/ für eine minimale Schnittstelle die nichts tut). Nachrichten die du an Bricklets schicken willst könntest du mit com_route_message_from_pc verschicken, wobei du als dritten Parameter deine neue Schnittstelle angeben musst, also z.B. COM_ONDEVICE. Die Antworten rufen dann ondevice_recv auf. Die Daten selbst sind im gleichen Format wie im TCP/IP Protokoll beschrieben.

remotecontrol hat recht, du musst in init.c in void brick_tick_task(void *parameters) noch die Zeile led_tick_task(tick_type); auskommentieren. Ansonsten bleibt das blinken der LED anhand der übertragenen Datenmenge aktiv.

https://www.tinkerforge.com/de/shop/cases/mounting-plate-8x8.html

Shop: Montageplatte 8x8 Neue Montageplatte mit gleicher Größe wie Bricks

Shop: Mounting Plate 8x8 New mounting plate that has the same size as the Bricks

Yes That would be better, but is still think the smallest range doesn't make much sense for the autoranging. While looking at the source code, i thought that we should have allowed the 0-3.3V range when the auto range is disabled: http://www.tinkerforge.com/en/doc/Software/Bricklets/AnalogIn_Bricklet_Python.html#AnalogIn.set_range We can't break the API now, so we would have to add the new range as constant "5".

Ich hab schonmal darüber nachgedacht ein Plugin für Wireshark zu machen welches unser Protokoll versteht. Das wäre dann IMO noch einfacher. Damit könnte man sich dann sowohl die USB als auch die TCP/IP Kommunikation angucken .