Jump to content

photron

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    3.216

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    57

 Inhaltstyp 

Posts erstellt von photron

    [Java] Korrekturen im disconnected und Inline-Doku

    in Software, Programmierung und externe Tools

    Geschrieben

    Okay, du hast neben den korrigierten null Zuweisungen noch redundante Casts entfernt und die JavaDoc Links verkürzt.

     

    Da BrickServo.java generiert wird gehören die JavaDoc Änderungen in generate_java_bindings.py.

     

    Wie AuronX richtig sagt ist der einfachste Weg für uns über einen Pull Request auf GitHub. Das setzt allerdings voraus, dass du dich mit git auskennst und vor allem auch weist wie die Generatoren arbeiten usw. Daher ist es auch okay, wenn du Änderungs- und Verbesserungsvorschläge einfach hier im Forum postest.

     

    Ich baue deine Änderungen gleich ein.

    Stepperbrick - Probleme mit mehreren USB Geräten

    in Hardware

    Geschrieben

    Okay, dass heißt also, dass die Kamera den Brick stört, selbst wenn dieser einfach nur vor sich hin den Motor fährt. Es findet keine aktive Kommunikation mit dem Brick zu diesem Zeitpunkt statt, welche von der Kamera gestörte werden könnte.

     

    Vielleicht ist es die Stromversorgung des Bricks, die die Kamera irgendwie stört. Wie versorgst du Brick und Motor? Ist der Brick über USB versorgt? Wenn ja hast du einen aktiven USB Hub den du zwischen PC und Brick stecken kannst, wobei die Kamera nicht an den Hub darf. Oder hast du eine Step-Down Power Supply um darüber den Brick zu versorgen.

    Stepperbrick - Probleme mit mehreren USB Geräten

    in Hardware

    Geschrieben

    Es sind übrigens nicht die Fehlermeldungen, die tauchen nur auf wenn der USB Stecker des Bricks gezogen wird und der Viewer noch läuft.

     

    Ah, okay, das im Prinzip erwartet, dass beim abziehen des Bricks diese Fehler auftreten. Eigentlich sollte libusb es ordentlich mitbekommen, wenn ein USB Gerät entfernt wird. Allerdings ist Hotplug in libusb je nach der Version und Betriebssystem unterschiedlich gut unterstützt. Du kannst also abbrechende Read Transfers beim Abstecken des Bricks ignorieren. Die haben nichts mit deinem Problem zu tun.

     

    Die Fehler treten bei forward Kommandos wesentlich häufiger auf als bei backward. Man kann es richtig hören uns natürlich auch sehen. Es werden dabei in den Logs keine Fehler etc. gemeldet.

     

    Was genau tust du denn? Konfigurierst du den Stepper Brick im Brick Viewer und lässt ihn dann per Forward Knopf einfach fahren? Und während der fährt und du im Brick Viewer nichts tust läuft der Motor nicht gleichmäßig und stottert?

     

    Das ist interessant, denn wenn du im Brick Viewer oder durch dein eigenes Programm keine Steuerbefehle absetzt, fährt der Stepper ja einfach vor sich hin ohne das über USB Kommuniziert wird.

    Stepperbrick - Probleme mit mehreren USB Geräten

    in Hardware

    Geschrieben

    Dass heißt, die 5 libusb Read Transfers, die brickd pro Brick benutzt um über USB Daten vom Brick zu lesen, brechen mit LIBUSB_TRANSFER_ERROR ab. Brick Daemon sollte dann versuchen diese Read Transfers neu abzuschicken.

     

    Kommen diese Warnings immer und immer wieder solange wie die Kamera angesteckt ist, oder nur einmal beim Anstecken der Kamera und dann ist wieder Ruhe?

     

    Deine Kamera schafft es irgendwie die USB Kommunikation zwischen Brick Daemon und Brick zu stören. Mir ist nicht klar wie oder warum. LIBUSB_TRANSFER_ERROR ist hier als Fehlermeldung leider nicht sehr aussagekräftig, der Fehler kann in libusb an vielen Stellen auftreten. Ich werde versuchen ob ich da libusb noch mehr Information entlocken kann.

     

    Hast du mal versucht Brick und Kamera an andere USB Anschlüsse anzuschließen? Vielleicht tritt das Problem nur in bestimmter Kombination auf.

    [Delphi] Fehler in BrickStepper.pas

    in Software, Programmierung und externe Tools

    Geschrieben

    Ich habe noch einige Probleme mit den Delphi Bindings.

    Mein Beispielcode sieht derzeit so aus:

    ipcon := TIPConnection.Create;
stepper := TBrickStepper.Create(UID, ipcon);
ipcon.Connect(HOST, PORT);
label1.caption:= inttostr(stepper.GetChipTemperature);

    Zum einem lassen sich die Bereichsüberprüfung und Überlaufprüfung in den Compileranweisungen nicht aktivieren ohne dementsprechende Fehler zu provozieren.

    Z..B. hier (TIPConnection.ReceiveLoop): 

    Move(pendingData[len], pendingData[0], Length(pendingData) - len);

    Ok kann man abschalten und akzeptieren, aber besonders schön ist das nicht.

     

    Okay, Move mit Länge 0 aufzurufen führt zu einen ERangeCheck. Das halte ich für übertrieben, da das an sich gültig ist. Aber ich habe jetzt einen extra Check ein gebaut um Move nur mit Längen > 0 aufzurufen.

     

    Die Chip Temperatur die ausgelesen wird liegt bei ca. -28°C. Nicht wirklich realistisch!

     

    Doch das kann durchaus sein. Die Chip Temperatur ist nur proprtional zu wirklichen Temperatur. Der Wert kann einen solchen Offsetfehler haben. Wenn du den Mikrocontroller anwärmst, z.B. mit dem Daumen, dann solltest du die Temperatur steigen sehen. Wenn du mehrere Bricks da hast wirst du feststellen, das der Offsetfehler der Chip Temperatur eine große Streuung hat. Die Chip Temperatur ist daher nur dafür gut Temperaturveränderungen zu erkennen, aber nicht dafür geeignet die absolute Temperatur zu messen.

     

    Wenn man etwas genauer hinsieht gibt es hier Probleme: 

    function LEConvertUInt16From(const offset: longint; const data: TByteArray): word;
begin
  result := word(data[offset + 0]) shl 0 or word(data[offset + 1]) shl 8;
end;

    OK ein Beispiel: data[8] hat den Wert 225 (225/10= 22.5°C was passen würde). Der Rückgabewert ist mit den Ganzen shl Verschiebungen leider 65508. Diesen Wert kann die endgültige Rückgabefunktion LEConvertInt16From nicht mehr verarbeiten (Überlauf da smallint was nur bis grob 32000 geht). Macht dann – 28°C. mmmh schlecht.

     

    Das ist richtig so wie es da implementiert ist. Was da allerdings fehlt sind explizite Casts für die Zuweisungen die Overflowen können, da sonst ERangeCheck Fehler auftreten können.

    [Delphi-Bindings] Dekl. GetIdentity untersch. sich von vorheriger Dekl.

    in Software, Programmierung und externe Tools

    Geschrieben

    Ich denke du hast hier das gleiche Problem wie Bralph in diesem Thread:

     

    http://www.tinkerunity.org/forum/index.php/topic,1357.0.html

     

    Wenn ich das richtig sehe ist overwrite hier richtig, weil GetIdentity aus TDevice ja wirklich überschrieben werden soll. reintroduce überschreibt nicht wenn ich das richtig verstehe. Das Problem hier liegt in der mehrfachen Definition von TArray0To2OfUInt8. Ich bin dabei das zu korrigieren.

×
×
  • Neu erstellen...