Jump to content

cl-

Members
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ein Blick ins Datenblatt und ich wäre schlauer gewesen. Sorry daher für meine blöde Frage! Vielen Dank
  2. 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
  3. Es ist seit einigen Tagen nun nicht mehr vorgekommen. Ich werde weiter beobachten.
  4. 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
  5. 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
  6. Das hätte mich auch gewundert. Ich schaue mal weiter drauf und versuche herauszufinden, was das Problem ist. Danke
  7. 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)
  8. 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; } ... }
  9. 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? } });
  10. 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);
  11. 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
  12. 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
  13. 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?
  14. 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.
×
×
  • Create New...