Beiträge von Hermann
-
-
Nö, im Text sind zwar zwei Fragezeichen, aber das erste ist da völlig fehl am Platz. Da beschreibst Du nur was Du wolltest. Selber
Merkst schon: heute habe ich meinen 'witzigen' Tag. Irgendwie nicht ganz ausgelastet,
obwohl ich gerade von einem Kunden mächtig verarscht wurde.Und ich hätte es auch lieber, wenn man das Programm auf beliebig vielen Rechnern installieren könnte.
-
Die Antwort auf die einzige Frage im Text habe ich doch schon gegeben. .
Vermutlich ist die Frage: Kann man das SimPro mit nur EINER Lizenz auf Win7 und in der VirtualBox verwenden?
Meine Antwort auf diese Frage ist:
Nein. Die Lizenz ist an diverse Eigenschaften des Betriebssystems/Rechners (Computername, Version, Installationsdatum und weiss nicht was noch) gebunden auf dem sie läuft.
Die dürften in der VirtualBox deutlich anders sein als im Win7. -
Also ich hab's verstanden.
-
Also meine Erfahrung ist auch:
Es gibt diverse Fehler, die man im Auto-Extern nicht quittieren kann.
Warum auch immer. Da kann ich dem Kuka-MA zustimmen.Und mal ganz unter uns: wenn eine Achse blockiert ist, dann ist da "irgend was"
nicht ganz in Ordnung. So einen Fehler im Auto-Extern wegquittieren?
Ich weiss nicht recht. Da sollte man dann doch mal nach der Ursache suchen.Und warum ist da der Kaltstart eine schlechte Alternative?
Der Not-Aus-Kreis lässt sich extern versorgen, dann hat der Rest der Anlage
beim Ausschalten des Roboters keinen Not-Aus (sollte man immer so machen). -
Richtig ist's wenn man's korrekt einträgt. Egal, was der eine oder andere bei der Sternfirma haben will.
Lastdatenermittlung ist bei den meisten mir etwas genauer bekannten Robotern eine Option (ABB, Fanuc, Kuka,
Kawasaki weiss ich grad nicht).
Man weiss nie so genau was sich die Systemprogrammierer der Hersteller alles einfallen lassen.
Hatte bei Kuka mal den Fall, dass der Roboter bei korrekt eingetragenen Werten (ca 30% Maxlast)
sehr langsam wurde. Bei zu gross eingestellten Werten lief er wie geschmiert. -
Warum nicht gleich von Anfang an den vermessenen Würfel als Base hernehmen?
Da macht man keine 3-Punkt-Vermessung, und hat nur eine Berechnung. -
Müsste sowas wie z.Bsp:
SKIP CONDITION $MISC[1].$HPD_TRQ[7]>R[52]
sein. Weiss aber nicht, ob's das ...$HPD_TRQ[7] wirklich gibt. Mit 5 hab' ich's schon gemacht.
-
Kann z.Bsp. dann kommen, wenn die extern-Signale Motoren-Ein und/oder Programm-Start zu schnell nach dem
Schliessen der Schutztür kommen. Da sollte man eine kleine Verzögerung einbauen. -
Nach dem ADD Wert nehmen und dann die 1.
Dann sollte da stehen R1=R1+1.Kauft mal was vernünftiges. Die alte Kiste gehört ins Museum.
-
Ja ein DLE in den Nutzdaten muss verdoppelt werden. Und es zählt auch zur
Checksum. Nur so kann es vom 'normalen' DLE am Ende unterschieden werden. -
Also nach dem DLE - NAK musst Du auf alle Fälle nochmal ein komplettes Protokoll schicken.
Nur die Nutzdaten reichen nicht, das ist auf alle Fälle falsch. Ist aber nur ein Folgefehler, das eigentliche
Problem erklärt das nicht.
Und ein evtl. vorkommendes DLE im Datenstrom wird in Deinem Programm auch korrekt
verdoppelt? -
Im Gegensatz zu SET_PORT_CMT hat SET_PREG_CMT nur 3 Parameter.
SET_PREG_CMT setzt die Kommentare zum Positionsregister im ersten Parameter.z.Bsp:
SET_PREG_CMT(1,'homepos',STATUS)Eingänge:
SET_PORT_CMT(1,257,'lamp test',STATUS)
zweiter Parameter ist die Eingangsnummer, erster ist konstant 1Ausgänge:
SET_PORT_CMT(2,17,'lamp green',status)
zweiter Parameter ist die Ausgangsnummer, erster ist konstant 2Steht aber eigentlich alles im oben zitierten Thread. Nur manchmal ist man halt etwas betriebsblind.
-
-
Ich hatte mal ein Programm geschrieben, das hat so ca 5 Minuten lang Daten über die
ser. Schnittstelle übertragen, das waren garantiert deutlich mehr Daten als in Deinem
Fall. Habe damals das 3964R-Protokoll verwendet.Wo kommen denn die Daten her?
Vielleicht liegt es ja am Sender? -
Ja genau.
-
Mein Lösungsvorschlag:
Immer einen Kaltstart durchführen. Dauert zwar länger, ist aber häufig auch für andere
sonderbare Verhaltensmuster des Roboters die Lösung.
Ich schalte den bei nahezu jedem Roboter den ich konfiguriere dauerhaft ein. Da hat man
auf Dauer deutlich weniger Probleme. -
Also wenn es so aussieht, als ob das Return bei Dir an den Anfang des Hauptprogramms springt,
dann ist da irgend was anderes faul.
Solltest dann mal den Code posten. -
Na, da würde ich an Deiner Stelle aber die Beschreibung zum RETURN nochmal nachlesen.
Das springt NICHT an den Anfang der Hauptroutine sondern schlicht und einfach aus
der aktuellen Routine hinter die Stelle, an der sie aufgerufen wurde.Vielleicht sollte es nicht rtfm sondern utfm heissen .
-
Man sollte im Voraus mit der INVERSE-Funktion die Achswinkel berechnen, und dann gegen
die Endschalter (§SOFTP_END[], §SOFTN_END[]) prüfen können.
Schau mal z.Bsp. hier: http://www.roboterforum.de/rob…rse_funktion-t5724.0.html