Beiträge von Spielkind

Mmmh, ich war eben auf der Homepage von Stäubli und da waren sehr viele Schulungen angegeben ...
Du warst vielleicht im Sommerloch?

In Österreich kenne ich das Wifi in Linz, welches Schulungen für Roboter anbietet. In Deutschland ist mir nichts dergleichen bekannt.

Oder man nimmt FSoE oder Profisafe ...

Hallo al3x,
da du von einem SP2 Handbediengerät sprichst, hast du eine CS9-Steuerung - also der Nachfolger von der CS8C deines "Vorredners".

In der CS9 gibt es mehrere Achsgrenzen abhängig davon, wo diese gespeichert sind:

• Safety Limits: Werden in der Safety der Robotersteuerung konfiguriert und von dieser auch kontrolliert
• Cell Limits: Diese Achsgrenzen sind in der Konfigurationsdatei /usr/configs/cell.cfx hinterlegt und "gehören" der Roboterzelle
• Arm Limits: Diese Achsgrenzen sind in der Konfigurationsdatei /usr/configs/arm.cfx hinterlegt und "gehören" dem Roboterarm
• System Limits: Das sind die maximal möglichen Arbeitsbereiche der Achsen und sind von Stäubli festgelegt (und können nicht geändert werden).

Die Idee dahinter:

Wenn du Personensicherheit brauchst, gehören die Limits in die Safety. Dann muss man das aber auch validieren.

Wenn du den Arbeitsbereich einschränken willst, weil du Anbauten an den Roboter angebracht hast, wäre es toll, wenn auch eine andere Robotersteuerung das mitbekommen würde (wenn diese getauscht wird). Deshalb solltest du diese in der arm.cfx eintragen, da diese Datei sowieso mit dem Roboter mitgenommen werden muss.

Wenn du die Arbeitsbereiche einschränkst, weil die Zelle das braucht, sollte auch ein anderer Roboter darüber Bescheid wissen (wenn du den Roboter tauschen willst/musst). Deshalb gehören die Limits dann in die cell.cfx. Diese Datei beinhaltet Einstellungen für die Roboterzelle und sind vom Roboter unabhängig.

Generell nimmt das System dann die Werte, die von allen Dateien am meisten einschränken.

Warum du nun die Fehlermeldung bekommst, ist mir nicht klar. Hast du vielleicht Plus und Minus vertauscht oder anstelle Komma einen Punkt eingetragen (wenn du Nachkommastellen angeben willst)?
Du könntest dich auch mit einem FTP-Client auf die Robotersteuerung verbinden und in den angebenen Dateien die Werte direkt eintragen. Dann musst du allerdings anschließend einmal neu booten.
Oder du machst die Einstelllungen mit SRS...

Hallo,

um die Ausführungen von Psyril ein wenig zu vertiefen:

Bibliotheken sind nichts anderes als VAL3-Applikationen mit "freigegebenen" globalen Variablen und oder Programmen.

Hinter Bibliotheken stecken zwei verschiedene Use Cases:

a) Du nutzt Bibliotheken, um unterschiedliche Teile von deinem Roboter bearbeiten zu lassen. Dann liegt alles, was bei allen Teilen immer gleich ist, in der Hauptapplikation und alles, was sich von Teil zu Teil unterscheidet liegt dann in den einzelnen Bibliotheken. Je nach produzierendem Teil lädt die Hauptapplikation dann die unterschiedlichen Teilebibliotheken.

b) Bibliotheken als bereits fertig geschriebene "Module". Damit würde dann zum Beispiel der ganze Code zur Ansteuerung eines Vision-Systems oder ein bestimmter Sortieralgorithmus oder auch nur dein persönlicher "Werkzeugkasten" als Bibliothek immer von deiner eigentlichen Applikation nutzbar sein. Vorteil ist, dass du diese Bibliothek bei jedem neuen Projekt einfach immer wieder einspielen und nutzen kannst. Du erweiterst quasi den Umfang von VAL3 mit deinen eigenen Softwarebausteinen.

Hallo staude89,

deine Frage ist viel zu allgemein, als das irgendeiner hier antworten könnte.

Der Stäubli bietet dir zum Beispiel auf Profibus maximal 244 Byte Eingang und 244 Byte Ausgang.
Diesen E/A-Bereich kannst Du beliebig auf Bits, Bytes, Wörter, Doppelwörter und Floats aufteilen. Bei den Bytes, Wörtern, Doppelwörtern und Floats kannst Du nochmals festllegen, ob sie signed oder unsigend sein sollen.
Welche Informationen du nun zwischen SPS und Roboter austauschen willst, ist völlig dir überlassen.
Es gibt Leute, die nur Start, Pause, Stop austauschen und noch ein paar Fehlerbits senden (Robbi hat Not-Aus, ist in Grundstellung, arbeitet fleissig, etc.).
Andere haben eine riesige Schnittstelle, die sogar Zielpunkte über den Feldbus austauschen ....

Alles ist möglich, du musst nur wissen, was du willst

Gruss

Spielkind

Hallo Dandreas,
welche Befehle möchtest Du denn von V+ nach VAL3 übernehmen und warum?
Ich habe früher mal V+ programmiert und bisher sehr wenig vermisst.

Vielleicht kann man die von Dir vermissten Befehle anders in VAL3 ausdrücken?

Meiner Meinung nach solltest Du nicht den Fehler machen und V+ Programme "eins zu eins" in VAL3 umsetzen.
Wie Frisco bereits richtig gesagt hat, sind die beiden Systeme völlig unterschiedlich - eine "einfache" Konvertierung würde wegen der unterschiedlichen "Eigenarten" der Systeme nicht richtig funktionieren.

Hallo Tequila_155,

auf der Homepage vom Stäubli (oder von der Hotline, beides kostenlos) bekommst Du verschiedene Programme ("Bibliotheken") für die einzelnen Verfahren, um Tools zu teachen.
Die haben da 2 Varianten:
a) die klassische 4 Punkt-Methode (ohne Tool abzumontieren, es fehlen aber RX und RZ RY)
b) eine Variante, bei der man nur 2 Punkte teachen muss (aber zwischendurch das Tool abmontieren), Vorteil: alle 6 Werte weren ermittelt

Gruss

Spielkind

Hallo cbrigger,

wenn ich das richtig verstanden habe, ist der BK9050 doch Modbus Slave (Server), oder?
Der Stäubli ist standardmäßig ebenfalls Slave (Server).
Die beiden werden sich also nie finden.

Entweder musst du bei Stäubli eine Feldbuskarte "ETH" kaufen und die als Modbus Master (Client) konfigurieren, oder du musst für den BK9050 ein SPS-Programm schreiben, welches als Modbus Master (Client) arbeitet.

Viele Grüße

Spielkind

Hi Odyssee,

isEmpty() ist ein VAL3-Befehl, kein Programm ...

Das Program start() sieht so aus:

program start()
  begin
    taskCreate "motion",100,motion()
  end

das Programm motion() sieht so aus:

program motion()
  begin
    // warten, dass vorherige Fahrbefehle völlig abgearbeitet wurden
    waitEndMove()
    // Fahrbefehl absetzen
    movel(pZiel,tGreifer,mSchnell)
    // nun soll der Ausgang angesteuert werden
    do
      // digitalen Ausgang toggeln
      doAusgang=!doAusgang
      // 20Hz entsprechen 0.05 Sekunden 
      delay(0.05)
      // so lange, bis der Roboter 'angekommen' ist
    until isEmpty() == true
end

Hi Odyssee,

ach so, nun habe auch ich es verstanden:

Wie schon vorher geschrieben, werden Fahrbefehle "einfach" an die Bahnplanung (den Motionstack) geschickt. Damit ist für den Programminterpreter der Fahrbefehl erledigt und er kann im Programm weitermachen.
Im einfachsten Falle könnte dein Programm so aussehen:

// warten, dass vorherige Fahrbefehle völlig abgearbeitet wurden
waitEndMove()
// Fahrbefehl absetzen
movel(pZiel,tGreifer,mSchnell)
// nun soll der Ausgang angesteuert werden
do
    // digitalen Ausgang toggeln
    doAusgang=!doAusgang
    // 20Hz entsprechen 0.05 Sekunden 
    delay(0.05)
// so lange, bis der Roboter 'angekommen' ist
until isEmpty() == true

Das obige Schnipsel ist nur zeitlich genau, wenn Du es in einem Echtzeittask aufrufst (also mit taskCreateSync ). Desweiteren wird im obigen Beispiel einfach angenommen, dass der Roboter dann auch fährt. Also Not-Aus, Antriebe Aus, falsche Betriebsart usw. würden den Ausgang endlos weiterblinken lassen.

Einen völlig anderen Ansatz bekommst Du, wenn Du mit dem Befehl
$getMoveId() - aus dem Expansion-AddOn, wenn das Betriebssystem < 7.0 ist
getMoveId() - im Standard-Befehlsumfang, wenn dein Betriebssystem >= 7.0 ist
arbeitest.

Damit könnte das Beispiel so aussehen:

movej(irgendwas)
movel(irgendwas)
// Fahrbefehl in den Motionstack, gleichzeitig bekommt man in nNummer eine eindeutige Kennung für diesen Fahrbefehl zurück
nNummer = movel(pZiel,tGreifer,mSchnell)
movel(irgendwas)
movej(irgendwas)
// darauf warten, dass dein "besonderer" Fahrbefehl ausgeführt wird - der Roboter also gerade in Richtung pZiel fährt
wait(getMoveId() >= nNummer)
// deinen Ausgang blinken lassen
do
    // digitalen Ausgang toggeln
    doAusgang=!doAusgang
    // 20Hz entsprechen 0.05 Sekunden 
    delay(0.05)
// so lange, bis der Roboter 'angekommen' ist
until getMoveId() > nNummer + 1

Bei diesem Beispiel könnten alle Zeilen beginnend mit wait(getMoveId() >= nNummer) auch in einem anderen Task laufen.
Die Fahrbefehle wären also in einem "normalen" Task (taskCreate), die Aktionen, die du bahnbegleitend machen möchtest, würden dann in einem Echtzeittask (taskCreateSync) stattfinden. Die Synchronisierung von Bahnausführung und Aktion geschieht dann über die eindeutige Kennung und getMoveId().

Viel Erfolg

Spielkind

Hallo Odyssee,

ich verstehe deine Frage(n) und deine Aufgabenstellung nicht ...

Vielleicht mal generell:
Es gibt im System Asynchrontasks (viel Code pro "Zeit", aber nicht Echtzeit) und Synchrontasks (Echtzeit, aber nur verhältnismäßig wenig Code pro "Zeit").
Alle Fahrbefehle (egal aus welchem Task) werden in den Motionstack (dem Eingangspuffer der Bahnplanung) kopiert und nach und nach durch die Bahnplanung an die Verstärker gefüttert.

Versuche doch bitte, einem Langsamdenker wie mir dein Problem ein wenig anders näherzubringen

Viele Grüße

Spielkind

Hallo Robotiker,

wie Du schon selbst gesagt hast, kann man nun mal nicht mit konstanter Geschwindigkeit durch eine Ecke fahren.
Du wirst also grundsätzlich immer einen Kompromiss finden müssen.
Das ist bei allen physikalischen Systemen so: Auto fahren mit konstant 50km/h um die Ecke wird nicht gehen.

Den Roboter kann man (natürlich) 'zwingen', Dinge zu tun, die man normalerweise nie machen (sollte):
Stelle mal den Verfahrbefehl in der Ecke auf sehr hohe ACCEL- und VEL-Werte (viel höher als 100%).
Natürlich wirst Du dann die entsprechende Achse(n) überlasten - ob die das auf die Dauer überleben ...

Eine andere (bessere) Variante wäre, den Anstellwinkel des Tools so zu verändern, dass mehrere Achsen an der Richtungsumkehr beteiligt sind bzw. Achsen beteiligt werden, die schneller sind (in der Regel je näher am Tool, desto schneller die Achse).
Diesen Ansatz kann man auch erreichen, indem man das Tool anders konstruiert.

Ich kann Dir da ansonsten nur viel Glück wünschen

Gruss

Spielkind

Hallo Odyssee,

eine Eigenschaft einer Tool-Variablen ist ein digitaler Ausgang. Du kannst also einer Tool-Variablen einen digitalen Ausgang zuweisen und anschliessend mit open(meinTool) den entsprechenden Ausgang schalten.

Da ich bisher eher keine Tools gefunden habe, die nur mit dem Schalten eines Ausgangs (ohne Sensorik) klarkommen, nutze ich diese Fähigkeit nicht.

Stattdessen die althergebrachte Methode vom eigenen Unterprogramm "greiferOeffnen()". Darin kann ich dann trotzdem die eingebauten Ventile ansprechen:

io:valve1 = true
io:valve2 = true

schaltet beide Magnetventile.

Beide Magnetventile sind bereits standardmäßig von Stäubli verdrahtet. Du brauchst also nichts hardwaretechnisches erledigen ...

Gruss

Spielkind

Hi Odyssee,

Zitat

Muss man neue Profile einzeln für den Emulator und den Controller anlegen?

Es hängt davon ab, wie du arbeitest.
Ich lege grundsätzlich für jeden Roboter eine eigene "Zelle" mit dem Cells Manager von Stäubli Robotics Studio an.
Diese Zelle ist in Wirklichkeit ein Ordner, in dem dann alle "meine" Dateien liegen --> mein Arbeitsordner für diesen einen speziellen Roboter.

Alle Dinge, die ich nun mache, mache ich in der Regel immer mit dem Stäubli Robotics Studio (z.B. Profile anlegen, Modbus konfigurieren, programmieren etc).
Anschließend nutze ich den Transfer Manager, um die geänderten Sachen auf die Steuerung zu schieben.
Sollte ich mal Änderungen auf der Steuerung direkt machen, nutze ich ebenfalls den Transfer Manager, um dann die Dateien von der Steuerung in meine Zelle (meinen Arbeitsordner) zu kopieren.

Aber Achtung: Deine Zelle (dein Arbeitsordner) ist niemals und wird niemals ein Backup der Steuerung !

Du kannst allerdings deine Profile auch direkt in der Steuerung anlegen (wie oben beschrieben). Dann kann eben dein Emulator nicht auf das Profil zurückgreifen, was nicht "schlimm" ist, wenn Du sowieso nicht mit dem Emulator arbeitest.

Gruss

Spielkind

Hallo Odyssee,

aber deine Variante mit io:portSerial1 = string müsste trotzdem funktionieren (wenn Du VAL3 V6 nutzt).
Bei VAL3 V7 würdest Du mySioVariable = string schreiben ...

Schicke doch mal die entsprechenden Fehlermeldungen ...

Gruss

Spielkind

Hi Odyssee,

nutzt Du VAL3 Version 7 oder 6?
Bei der Version 7 musst Du erst eine globale Variable vom Typ sio anlegen und die dann mit deiner seriellen Schnittstelle verlinken um sie nutzen zu können.
Bei der Version 6 existiert eine IO-Bibliothek (wird vom Betriebssystem angelegt und verwaltet) in der die serielle Schnittstelle auftaucht.

Zu deinem Programm:
die Befehle "toBinary" sind in deinem Beispiel überflüssig. Ich würde es so programmieren:
var[0] = "x"
var[1] = "y47"
var[2] = "z3.14"

// step ist überflüssig, wenn sowieso 1, size liefert dir Größe des Arrays, praktisch, wenn das Array var mal größer oder kleiner wird.
for i = 0 to size(var)-1
for j = 0 to len(var[i])-1
// asc liefert den unicode an der Stelle "j"
nZeichen = asc(var[i], j)
// das Zeichen senden, io:portSerial nur bei VAL3 Version 6, bei V7 muss anstelle die sio-Variable eingetragen werden
sioSet(io:portSerial1, nZeichen)
endFor
// sende Carriage return
sioSet(io:portSerial1, 13)
// sende Line Feed
sioSet(io:portSerial1, 10)
endFor

Oder der andere sehr viel einfachere Vorschlag:

var[0] = "x"
var[1] = "y47"
var[2] = "z3.14"

for i = 0 to size(var) - 1
io:portSerial1 = var[i]
// sende Carriage return
sioSet(io:portSerial1, 13)
// sende Line Feed
sioSet(io:portSerial1, 10)
endFor

Viel Erfolg

Spielkind

Zitat

unter dem Verzeichnis *\Staubli\CS8\*Dein Rob*\usr\configs\profiles findest du Standardmäßig zwei *.cfx - Dateien für die Profile.
Da kannst du dir eine kopieren, entsprechend wie du es benötigst bearbeiten und über SRS auf die Steuerung übertragen. Danach die Steuerung neustarten und du hast das Profil zur Verfügung.

Naja, geht schon so, ich würde aber doch den Profil-Editor (SRS | Werkzeuge | Profil-Editor) zum Anlegen und Bearbeiten von Benutzerprofilen bevorzugen.
Man kann keine Fehler machen (z.B. XML-Steuerzeichen vergessen).
Entweder legt man mit diesem Tool die Profile direkt auf der Steuerung an oder erst auf dem PC und kopiert sie dann mit dem Transfer-Manager auf die Steuerung.
Eine Reboot der Steuerung ist danach nicht nötig.

Gruß

Spielkind

Hallo Odyssee,

es gibt von Stäubli eine kostenlose Bibliothek, mit der man ziemlich einfach "Arbeitsräume" anlegen kann. Das können Quader, Kugeln, "Stangen" sein.
Anschließend kann man die Bibliothek fragen, ob der Roboter momentan in einer der Räume ist, und wenn ja in welchem.

Aber wie meine Vorredner schon gesagt haben, ein 100% Schutz ist das nicht.

Zitat

Schneller als die 4 ms geht es ja nicht, weil das der Takt ist, in dem der Roboter seine Bewegungen berechnet. (Was übrigens verglichen mit anderen Robotersteuerungen ziemlich schnell ist.)

Das stimmt so nicht ganz. Man kann das Betriebssystem auch mit anderen Takten als 4ms laufen lassen. Je schneller aber der Takt, desto weniger Zeit bleibt für die VAL3-Anwendung. Mit einem Zyklus von 2ms kann man vielleicht noch leben, wenn die VAL3-Anwendung nicht so groß ist.
Soll es allerdings 1ms sein, braucht man definitiv eine schnellere CPU. Gibts dann bei Stäubli zu kaufen ...

Aber für deine Anwendung, finde ich das dann "Overkill".

Gruss

Spielkind

Hallo Rene,

um deine Fragen beantworten zu können, müssten wir wissen, an welcher Steuerung der jeweilige Roboter hängt.

Dein RX130 kann nur an einer CS7-Steuerung hängen. Diesen programmierst Du in V+ (von Adept)
Ein RX130B kann an einer CS7B- (V+) oder an einer CS8-Steuerung (programmiert in VAL3) hängen.
Der RX160 funktioniert nur an einer CS8C-Steuerung (VAL3).

Zu den CS7 / CS7B Systemen kann ich dir nicht viel sagen, meine weiteren Antworten beziehen sich auf CS8- und CS8C-Steuerungen:
- Du kannst keine Achsen abwählen, aber es hält dich natürlich nichts davon ab, eine Bewegung zu programmieren, die nur Achsen 5 und 6 betrifft
- Es gibt in VAL3 Befehle, um die Schleppfehler, Motorströme und Geschwindigkeiten auszulesen.
- Um die Daten übers Netzwerk zu schicken, hast Du (wie immer) mehrere Möglichkeiten:

• Wenn Du mit Netzwerk dein ProfiNet meinst, schickst Du die Werte als Fließkommazahl am einfachsten mit dem Befehl aioSet()


• Wenn Du mit Netzwerk TCP/IP meinst, gibt es wieder mehrere Möglichkeiten:
  

• 
  

  • Du schickst die Daten per eingebauten Modbus/TCP (funktioniert wie ProfiNet allerdings über den Feldbus Mdbus/TCP, der auf TCP/IP basiert
  
  
  • Du schreibst die Daten aus VAL3 in eine Datei auf der Steuerung und holst diese Datei dann später per FTP ab.
  
  
  • Du installierst auf deinem PC einen FTP-Server, meldest ihn auf der Steuerung an und schreibst deine Daten direkt in eine Datei auf deinem FTP-Server
  
  
  • Du schreibst dir in VAL3 ein TCP/IP-Protokoll, welches die Daten direkt an deine Software schickt (ohne den Umweg über eine Datei). Hier bieten sich dann die Befehle toBinary und fromBinary an, um die Daten direkt in das passende Format umzuwandeln (Byte, Word, DWord, Single Precision Floating Point oder Double Precision Floating Point, Motorola- oder Intel-Format (auch als LittleEndian oder BigEndian bekannt))
    
  • [li]
  
  

Die Datenaufnahme sollte in einer Echtzeittask mit 4ms Zyklus geschehen. Der Befehl dazu lautet taskCreateSync. Das verschicken der Werte würde ich allerdings in einer Standardtask (Befehl taskCreate) erledigen. Ich stimme dir zu, dass du die Werte wahrscheinlich puffern musst, um sie alle rechtzeitig wegschreiben zu können.

Wenn Du dich in die Roboterprogrammierung "Adept" einliest, macht das nur Sinn, wenn du eine CS7 oder CS7B Steuerung hast. Für den RX160 müsstest Du dich in VAL3 einlesen ...

Gruss

Spielkind

Hallo AchimE,

es gibt noch mindestens eine dritte Möglichkeit:

Die SPS gibt dem Roboter den Auftrag "Hole Teil aus Spannvorrichtung und lege es in X". Nach Beendigung des Jobs fährt der Roboter wieder in GS.

Letzendlich funktionieren alle Varianten und es kommt nur auf deine persönliche Vorliebe an.
Ich persönlich mag deine Variante 1 nicht, da der Roboter immer über GS fahren muss und dadurch jede Menge Taktzeit verliert.

Dein Argument, dass bei der Variante 2 es schwer ist, den Roboter in GS zu fahren, wenn etwas schief läuft, ist meiner Meinung nach nicht relevant.
Da Du dir eh überlegen musst, wie der Roboter in Grundstellung zu fahren ist, wenn er aus welchen Gründen auch immer bei Produktionsbeginn nicht in GS steht, ergibt sich hieraus dann auch die Lösung für deine Variante 2 (und auch für meinen dritten Vorschlag).

--> Ich würde dir deine Variante 2 empfehlen, wenn du möglichst viel auf der SPS machen willst, oder meinen dritten Vorschlag, wenn Du mehr auf Roboterseite erledigen möchtest.

Gruss und viel Erfolg

Spielkind