CWRITE Logging über Submit

Hallo zusammen,

ich hab' hier einen LBR4 stehen und möchte (bis das FRI endlich da ist) gerne Kräfte und Positionsdaten über einen externen PC mitloggen.
Das Nutzen von CWRITE an sich funktioniert auch unproblematisch.

Ich möchte jetzt aber gerne ein Programm ausführen und parallel dazu (also gleichzeitig) die Kräfte und Positionsdaten übertragen.
Sehe ich das richtig, dass ich dann ein SUBMIT schreiben muss, wo ich die Kommunikation mit dem PC handle, während parallel dazu dann das eigentliche SRC ausgeführt wird?

Oder gibt es da geschicktere Ansätze? (Hatte auch an TRIGGER WHEN PATH gedacht, allerdings ist mir aus der Doku nicht ganz klar geworden, ob die Bewegungsanweisungen tatsächlich parallel (ohne Unterbrechung) zur seriellen Kommunikation ausgeführt werden?

Vielleicht kann mir ja jemand kurz weiterhelfen.

Gruß
Nico

Ich habe mein Unterprogrammm in die SPS.sub eingebaut (generell funktioniert die permanente serielle Kommu), allerdings kommt nun ein neues Problem auf.

Wenn ich eine Kraft versende, dann wird bei der internen Telnet-Ausgabe (192.0.1.1) der korrekte Wert angezeigt (bspw. +2.45896). Beim mit der KRC verbundenen Labview-PC erhalte ich allerdings nur eine 2. und der Rest wird verschluckt. Wenn ich nach dem CWRITE aber ein WAIT SEC 0.06 bspw. einfüge, dann wird der korrekte Wert übertragen.

Noch interessanter wird es aber, wenn ich bei reinem laufendem Submit-Interpreter eine Kraft auf den Robo ausübe. Dann verschluckt sich CWRITE komplett und ich erhalte im Labview-Programm einen Shift der zu sendenen Zahl (statt 2.4545 bspw. 452.45). [Unabhängig ob ich WAIT SEC einfüge oder nicht]

Jemand eine Idee?

Ich arbeite "Pure", sprich XON/XOFF abgeschaltet - auf beiden Seiten.

Nun ja, normalerweise würde ich davon ausgehen, dass es CWRITE in den TX-Buffer der Schnittstelle haut und ich es mir dann auslese. Das funktioniert mit nem Char-Array gut, mit Real-Werten weniger gut. (Auf der anderen Seite bekomm ich selbst mit nem RX-Buffer und dem kompletten Auslesen teilweise (wenn ich eine Kraft auf den Rob ausübe) eine Verzögerung/Verschiebung.

Irgendwo ist da der Wurm drin. Entweder ist es ein Timing-Problem oder auf der Strecke COM3 KRC <-Nullmodemkabel-> <-Seriell/USB-Konverter-> <-Labview> murkst was herum.

Den Seriell/USB-Konverter werde ich mal gegen eine altmodische onboard-Schnittstelle tauschen und sehen, ob sich nicht was verändert. Am Konverter kann ich immerhin noch an der Latency-Time und Puffergröße spielen ...

Der Submit-Interpreter sollte doch deterministisch im 12ms Takt ausgeführt werden oder sehe ich das falsch?

Werde es mit Xon/Xoff testen. Wenn es nur das war, wäre es super.

Servus Stups,

13 Stk. bei dem Einkaufspreis ist aber auch eine gute Hausnummer. Da könnte ich mich mal so richtig austoben.
Da fallen mir Dinge ein ... Du arbeitest aber nicht zufällig bei einer Firma mit Stern oder?

Wir haben hier genau einen zur Verfügung. Ist ein Fraunhofer Institut, in dem er steht. Forschungsmäßig beschäftige ich mich gerade mehr mit Regelungskonzepten (bspw. Kraft, Potentialfelder), Dynamikidentifikation, Nullraum im Rahmen von bestimmten Montageaufgaben. Immer auch im Zusammenspiel mit anderer Sensorik. Wenn Du Regelungen auf Drehmomentebene o.ä. erstellen willst/musst, dann kommst Du um das FRI meiner Meinung nach nicht drum herum. RSI geht nicht tief genug hinein.

Von den Standardfunktionen im Grunde das gesamte Kraftportfolio (TrigByContact, DesiredForce mit Profilen usw.)

Finde es generell anstrengend, dass die unteren Schichten bei KUKA so gekapselt und abgeschottet sind. Würde meiner Meinung nach einen Benefit auch für KUKA geben, wenn das etwas offener werden würde.

Generell geht's natürlich am Ende immer um praxisnahe Anwendungen in der Produktions- und Montagetechnik.

Grüße

Hallo APT,

danke für die Info. Da sehe ich bei mir weniger Probleme, denn der Robo läuft nicht durch sondern geht abends brav schlafen mit kalter Dusche am nächsten Morgen.

Meine Meinung:

Ärgerlich sind solche Dinge allerdings, denn es heisst fast immer am Anfang: Der Fehler liegt bei auf Kundenseite. Ist ja auch einfacher und kostengünstiger als bei sich selber nachzuschaun ... Den einzelnen Kunden besser in den Entwicklungs- und Verbesserungsprozess einbinden und mit mehr Möglichkeiten (Software, Schnittstellen) in den Grundausstattungen, dann wären beide Seiten zufriedener.

Zur seriellen Schnittstelle:
Dummerweise liegt das Problem auch schon mal an der Krücke USB-Seriell, wenn nur wenige Byte übertragen werden. Da kann der Adapter echt langsam werden, da USB ja nach dem Polling-Verfahren arbeitet und am liebsten zusammengefasste Pakete verschickt. Bei langen Datenstreams sicherlich sinnvoll, bei vermeintlich kurzen einfachen Sequenzen muss man ewig herumbasteln.

Deswegen nehm ich mir Montag nen Laptop mit guter alter serieller Schnittstelle mit, um zu schaun ob es nicht auch am Adapter liegen kann.

Da wir in dem Fall nicht mit KUKA kooperieren, haben wir den selben dürftigen Informationsstand.
Das DLR dürfte uns dabei ne ganze Ecke voraus sein - die haben die Dinger ja in Kooperation mit KUKA entwickelt.

Bedeutet aber auch, dass alles was ich/wir hier noch machen werden, nicht in den LBR5 einfließen wird.
Zum FRI existieren bisher nur C++ -Funktionen. Von Java höre ich das erste mal, wobei es kein so großer Aufwand sein sollte, diese Funktionen zu portieren. Muss halt nur einer Zeit haben und mal machen. Stört mich aber nicht, denn ich kann auch mit C/C++ leben bzw. würd das dann mal mit Labview kombinieren.

Auf welche Instabilitäten spielst Du an?

Die Kraftmessung ist ja eine Rückschätzung/Berechnung der TCP-Kräfte ausgehend von den Achsmomenten. Wenn Du jetzt falsche Lastdaten bzw. Trägheiten hinterlegst, dann wirkt sich das auf den modellbasierten Regler aus. Im schlimmsten Fall bewegt sich dann der Robo ohne Last einfach nach oben oder zur Seite, weil er die Gravitationskräfte ausgleichen will, die er ja größer annimt, als sie tatsächlich sind.

Das wirkt sich dann aber auch auf die "Gewichtsmessung" aus. KUKA hat ja noch die Varianz als Kriterium für die Kraftschätzungsqualität mit angegeben, aber naja. Du solltest beim Wiegen jedenfalls drauf achten, dass sich der Arm nicht in der Nähe einer singulären Position befindet, denn dann nimmt die Schätzqualität ab.

An einem Austausch wäre ich aber generell interessiert, denn oft hat der eine die Probleme des anderen schon lange gelöst und man muss das Rad nicht dauernd neu erfinden.

Stups: Kontaktier mich doch mal per PM.

Zum Problem und der Lösung:

Mit Xon/Xoff an PC und KUKA, Latenzzeit vom USB-Treiber auf 1ms am PC, Buffer auf 64Byte verkleinert am PC und Termination-Character am PC funktioniert die Übertragung nun gut.

Jetzt muss ich sie nur noch etwas schneller bekommen.