Hallo spec,
ja gibt es.
IF Present(VARIABLE) THEN
Grüße
Seit wann kann ich mit Present eine Variable überprüfen? Damit kann ich doch nur prüfen ob ein Optionales Argument beim Aufruf verwendet wurde.
Ich wüsste jetzt auch nicht das es eine funtion gibt die das prüft (im Rapid Handbuch hab ich auch nix beim überfliegen gesehen), auf was willst du auch prüfen wenn Rapid VAR immer mit Nullen initialisiert.
An deiner Stelle würde ich versuchen so eine Konstellation zu vermeiden, eine nicht beschriebene Variable abfragen klingt für mich einfach Falsch und sollte schon vom Ablauf gar nicht möglich sein.
Wenn du das nicht umschiffen kannst fällt mir nur ein Weg bei nicht booleschen Werten ein, initial mit
einem Wert beschreiben der nicht auftreten kann im Betrieb und dann abfragen ob man in dem Bereich ist.
In diesem Thread im englischen Forum haben wir auch schon über das Thema diskutiert.
Rapid selbst scheint in dieser Hinsicht auch nicht völlig im Reinen mit sich zu sein, sonst würde es die nicht gebrauchten Zusatzachsen in den Positionsdaten nicht mit 9E+09 vorbelegen.
Wenn es denn unbedingt nötig wäre, dann würde ich diesen Stil aufgreifen.
Seit wann kann ich mit Present eine Variable überprüfen? Damit kann ich doch nur prüfen ob ein Optionales Argument beim Aufruf verwendet wurde.
Guten Morgen,
da gebe ich dir vollkommen recht. Das hatte ich falsch in Erinnerung.
Der Befehl Present gilt nur für optionale Argumente. 
Morgen Leute,
Seit wann kann ich mit Present eine Variable überprüfen? Damit kann ich doch nur prüfen ob ein Optionales Argument beim Aufruf verwendet wurde.
Ich habe das auch so verstanden, aber natürlich habe ich gehofft, dass es trotzdem irgendwie möglich ist.
Aber selbst mit dem RAPID-Verfahren, bei dem nicht initialisierte Variablen initialisiert werden, kann ich etwas damit anfangen.
Vielen Dank euch.
Warum nicht mit einer einfachen IF-Abfrage?
IF Variable <> Initalwert Fehlerausgabe;
Bei KUKA habe ich sogar zwei Möglichkeiten: entweder über die VARSTATE-Funktion oder über Prozessfehler.
KRL sieht aber auch explizit vor, unvollständige Variablen zu verarbeiten. Mag historisch bedingt sein, aber dass PTP halbe Frames ebenso entgegennimmt wie E6AXIS ist eigentlich 'n Desaster. Möchte nicht wissen, wie viele Systementwickler in Augsburg ein Beißholz auf dem Schreibtisch liegen hatten deswegen.
Und dass es heute Roboterprogrammierer dazu erzieht, ziemlich dreckige Tricks anzuwenden. Weil man es kann. Insofern würde ich KRL nicht als Referenz hernehmen.
Mahlzeit!
Jetzt hänge ich mich auch noch einmal rein. Ich initialisiere Variablen grundsätzlich bei einer PowerOn-Routine. Es gibt auch noch mehr Möglichkeiten, wann ich Systemgetriggert initialisieren kann. Optional kann ich auch zu Beginn der main() eine Init-Routine einfügen.
Wenn ich einer Variablen keinen Wert gebe, dann sind sie entweder leer (String), FALSE (bool) oder 0 (num). Numerische Variablen initialisiere ich mit einem Wert, der im Prozess nicht auftreten darf. Damit habe ich bei der Fehlerauswertung die Möglichkeit, falsche Werte auszuschließen bzw. sicherzustellen, dass ein korrekter Wert vorhanden ist.
Hier einige Beispiele:
VAR num nCount := 5; initialisiert zu Beginn immer mit dem Wert 5.
VAR num nCount; initialisiert IMMER mit 0.
PERS num nCount := 3; wird einmalig mit 3 initialisiert, anschließend wird der Wert immer aktualisiert. Eine Persistente ohne Vorgabewert lässt der Compiler nicht zu.
CONST num nCount:=5; macht per sé keinen Sinn.. 
Eine Konstante ohne Vorgabewert ebenso wenig erlaubt.
Eine nicht initialisierte Variable gibt es beim ABB demzufolge nicht.
MfG
Have you tried a TRAP Routine for the variable? Before your program starts, check the variable and then according to that value, execute respective program.
