cl-

Ein Blick ins Datenblatt und ich wäre schlauer gewesen. Sorry daher für meine blöde Frage! Vielen Dank

Hallo zusammen, ich habe ein paar Fragen zur Benutzung der Ethernet Extension: Wenn ich in meinem aktuellen Setup Daten vom Master Brick abfrage, bekomme ich 1000 Nachrichten pro Sekunde. Habe ich aber jetzt eine Ethernet Master Extension im Stapel, ohne dass ich ein Netzwerk-Kabel eingesteckt habe, bekomme ich nur noch 3/4 der ursprünglichen Anzahl an Nachrichten geliefert (hierbei verbinde ich mich weiterhin mit localhost per USB wie vorher auch). Ich setze nur die Ethernet Extension drauf, ohne dass ich sie "aktiv verwende". Warum bekomme ich weniger Daten weg? Ich bekomme mit der Ethernet Extension (diesmal mit Kabel) weniger als die Hälfte der Daten vom Master Brick weg als das per USB angeschlossene Master Brick alleine schafft. Wodran liegt das und könnte man das verbessern, wenn man einen zweiten Master Brick im Stapel hätte? Ich hätte gedacht, dass das USB Limit von 1000 Nachrichten pro Sekunde bei Ethernet (100 Mb/s) nicht gilt. Liegt das an der Pollrate des Master Bricks? Wenn ich die Ethernet Extension "nur" als Netzwerkkarte verwende und mit dem RED Brick verbinde, bekomme ich dann mehr Daten weg? Und wenn sowohl auf der Ethernet Extension als auch auf dem RED Brick der Brick daemon läuft, mit welchem würde ich mich in der Kombination unterhalten? Ich habe ja nur eine IP Adresse und ich kann von aussen nicht einsehen, welcher Daemon dann aktiv wäre. Losgelöst von Ethernet: Mit welcher Master Extension bekomme ich die meisten Nachrichten weg? Beste Grüße Claudio

Es ist seit einigen Tagen nun nicht mehr vorgekommen. Ich werde weiter beobachten.

Hallo zusammen, das MultiTouch Bricklet gibt neben den 12 Kontakten auch einen globalen Proximity Wert aus. Bei mir ist es so, dass die 12 Kontakte auch (bei entsprechender Sensitivität) auslösen, wenn ich in Distanz bin. Das ist auch gut so! Beim Proximity Wert aber bekomme ich nur ein Signal, wenn ich einen der 12 Kontakte berührt habe. Ist das normal? Das Wort "Proximity" lässt für mich den Schluss zu, dass auch er schon bei Annäherung ausschlägt. Welche Informationen gibt denn Proximity, welche ich nicht (schon vorher) über die Kontakte bekomme? Oder ist es einfach nur die zusätzliche Möglichkeit, bei der Prüfung eines einzigen Wertes zu wissen, ob ein Signal auf einem der Kanäle anliegt und ich nicht ständig alle Kontakte prüfen muss? Das ist keine technische Frage, sondern womöglich eher eine Verständnisfrage. Beste Grüße Claudio

Nein, das Update habe ich sehr früh gemacht, ein paar Tage nachdem es verfügbar war. Das ist schon ein paar Wochen her. Sobald es wieder vorgekommen ist, werde ich hoffentlich mehr wissen. Danke

Das hätte mich auch gewundert. Ich schaue mal weiter drauf und versuche herauszufinden, was das Problem ist. Danke

Hallo zusammen, ich beobachte seit einigen Tagen des öfteren, dass brickd ohne erkennbaren Grund nicht mehr erreichbar ist. Brick Viewer kann sich dann nicht mehr verbinden und ich muss den Daemon neu starten. Das kommt seit zwei Wochen ca. alle ein bis zwei Tage vor. Ein Blick ins Logfile lässt nichts erkennen, da der Fehler leider nicht geloggt wird. Gestern ging alles problemlos. Zwei Tage davor musste ich zum letzten Mal neu starten. Vor 10 Minuten wollte ich drauf zugreifen und es ging nicht mehr. Dazwischen habe ich den Rechner im Schlafmodus gehabt. Hat jemand das gleiche Verhalten bei sich? ==> /var/log/brickd.log <== 2020-04-30 19:42:33.768010 <I> <libusb:darwin_claim_interface> no interface found; setting configuration: 1 2020-04-30 19:42:33.768331 <E> <libusb:darwin_claim_interface> interface not found 2020-04-30 19:42:33.896937 <I> <usb.c:194> Added USB device (bus: 20, device: 24) at index 1: Master Brick [6Jpnid] 2020-04-30 21:18:35.727764 <I> <usb.c:414> Removing USB device (bus: 20, device: 24) at index 1: Master Brick [6Jpnid] 2020-04-30 21:18:35.733964 <W> <libusb:darwin_release_interface> USBInterfaceClose: no connection to an IOService 2020-04-30 21:18:35.734097 <W> <libusb:darwin_close> USBDeviceClose: no connection to an IOService 2020-04-30 21:18:36.156209 <I> <libusb:darwin_claim_interface> no interface found; setting configuration: 1 2020-04-30 21:18:36.156738 <E> <libusb:darwin_claim_interface> interface not found 2020-04-30 21:18:36.287554 <W> <libusb:darwin_open> USBDeviceOpen: no connection to an IOService 2020-04-30 21:18:36.287712 <E> <usb_stack.c:444> Could not reopen USB device (bus: 20, device: 25): LIBUSB_ERROR_NO_DEVICE (-4)

Also ich mache es in anderer Reihenfolge, wobei ich aber nicht glaube, dass das irgendetwas ändern sollte. Ich mach den icon_connect() erst nachdem die Callbacks registriert sind. Innerhalb der callbackConnected() mache ich dann den ipcon_enumerate() call. //-------------------------------------------------------------- CTF_Steuerung::CTF_Steuerung() { ... // create IP connection ipcon_create(ipcon.get()); ... // register connected callback ipcon_register_callback(ipcon.get(), IPCON_CALLBACK_CONNECTED, (void (*)(void))callbackConnected, ipcon.get()); // register enumeration callback ipcon_register_callback(ipcon.get(), IPCON_CALLBACK_ENUMERATE, (void (*)(void))callbackEnumerate, &metadata); // establish IP connection to brick daemon error = ipcon_connect(ipcon.get(), TF_HOST, TF_PORT); if (error < 0) { std::cerr << "Could not connect to brick daemon" << std::endl; return error; } ... }

Hallo zusammen, wenn ich das Accelerometer 2.0 Bricklet mit continuous_acceleration_configuration() einstelle, sagen wir beispielsweise 12800 mit einer Achse wie in unterem Beispiel, führt das Cooperative multitasking des KX122 dazu, dass die Zeitdifferenz zwischen zwei Samples immer konstant ist? In dem Fall müssten es ca. 1/12800 = 78 us sein. Dazu müsste ja das Senden der Daten zum XMC via SPI wirklich so fix sein (< 78 us), dass die nächste Wandlung rechtzeitig geschehen kann. Hintergrund der Frage: Ich verpasse den Samples, die über den get_continuous_acceleration_16_bit_callback_receiver() reinkommen, nachträglich ihre individuellen Zeitstempel. Ich mache das im Moment so, aber heute beim Verbessern des Codes kam die Frage auf, ob das überhaupt technisch vertretbar ist. Habt ihr dazu vielleicht Informationen? Beste Grüße Claudio let sensor = AccelerometerV2Bricklet::new(&response.uid, &request_sender); // set data rate and full scale configuration sensor.set_configuration(ACCELEROMETER_V2_BRICKLET_DATA_RATE_12800HZ, ACCELEROMETER_V2_BRICKLET_FULL_SCALE_4G); frequency_sensor.set_continuous_acceleration_configuration( true, false, false, ACCELEROMETER_V2_BRICKLET_RESOLUTION_16BIT, ); // get callback receiver let acceleration_receiver = sensor.get_continuous_acceleration_16_bit_callback_receiver(); // spawn thread to handle received callback messages thread::spawn(move || { // process acceleration data for acceleration in acceleration_receiver { // in that case, acceleration has 30 i16 values // what's the difference in timing between the individual samples? // can we assume that coop_task_tick() generates timestamps with constant timeshifts? } });

Hi Paul! Der Callback ist richtig definiert. Ist cb_enumerate_static() Teil einer Klasse oder ist es eine Funktion außerhalb? Wenn ersteres zustimmt, dann versuch mal folgendes: // register enumeration callback ipcon_register_callback(&ipcon, IPCON_CALLBACK_ENUMERATE, (void (*)(void))cb_enumerate_static, this);

Hallo Manni, ja das ist problemlos möglich. Du bräuchtest dann zwei Verbindungen in deiner eigenen Auswertesoftware, um gleichzeitig auf die beiden verschiedenen Kommunikationswege zugreifen zu können: Der Weg geht bei Tinkerforge Hardware immer über eine spezielle Softwareschnittstelle, die auf den System installiert wird, auf das zu zugreifen willst. Bei Tinkerforge heisst diese Schnittstelle Brick Daemon. Du benötigst somit eine Verbindung zum Brick Daemon deines PC/Laptop (um die Sliders und die anderen Komponenten abzufragen) und eine zweite, parallele Verbindung zur Master Extension (dort läuft auch der Brick Daemon) für die Servos. Man arbeitet dann mit den entsprechenden IP-Adressen, d.h. die Verbindung mit dem eigenen Computer geht mittels "localhost" (was Betriebssystem-intern eine spezielle IP-Adresse darstellt) und die Verbindung zur Ethernet Extension läuft über die entsprechende IP-Adresse, die sie in deinem Netzwerk bekommt oder du ihr manuell gibst. Die Logik und die Regeln, nach denen die Servos dann gesteuert werden sollen, implementierst du in deiner eigenen Software. Dafür bekommst du bei Tinkerforge viele verschiedene Programmierschnittstellen (API). Welche Programmiersprache willst du verwenden? Grüße

Thanks a lot. That will make it easier to understand.

Hi Erik, vielen Dank! Das hilft mir sehr! Jetzt habe ich den Zusammenhang endlich mal verstanden. Das ist für mich und vielleicht auch andere nicht trivial, weil der Zusammenhang von USB 2.0 und 1.000 Hz Pollrate kein technisches Allgemeinwissen ist. Heißt das dann im zweiten Schritt, dass man zu Ethernet greifen sollte, wenn man sichern stellen will, dass maximal viele Nachrichten vom Bricklet weggehen? Ich denke da vor allem an das Acceleromer Bricklet 2.0 mit seinen 25.600 Werten pro Sekunde. Hängt man davon mehrere an ein Master Brick, wird man ja auch nicht alle Daten wegbekommen. Ist es möglich, mit dem Ethernet Brick mehr Accelerometer Bricklets zu betreiben (mit maximaler Rate) als über USB? Ich werde gleich direkt das Beispielprogramm von dir testen! Grazie, Claudio

Ok. Ich habe weiter probiert. Wenn ich ohne das Isolator Bricklet arbeite, bekomme ich die vollen 1000 Werte. Es scheint also, dass das Isolator Bricklet den Datendurchsatz halbiert. Kann das sein?

Hallo! Ich habe hierzu eine Frage: Wie bekomme ich denn die 976 samples pro Sekunde übertragen? Wenn ich bei meinem Industrial Dual Analog in Bricklet 2.0 mit voltage_callback_configuration arbeite, dann bekomme ich 500 Werte pro Sekunde pro Kanal. Wenn ich pausenlos mittels get_adc_values() beide Kanäle gleichzeitig abfrage (und beide Werte werden gleichzeitig in einer Nachricht übertragen), dann bekomme ich auch 500 Werte (für beide Kanäle) pro Sekunde. Der Header hat zumindest beide Werte in einer Nachricht: typedef struct { TFPMessageHeader header; int32_t value[2]; } __attribute__((__packed__)) GetADCValues_Response; Selbst wenn ich einen Kanal einzeln abfrage mittels get_voltage() bekomme ich nur 500 Werte pro Sekunde. Meine Konfiguration für die Callbacks: // set period for voltage callback to 1 ms voltage_sensor.set_sample_rate(INDUSTRIAL_DUAL_ANALOG_IN_V2_BRICKLET_SAMPLE_RATE_976_SPS); voltage_sensor.set_voltage_callback_configuration(0, 1, false, 'x', 0, 0); voltage_sensor.set_voltage_callback_configuration(1, 1, false, 'x', 0, 0); Wie kommt man denn auf die 1000 Nachrichten pro Sekunde, wie in deinem Beispiel? Was ist der Unterschied zwischen Nachrichten pro Sekunde und Messwerte pro Sekunde? Das Industrial Dual Analog in Bricklet 2.0 ist das einzige Bricklet an meinem Master Brick. Es gibt keine weiteren Master Bricks im Stapel. Bei mir hängt aber ein Isolator Bricklet zwischen Mater Brick und Industrial Dual Analog in Bricklet 2.0.

Possibility b) works. Great, thanks a lot for clarifying! So maybe you could add one more sentence into the documentation that the connected_uid - in case a bricklet is connected to an Isolator - is indeed the Isolator and not, as the documentation states, the Brick it is connected to. Again, thanks

Ok. I guessed it wouldn't be possible right away. I know I could save the uids and ports of the other bricklets to get what I wanted. Possibility a) only works (and that's why I was looking for another approach), in case the enumeration of the Isolator bricklet comes first in the sequence, that is after the IDAI enumerates. Is there a constant order in the enumeration process? Does it go from inside (bottom Master Brick at position 0) to outside the network topology? Possibility b) doesn't work, at least from what your documentation says. Your comments in the source code say "For a Bricklet this ... [connected_uid] ... will be a UID of the Brick where it is connected to." Frankly, I started that way using the connected_uid of the EnumerateResponse object (Rust API), but when I found out, that I get the UID of the Master Brick instead of the Isolator, I gave up on this. If the documentation is misleading (or I just misunderstood, which is more likely) and I can use possibility b), that would be the approach I'd follow.

Hi everyone, I'm struggling or maybe my brain isn't as fresh anymore as I think it is. I have an IndustrialDualAnalogInV2Bricklet (IDAI) connected to an Isolator Bricklet, which in turn is connected to the Master Brick. How do I get the position at the Master Brick (a, b, c, d) to which the Isolator Bricklet is connected, by processing the enumerate response from the IDAI. When you process an enumerate response of the bricklet which is connected to the Isolator, it doesn't know about the "connected_uid" of the Isolator bricklet (as both, Isolator and IDAI won't show up in the same enumerate callback function, obviously). I can't ask the IDAI, because its position is always z, as it's behind an Isolator. I like to know the position of the Isolator bricklet at the Master Brick inside the enumerate callback of another bricklet (which is connected to the Isolator) There might be a complex way to get around this problem, but is there an easy way, which I just can't see at the moment? What's the right way of doing this? I need to know the position of the Isolator Bricklet at the Master Brick, because I have multiple IDAI connected and the local channels of the IDAI (0, 1) have global channels in my setup. Think of having two IDAIs (going through Isolator bricklets) connected to the Master Brick (positions A and B), therefore you'll end up having four global voltage channels, that is IDAI A with channels 0 and 1 (connected to Brick at position A through Isolator A) and IDAI B with channels 0 and 1 (connected to Brick at position B through Isolator B). On the broader scale, I need to know which of the local IDAI channels maps to which global channel, in order to save the measured values in the IDAI callback receiver loop to the right locations in my data structure. Cheers, Claudio

Ich habe hierzu noch eine kurze Frage. Im Schaltplan für das Industrial Dual Analog In Bricklet 2.0 sind die beiden ADC Kanäle getauscht (zumindest wenn man sich nur die Zahlen anguckt). ADC1 ist laut Schaltplan mit CH0 des MSCP3911 verbunden und andersherum. Meine Frage ist nun, ob das einen technischen Grund hat? Wenn ja, könntet ihr mir das vielleicht kurz erklären? Oder war das einfach nur besser vom PCB Layout? Danke

Thanks! I've seen the changes in bricklib2. There are also two files in /bricklib/toolchains with the absolute path to docker. Cheers!

Hi! Would it be possible to make the path to the docker executable editable for your docker based build environment? At the moment, the command in your makefile configuration files (inside the bricklib2/cmake folder) include the static path, that is /usr/bin/docker. On a mac, for instance, docker doesn't install into /usr/bin though. It would be possible for me to change all these occurrences, that's not the question. However, I don't want to change that many files, given that I don't want conflicts in the cloned git repository. Cheers, Claudio

Das ist ein guter Punkt! Daran habe ich nicht gedacht. Danke

In der Version ist der Versatz weg. Das ist schon mal gut! Was mir noch aufgefallen ist, dass wenn man den Tab wechselt hin zu einem anderen Bricklet, der Plot im anderen Tab pausiert. Wechselt man nun zurück zum ersten Tab, hat der Plot einen Sprung. Wenn man nun nicht weiß, dass ein inaktiver Tab nicht weiter aktualisiert wird, dann würde man sich wundern, warum das Signal so komisch aussieht. Siehe Screenshot. Könnte man den Plot im Hintergrund weiter plotten lassen? Das wäre die ideale Lösung. Sonst müsste man zumindest dafür sorgen, dass die "alten Daten", also die vor dem Wechsel des Tabs aus dem Plot gelöscht werden. Man könnte ja softwareseitig einen "clear graph" erzwingen, sobald ein Tab aktiviert wird. Ihr werdet sicherlich eine gute Lösung finden. Besten Dank für eure Mühen!

Stimmt, das habe ich vergessen nach dem Update! Geht nach dem build_src.py Aufruf wieder. Ja genau, ich führe den Brick Viewer aus dem Source aus. Danke

Es gibt eine Fehlermeldung in Brick Viewer Version 2.4.9 (aktueller Commit von gestern) unter macOS 10.14.6, nachdem mal auf den Updates/Flashing Button geklickt hat im ersten Fenster. Aufruf des Brick Viewers mittels python3 (Version 3.7.4 installiert über Homebrew). Beste Grüße Claudio ps: Sorry, ich bin im falschen Forum! Bitte entsprechend in den Softwarebereich verschieben. Danke!