Eingangssignale über Ausgänge an SPS

SIGNAL ID_STRING_ECHO_01 $OUT[353] TO $OUT[360]

SIGNAL ID_STRING_ECHO_02 $OUT[361] TO $OUT[368]

SIGNAL ID_STRING_ECHO_03 $OUT[369] TO $OUT[376]

SIGNAL ID_STRING_ECHO_04 $OUT[377] TO $OUT[384]

SIGNAL ID_STRING_ECHO_05 $OUT[97] TO $OUT[104]

SIGNAL ID_STRING_ECHO_06 $OUT[105] TO $OUT[112]

SIGNAL ID_STRING_ECHO_07 $OUT[113] TO $OUT[120]

SIGNAL ID_STRING_ECHO_08 $OUT[121] TO $OUT[128]

SIGNAL ID_STRING_ECHO_09 $OUT[129] TO $OUT[136]

SIGNAL ID_STRING_ECHO_10 $OUT[137] TO $OUT[144]

SIGNAL ID_STRING_ECHO_11 $OUT[145] TO $OUT[152]

SIGNAL ID_STRING_ECHO_12 $OUT[153] TO $OUT[160]

; SPS ...

ID_STRING_ECHO_01=ID_STRING_01

ID_STRING_ECHO_02=ID_STRING_02

ID_STRING_ECHO_03=ID_STRING_03

ID_STRING_ECHO_04=ID_STRING_04

ID_STRING_ECHO_05=ID_STRING_05

ID_STRING_ECHO_06=ID_STRING_06

ID_STRING_ECHO_07=ID_STRING_07

ID_STRING_ECHO_08=ID_STRING_08

ID_STRING_ECHO_09=ID_STRING_09

ID_STRING_ECHO_10=ID_STRING_10

ID_STRING_ECHO_11=ID_STRING_11

ID_STRING_ECHO_12=ID_STRING_12

Hallo es hat nur untergeordnet hiermit, was zu tun und ich habe mir schon die CWRITE Doku durchgelesen, aber ein richtiges Beispiel finde ich nicht.

Ich würde gerne mehrere DI des Roboters setzen, vom Roboter aus, diese sind jedoch schreibgeschützt.

Jetzt war meine die DI einfach auf den Bus zu verknüpfen und diese dann über den Bus zu setzen.

Wisst Ihr, welchen Befehl ich nutzen kann, um z.B. einfach den $IN[4000] zu setzen?

Du kannst dir mal $iosim_opt anschauen. Ist aber nur für simulierte Steuerung gedacht. Eingänge sind halt Ein- und keine Ausgänge. Insofern ist das direkt nicht vorgesehen. Müsstest du sonst über deine SPS handeln.

Fubini

Super, danke für die Hilfe!

Aber ich habe was auf Kuka gefunden darüber

Zustand vor der Simulation: $OUT[8] == FALSE

1. Der simulierte Zustand des Ausgangs wird auf TRUE gesetzt. ($OUT-

SIM_TBL[8] = "1")

2. Die Simulation wird eingeschaltet. ($IOSIM_OPT = TRUE)

Der reelle Zustand gibt jetzt den simulierten Zustand wieder, d. h.

$OUT[8]==TRUE.

$OUT[8] kann nicht mehr geändert werden.

3. Die Simulation wird ausgeschaltet. ($IOSIM_OPT = FALSE)

Jetzt ist $OUT[8] == FALSE.

Durch das Ausschalten der Simulation wurde $OUT[8] auf den Zustand

vor der Simulation zurückgesetzt, d. h. FALSE. $OUT[8] kann wieder ge-

Allerdings ist

$IOSIM_OPT = TRUE auch schreibgeschützt, muss ich das in die Maschinendaten schreiben?

Es gibt keinen Grund, DI zu setzen, außer man will sich selbst starten.

Soll sich der Roboter selbst starten?

Nein ich nutze derzeit den Funktionsgenerator und hier gibt es die Option zur

Sensornachführung mittels

TECH [1].MODE = #Sensor

Analoger Eingang :

SIGNAL BANDGESCHW $ANIN[1]

ANIN ON $TECHIN[2] = FAKTOR * BANDGESCHW + OFFSET

Digitaler Eingang :

Eintrag in “$MACHINE.DAT”

SIGNAL $DIGIN1 $IN[20] TO $IN[28]

DECL DIGINCODE $DIGIN1CODE=#UNSIGNED

DIGIN ON $TECHIN[3] = FAKTOR * $DIGIN1 + OFFSET

Ich hätte es halt gerne ausprobiert, wie das dann aussieht, ob der Sensor einfach 1* Mal die halbe Periode, ganze Periode der Schwingung ausführen oder aber bis zum Spitzenwert oder wie es hier aussieht proportional zum Eingangswort.

Ich bin zwar gerade dran, mir was mit einem Interrupt zu Basteln, aber ich habe keine Ahnung, ob das aufs Gleiche hinauskommt.

Sonst hätte man sich einfach 4 Bit, genommen, das Byte spezifiziert und dann mit dem Faktor die Amplitude gezerrt oder gestaucht.

Ich habe halt hier keinen Zugriff auf die SPS das für sowas nachteilig.

Denn jetzt sage ich einfach, wenn Interrupt 21 kommt bei Variable X=1, gehe zur Funktion vom Interrupt und dort $TECHIN[1] = 1.5 (Maximalwert wäre 2 ) Resume.

Ist aktuell noch außerhalb vom FGEN, denn sonst würde ich ja den FGEN aufrufen und dann würde diese automatisch schwingen... aber vermutlich so lange bis TECH[1].MODE=#OFF waere

Mh, okay.

Ich weiß nur, dass man die Signaldefinition oft umleiten kann. Das Programm greift auf die benannte Variable zu, und ob hinter der jetzt $IN[..] oder $OUT[...] als Definition steht ist dann egal. Gelesen werden kann beides, letzteres eben dann auch von anderer Stelle aus geschrieben.

Wie das bei dem Techpaket ist weiß ich aber nicht....

Okay verstehe ich jetzt nicht zu 100 % mit dem Umleiten, also es ist gemeint das der z.B. DI einer Variable zugewiesen wird und dann die Variable gesetzt, ist dies dann nicht Quais eine doppelte Initialisierung mit der Prio des Eingangs außerdem müsste ich ja dann wieder mit dem = Operator zuweisen, das geht ja dann nicht da benötige ich Beispiel-Code

Ich habe hier aber noch einen Eingang vom Messtaster, dann nutze ich den ggf. einfach ist zwar dann nut 1 Bit aber zum probieren wirds langen

Wenn da irgendwo in einer .DAT steht:

SIGNAL variablendings $IN[20] TO $IN[28]

dann kann man das oft auch umändern in

SIGNAL variablendings $OUT[2000] TO $OUT[2008]

und es interessiert die Funktion, die nur lesend auf "variablendings" zugreift, nicht die Bohne.

Man selbst aber kann - entweder über die Variablenansicht oder über die Ausgangsansicht, oder auch über den Hintergrundtask programmiert - die Variable bzw. die Ausgangssituation ändern, weil es ja nicht mehr schreibgeschützt ist.

Das meinte ich nur, wäre vielleicht einen Versuch wert.

Ah okay ich verstehe, werde das dann mal ausprobieren.

Aber als Fazit bis jetzt, das Beispiel ist vermutlich fehlerhaft.

Das lässt sich gar nicht so auf in die Maschdata schreiben, wie in der Anleitung.

SIGNAL $DIGIN1 $IN[20] TO $IN[28]

DECL DIGINCODE $DIGIN1CODE=#UNSIGNED

DIGIN ON $TECHIN[3] = FAKTOR * $DIGIN1 + OFFSET

Sofern ich mich dann nur auf die

SIGNAL $DIGIN1 $IN[20] TO $IN[28] oder bei mir SIGNAL $DIGIN1 $IN[1XX]

beschraenke passt auch nicht

DECL DIGINCODE $DIGIN1CODE=#UNSIGNED - hier wird gemerkt, dass ein Objekt nicht existiert.

DIGIN ON $TECHIN[1]=1*$DIGIN - hier wird ein offene Klammer erwartet ( ergibt keinen Sinn

Der Robo ist zwar gemäß Rampe in Z-Achse gefahren aber unendlich lange, da kein Sensorsignal kam

Ich habe aber auch gesehen, dass das Signal gar nicht übertragen wurde zumindest laut Kaltstart, ggf. muss ich das als Admin direkt im Pad ändern

Ist das Techpaket denn überhaupt installiert?

Die Systemdateien werden bei der Installation erweitert. Der erste Fehler deutet darauf hin, dass der ENUM-Datentyp "DIGINCODE" gar nicht existiert. In WV kann man das recht einfach erforschen, indem man mit Rechtsklick auf Datentyp oder Variable und "gehe zu Deklaration" in an die entsprechende Stelle springt.

Die Anleitungen sind allgemein nicht immer ganz sauber, manchmal haben die sich in der Doku auch schlicht verschrieben...

Und dann: hast Du RE: Syntaxfehler bei DIGIN ON gesehen, bzw. ist Dein Gerät alt genug?

Das Techpaket sollte immer installiert sein, da es der Standardfunktionsgenerator ist, der angeblich seit KCR2 drauf ist und es ist eine KCR4 also das sollte passen, mittlerweile gibt's halt RSI oder fürs Schweißen ArcWelding.

Ich hatte auch gedacht das man mit Techangle_C/ Techangle den Flunge bzw. das Tool pendeln lassen kann.

es zeigt sich jedoch, dass die Techangle bezogen auf den TTS irgendwie angewandt wird Arbe anscheinen nur auf den orthogonalen Achsen.

Dies wirkt aber auch so, dass, wenn ich in B einen Winkel vorgebe, und das Offset in Z einstelle, dass der Roboter dann einfach im vorgegebenen Winkel schraeg nach oben fährt. Ich dachte aber, dass er in Z-Faehrt oder um die Z-Achse um den Winkel B pendelt mit dem Tool.

Mit ArcWeld. geht sowas... laut Bedienungsanleitung

Ich habe auch nochmals in der Docu von den Systemvariablen geschaut:

Datentyp Enum

Wert

min.

Einheit

Wer

max.

In Datei Steu\Mada\$machine.dat

Originalzeile DECL DIGINCODE $DIGIN1CODE=#UNSIGNED

...

DECL DIGINCODE $DIGIN6CODE=#UNSIGNED

Bemerkung Vorzeichenbelegung für $DIGIN1 ... 6

Optionen Auswirkung

#SIGNED Mit Vorzeichen.

#UNSIGNED Ohne Vorzeichen.

Ist also so deklariert wie es sein sollte

Ich konnte aber in Syntaxfehler bei DIGIN ON

den Grund finden denke ich.. gibt's einfach nicht mehr

Da ich gerade auch was simulieren wollte, aber eine vollwertige Steuerung haben, durchsuchte ich sämtlich Verzeichnisse, u.a. auch das C:\KRC\ROBOTER\INIT

ist diese Verzeichnis ausschließlich für diesen PC-Typen vorhanden?

Siehe: https://my.kuka.com/s/product/…kss-87/01t1i000001PcVNAA0

und kann man bei einer KCR4 keine Anpassung in einem anderen Verzeichnis machen, normalerweise müsste ja auch die echte Steuerung eine Hardwareconfig haben.

Zitat von SuS

durchsuchte ich sämtlich Verzeichnisse, u.a. auch das C:\KRC\ROBOTER\INIT

ist diese Verzeichnis ausschließlich für diesen PC-Typen vorhanden?

Siehe: https://my.kuka.com/s/product/…kss-87/01t1i000001PcVNAA0

C:\KRC\ROBOTER\INIT ist ein Pfad aus Zeiten bis Software KSS 7.1.

Zitat von SuS

und kann man bei einer KCR4 keine Anpassung in einem anderen Verzeichnis machen, normalerweise müsste ja auch die echte Steuerung eine Hardwareconfig haben

Ein Blick in WorkVisual bei der KRC4 und Du siehst die Hardwareconfig und seine Möglichkeiten, einen Eingriff zu Tätigen.

SuS : Bitte für solche Sachen einen eigenen Beitrag eröffnen. Da direkt Steuerung / KSS-Version mit Optionen, Robotertyp angeben.

Wie es aussieht, versuchst Du mit einem Bsp. einer alten KSS was zu Verwirklichen. Bitte solche Sachen auch posten, damit es klarar wird, mit was Du Dich herumschlägst.

Ja okay, es ist ein altes Beispiel,

ich nutze eine der KSS 8 Versionen.

Klar, im Arbeitsbereich findet man natürlich die Robo.dat und Masch.dat

aber kein .init und der Versuch mit dem Kopieren der Befehle:

office=TRUE

$ISOSim_opt=TRUE

Irgendwo reinzukopieren geht halt nicht (wäre halt auch irgendwie eine simple Lösung, eine Steuerung dann mit dem Parameter vorzugaukeln, es sei ein Office-PC, um die Sachen halt im Handbetrieb zu testen...na ja und Office Lite würde dann halt nur den Roboter auf dem PC-Simulieren. )

Der $TECHIN= 'Irgendwas' scheint halt einfach obsolet zu sein, sodass man vermutlich zu RSI greifen muss.

Der $TECHIN= 'Irgendwas' beim Funktionsgenerator scheint halt einfach obsolet zu sein, sodass man vermutlich zu RSI greifen muss.

Bzgl. analoger Sensoren ist halt keine wirkliche Karte verbaut, wie man sie von Siemens kennt, sondern es läuft natürlich alles übern Bus.

Die AIN lassen sich aber nicht einfach mit dem BUS-Koppeln, dann habe ich bei IFM hereingeschaut, die nutzen mittlerweile (https://www.ifm.com/de/de/shar…analog-signals-to-io-link), da der $DIGIN1CODE ja zum Syntaxfehler führt, ist die Option halt Fehlanzeige und nicht mehr verfügbar

Es könnte aber noch DATALINK mit Sen_PREA klappen, wird auch beim Schweißen genutzt

Zitat von SuS

ich nutze eine der KSS 8 Versionen.

Sorry, dies ist keine Angabe!

Es gibt 7 verschiedene Versionen, die sich z.T. gross unterscheiden.

Unter anderem lässt ab KSS 8.6 das Rückverschalten von Busausgängen auf KRCE/A's zu.

Zitat von SuS

..da der $DIGIN1CODE ja zum Syntaxfehler führt..

$DIGIN ist ein alter Zopf aus KRC32-Zeiten. Mal überlegt, was es genau ist und wie Du dies über eine Signalvereinbarung in gleicher Manier nachbilden kannst ?

Zitat von SuS

Die AIN lassen sich aber nicht einfach mit dem BUS-Koppeln,....

????

In WoV mal versucht, was da alles geht ?

Z.B. 16 digitale Eingänge zusammenfassen, Typengleich machen und dann Analogeingang zuordnen.

Okay danke schonmal dafür,

was ich mich aber frage ist wo bekommst Du diese Infos schnell her, wenn ich schon die Suchoption Kuka Expert nutze und zweitens wenn ich schon den Support bemühe bzgl. dieses Anliegens und dann nur

"

Verwenden Sie anstelle der $DIGIN Signalvereinbarung nicht einen Adressraum, sondern wählen einen $ANIN[]

SIGNAL KORREKTUR $ANIN[1]

ANIN ON $TECHIN[1] = FAKTOR * KORREKTUR + OFFSET"

Aber mit der Aussage sollte es ja dann möglich sein die digitalen Eingänge mit AIN verschalten, sodass ich dann wenigstens den betrieb mit einem Taster ausprobieren könnte.

Bzgl. Datalink habe ich auch "nur" folgendes Beispiel gefunden:

MEASURE_MULT = (TIME_STAMP * 1000)/12

$SEN_PINT[1]=0

$TECH[1].MODE=#OFF

$TECH[1].CLASS=#DATALINK

$TECH[1].FCTCTRL.GEOREF=#X

$TECH[2].FCTCTRL.GEOREF=#Y

$TECH[3].FCTCTRL.GEOREF=#Z

$TECH[4].FCTCTRL.GEOREF=#A

$TECH[5].FCTCTRL.GEOREF=#B

$TECH[6].FCTCTRL.GEOREF=#C

$TECHSYS=#BASE$VEL.CP=0.01

$VEL.ORI1=1

$VEL.ORI2=1

$ACC.CP=0.01

$ACC.ORI1=1

...

;*** SET B_FRAME ***

$SEN_PINT[2]=0

$SEN_PREA[1]=$BASE.X

$SEN_PREA[2]=$BASE.Y

$SEN_PREA[3]=$BASE.Z

$SEN_PREA[4]=$BASE.A

$SEN_PREA[5]=$BASE.B

$SEN_PREA[6]=$BASE.C

$SEN_PINT[1]=6 ;SET b_frame

$TIMER_STOP[10]=TRUE

$TIMER[10]=–10000

$TIMER_STOP[10]=FALSE

WAIT FOR (($SEN_PINT[2]<>0) OR $TIMER_FLAG[10])

$TIMER_STOP[10]=TRUE

IF $SEN_PINT[2]<>1 THEN

OCCU_MSG(6)

RETURN($SEN_PINT[2]) ;FEHLER SENSORSET

ENDIF

aus einer OCCUBOT VI R 1.0 Doku, war das Einzige was ich dazu gefunden hatte.
$SEN_PINT ist eigentlich Sensor-Signal senden
$SEN_PREA[1] ist eigentlich Sensor-Signal lesen bzw. zuordnen

Bezogen auf:

SIGNAL $DIGIN1 $IN[20] TO $IN[28]

DECL DIGINCODE $DIGIN1CODE=#UNSIGNED

DIGIN ON $TECHIN[3] = FAKTOR * $DIGIN1 + OFFSET

Hat sowas zum Testen wie

oder

$SEN_PREA[1]= FAKTOR

$TECHIN[3] = $SEN_PREA[1]

nicht funktioniert. SEN_PREA wir hier aber auch als Frame genutzt, glaube ich.

daher könnte es natürlich mit SEN_PREA uber die
Techangle funktionieren.
Hier habe ich aber auch nur ein Beispiel gefunden nach dem Muster

Techangle=(A 0, B 10, C 0)

und nicht etwas

Techangle=(X 0, Y 0, Z 10,A 0, B 0, C 0) oder
Techframe=(X 0, Y 0, Z 10,A 0, B 0, C 0)

Techangle= Techframe

Solltest du da noch einen Tipp haben wäre dies auch klasse