# Keyence IV3 - Automatische Programmumschaltung



## C_wie_Cäsar (27 August 2022)

Hallo Zusammen,

ich habe ein Problem mit dem AI Kamera von Keyence. Mein Aufbau ist folgender. 


SteuerungSiemens 1518FTIA VersionV 15.1KameraKeyence IV3 (https://www.keyence.de/products/vision/vision-sensor/iv3/)Angebunden über:Profinet

Es funktioniert eigentlich alles recht gut. Ich habe die Kamera mit der GSD-Datei in der Hardwarekonfiguration angelegt, habe mir mit der Anleitung UDT's erstellt und lese die Prozesswerte in die jeweilige Datenstruktur ein. Alles soweit in Ordnung. Ich kann ein Bild von der SPS triggern, ich bekomme die Auswertung (io/ng) und auch die Statistik lässt sich über den Prozesswert einlesen. Nur die Programmumschaltung funktioniert nicht. Ich habe mich sowohl an die Anleitung gehalten als auch am Beispielprogramm orientiert. Leider funktioniert die Umschaltung nicht. Der Grundgedanke von mir war relativ simpel:
	

		
			
		

		
	



Wenn "Prg. Wechsel Anfordern" kommt, schreibe ich die Nummer 5 in den Ausgang für "neue Programmnummer" und stoße mit Q0.2 den Wechsel solange an, bis mir die Kamera den Eingang I0.2 bringt. Der Programmwechsel funktioniert auch, aber immer nur auf Prg. Nr.: 0. Da er zwar wechselt aber nicht auf die gewünschte Nummer, bin ich mir nicht sicher ob er ein fehlerhafte Nr. bekommt (und in der Fehlerroutine immer auf Nr. 0 umschaltet) oder ob der Wert zur falschen Zeit kommt und beim umschalten die Variable wieder 0 ist (und er deswegen auf Prg. Nr. 0 wechselt)

Deswegen hab ich folgende Dinge schon ausprobiert:

1. "Prg. Wechsel Anfordern" als Flanke realisiert
2. Zuerst die Programm Nummer geschickt und dann nach ein paar Sekunden den Ausgang Q0.2 angestoßen 
3. Q0.2. als Flanke realisiert.
4. Die Programm Nummer dauerhaft geschrieben und dann Q0.2 angestoßen (einmal als Flanke, einmal dauerhaft und einmal wie im Bild mit Rücksetze)
5. Von mir angelegte Datenstruktur als Prozesswerte geschickt
6. Direkt die Ausgänge angesteuert
7. Die Prg. Nummer als WORD, UINT und INT geschickt

Jedoch waren alle Maßnahmen ohne Erfolg. Deswegen hoffe ich, dass jemand von euch mit den Kameras schon Erfahrung hat und vll. einen Kniff kennt. Fall nicht, werde ich mich am Montag wohl an den Support wenden müssen.

Grüße, Cäsar


----------



## revve (27 August 2022)

Was mir jetzt spontan einfallen würde ist, dass deine Kamera evtl. High und Low Byte dreht, und da laut Handbuch die Gültigkeit bei Programm Nr. 127 endet, könnte das noch dazu führen, dass die Nummer als ungültig gilt. Hast du mal versucht den Wert zu drehen?

Sonst sieht das mit dem Set/Reset Ablauf ja aus wie der Serviervorschlag vom Hersteller.


----------



## C_wie_Cäsar (27 August 2022)

Kurz als Hinweise, es gibt die Einstellung "Byte-Wechsel" in der Kamera. Dort ist aber nur von Text die Rede (Zu einem der OCR erkannte Text und zum anderen der Dateiname zum speichern der Bilder) und deswegen habe ich den auf "Deaktiviert" gelassen. Dürfte aber meiner Meinung nach keine Rolle spielen.



> Hast du mal versucht den Wert zu drehen?


Du meinst praktisch anstatt den Wert 1 den Wert 128 zu übergeben? 
0000 0001 => 1000 0000
1                => 128



> Sonst sieht das mit dem Set/Reset Ablauf ja aus wie der Serviervorschlag vom Hersteller.


Ja ziemlich. Nur die Flanken Merker die im Herstellerprogramm mit einer Selbsthaltung vom Senden Befehl verodert sind habe ich weggelassen.


----------



## revve (27 August 2022)

C_wie_Cäsar schrieb:


> Du meinst praktisch anstatt den Wert 1 den Wert 128 zu übergeben?
> 0000 0001 => 1000 0000
> 1 => 128


eigentlich 0000 0001 -> 1 0000 0000 aber ja, das würd ich versuchen
Du hast dazu doch bestimmt ne Diagnosesoftware wo du erkennst was die Kamera eingangsseitig liest, oder? Dann würdest es ja gleich sehen



C_wie_Cäsar schrieb:


> Ja ziemlich. Nur die Flanken Merker die im Herstellerprogramm mit einer Selbsthaltung vom Senden Befehl verodert sind habe ich weggelassen.


aber der Output ist ja der selbe, dass der Programmwechseltrigger ansteht bis Rückmeldung fertig vom Gerät.


----------



## C_wie_Cäsar (27 August 2022)

> Du hast dazu doch bestimmt ne Diagnosesoftware wo du erkennst was die Kamera eingangsseitig liest, oder? Dann würdest es ja gleich sehen


Leider nicht. Ich habe versucht aus dem IV3 Software irgendwelche Informationen raus zu ziehen aber da sieht man leider nur die Hardware-E/A Schnittstelle.


----------



## TP-Inc (28 August 2022)

Wie sieht die GSDML aus? Das sind bei Keyence of sehr viele Einzelmodule. Evtl ist die Adresse von der Programmnummer außerhalb deines UDTs


----------



## C_wie_Cäsar (28 August 2022)

TP-Inc schrieb:


> Wie sieht die GSDML aus? Das sind bei Keyence of sehr viele Einzelmodule. Evtl ist die Adresse von der Programmnummer außerhalb deines UDTs


Aus diesem Grund habe ich schon einmal direkt die Ausgangswörter angesprochen. Leider auch ohne Erfolg.


----------



## deg0 (29 August 2022)

Bis dato hatte ich nur IV1 / IV2 angesteuert. Die Adressierung von den Eingängen/Ausgängen passt. Bisher habe ich immer die Programmnummer auf die Schnittstelle geschrieben und mit Verzögerung die Umschaltung gestartet.
Das Programm ist der Kamera ist aber angelegt?


----------



## C_wie_Cäsar (29 August 2022)

Ja. Programm Nummer ist hinterlegt. Ich habe jetzt Kontakt mit dem Support und werde die Lösung hier posten, sobald wir sie haben. Vielleicht hilft es dem nächsten


----------



## C_wie_Cäsar (31 August 2022)

Hallo Zusammen,
auch wenn sich mir noch nicht exakt erschließt warum, funktioniert es nun. 
Folgenden Aufbau hatte ich:




So funktionierte es nicht. Auch nicht, wenn ich anstatt der Variablen aus der UDT die direkten Ausgänge verwendet habe. Wenn ich aber die Ausgänge mit einer Forcetabelle gesteuert habe, gings problemlos. Daraufhin habe ich mein Programm dahingehend verändert:




Ich stoße also den Wechsel erst dann an (außerhalb des Keyence_IV3_FB) wenn die Prozesswerte an die HW-Kennung bereits geschrieben wurde. Damit klappt es jetzt nun tadellos. 

Wie eingangs erwähnt, bin ich mir nicht ganz sicher warum es nun funktioniert. Ich gehe davon aus, dass das zyklische Schreiben der Ausgänge meinen Wert irgendwie überspielt hat. Ich konnte nämlich beim Beobachten des Ausgangs auch nicht die aktuelle Nummer erkennen (beim Steuern über die Forcetabelle aber schon).

*Hoffe es hilft irgendjemanden einmal weiter.* Falls mir jemand erklären kann warum das zyklische Schreiben der Prozesswerte das Problem war, wäre ich zudem sehr froh 

Grüße, Cäsar


----------



## TP-Inc (1 September 2022)

Kannst/darfst du deinen Code posten? Das sieht eher nach einem Problem im SPS-Programm aus als im VisionSensor. Vor allem der Teil wie die Ausgänge geschrieben werden ist interessant


----------



## C_wie_Cäsar (3 September 2022)

> Kannst/darfst du deinen Code posten? Das sieht eher nach einem Problem im SPS-Programm aus als im VisionSensor. Vor allem der Teil wie die Ausgänge geschrieben werden ist interessant


Es ist relativ simpel. Ich schreibe am Ende meines "Keyence_IV3_FB"-Bausteins das UDT (welches nach Anleitung angelegt wurde) mit einem DPWR_DAT-Baustein in die Hardwareadresse der Keyence Kamera. Eben über diesen Weg steuere ich auch den Trigger für das Kamerabild an und das funktioniert.


----------



## TP-Inc (3 September 2022)

C_wie_Cäsar schrieb:


> Es ist relativ simpel. Ich schreibe am Ende meines "Keyence_IV3_FB"-Bausteins das UDT (welches nach Anleitung angelegt wurde) mit einem DPWR_DAT-Baustein in die Hardwareadresse der Keyence Kamera. Eben über diesen Weg steuere ich auch den Trigger für das Kamerabild an und das funktioniert.


Ich finds toll dass es funktioniert, würde aber gerne wissen was der Fehler ist. Dieses Verhalten habe ich noch nie erlebt und mache eigentlich alles ohne DPRD_DAT seit TIA… Kannst du den Code samt Bausteinaufruf posten oder per PN schicken?


----------



## C_wie_Cäsar (3 September 2022)

Habe erst wieder am Montag auf den Code Zugriff, ich schick ihn dir dann per PN.


----------



## Oberchefe (5 September 2022)

Sehe ich das richtig, dass der Programmwechsel nicht auf den UDT geschrieben wird? In dem Fall wird er natürlich wieder mit dem Inhalt des UDT überschrieben und durch die geänderte Programmreihenfolge passiert das jetzt nicht mehr. Wenn du per DPWR_DAT schreibst hast du aber das Ding aus dem Prozessabbild herausgenommen?


----------



## TP-Inc (5 September 2022)

Oberchefe schrieb:


> Sehe ich das richtig, dass der Programmwechsel nicht auf den UDT geschrieben wird? In dem Fall wird er natürlich wieder mit dem Inhalt des UDT überschrieben und durch die geänderte Programmreihenfolge passiert das jetzt nicht mehr. Wenn du per DPWR_DAT schreibst hast du aber das Ding aus dem Prozessabbild herausgenommen?


Bei der 1500er gibts kein einstellbares Prozessabbild. War in Wahrheit auch bei der 300er egal ob SFC14/15 aus dem PAE/PAA liest/schreibt. Ich hatte nie Probleme.


----------



## Oberchefe (6 September 2022)

> Bei der 1500er gibts kein einstellbares Prozessabbild.


Man kann sehr wohl bei dem iDevice in der Hardwarekonfiguration einstellen, ob es automatisch aktualisiert werden soll (=OB1) oder mit irgend etwas anderem (OBxxx) oder gar nicht!


----------



## TP-Inc (6 September 2022)

Oberchefe schrieb:


> Man kann sehr wohl bei dem iDevice in der Hardwarekonfiguration einstellen, ob es automatisch aktualisiert werden soll (=OB1) oder mit irgend etwas anderem (OBxxx) oder gar nicht!


Ok. Das kann gut sein, hab ich noch nie verwendet. Aber warum sollte man dann nicht DPRD_DAT verwenden dürfen?


----------



## Blockmove (6 September 2022)

TP-Inc schrieb:


> Bei der 1500er gibts kein einstellbares Prozessabbild. War in Wahrheit auch bei der 300er egal ob SFC14/15 aus dem PAE/PAA liest/schreibt. Ich hatte nie Probleme.


Die 1500 im Prinzip auch einstellbare Prozessabbilder und zwar recht feingranulare.
 Das Schreiben über SFC macht bei 300er durchaus einen Unterschied.
Es ist ein direkter Peripheriezugriff.


----------



## TP-Inc (6 September 2022)

Blockmove schrieb:


> Die 1500 im Prinzip auch einstellbare Prozessabbilder und zwar recht feingranulare.
> Das Schreiben über SFC macht bei 300er durchaus einen Unterschied.
> Es ist ein direkter Peripheriezugriff.


Das mit dem Peripheriezugriff habe ich gelesen. Welcher Unterschied ergibt sich in der Praxis?


----------



## Oberchefe (6 September 2022)

> Aber warum sollte man dann nicht DPRD_DAT verwenden dürfen?


Siehe Hilfe zum DPRW_DAT, du sollst dich entscheiden, entweder dem Prozessabbild zuordnen oder mit DPRW_DAT arbeiten, nicht Beides gleichzeitig.


----------



## Blockmove (6 September 2022)

Peripheriezugriffe erfolgen „sofort“ und nicht erst am Anfang des nächsten OB1-Zugriffs.


----------



## Blockmove (6 September 2022)

Oberchefe schrieb:


> Siehe Hilfe zum DPRW_DAT, du sollst dich entscheiden, entweder dem Prozessabbild zuordnen oder mit DPRW_DAT arbeiten, nicht Beides gleichzeitig.


Zumindest muss man wissen was man tut.
Bei schnellen Datenaustausch kann sowas schon Sinn machen.


----------



## TP-Inc (6 September 2022)

Blockmove schrieb:


> Peripheriezugriffe erfolgen „sofort“ und nicht erst am Anfang des nächsten OB1-Zugriffs.


Das ist mir auch klar. Aber welchen Einfluss hat das? Zykluszeit? Ich lese ja in einem Baustein für ein Feldgerät nur einmal ein, arbeite mit den Daten, schreibe die Ausgänge einmal und das wars. Ob die Ein/Ausgänge am Anfang des OB1 verarbeitet werden oder mittendrinn macht in einem ewigen Loop ja keinen Unterschied (wenn alles nur einmal geschrieben/gelesen wird)


----------



## Blockmove (6 September 2022)

Du kannst mit Peripheriezugriffen mehrmals in einem Zyklus lesen und schreiben.
Beispiel: Du legst Daten an und später im Zyklus setzt du das Übernahme-Signa.


----------



## TP-Inc (6 September 2022)

Alles klar. Hab ich so nie verwendet. Einmal lesen, einmal schreiben. Vielleicht hatte ich deshalb nie Probleme mit SFC14/15 im Prozessabbild.


----------



## Oberchefe (6 September 2022)

so wie ich die Beschreibung am Anfang verstanden habe, werden Signale für die Programmumschaltung auf die Ausgänge geschrieben, wobei die da erst mal noch nicht bei der Kamera landen sondern erst "vorgemerkt" sind für das setzen. Später im Programm kommt er dann mit dem UDT, schreibt per DPWR_DAT direkt auf die Kamera (und überbügelt damit gleichzeitig die zuvor mühsam gesetzten Ausgänge). Am Ende des OB1 werden dann die bereits überbügelten Ausgänge nochmals auf die Kamera geschrieben, bei der Kamera kommt nur der Inhalt des UDT an.


----------



## C_wie_Cäsar (6 September 2022)

So um etwas Licht ins Dunkel zu bringen. Hier meine UDT



über diese Netzwerke lese ich die Prozesswerte ein (Beispielhaft für einen Slot):



über diese Netzwerk schreibe ich die Daten raus:



und dazwischen setzte ich die von mir gewünschten Ausgänge wie z.B. beim Bild Trigger:



Bei der Bild Anforderung klappt das einwandfrei. Im Prinzip also:
1. Prozesswerte einlesen
2. Ausgänge entsprechend vorbereiten
3. Ausgänge in Prozesswerte schreiben


----------



## Oberchefe (6 September 2022)

und jetzt fehlt noch ein Screenshot von der ursprünglichen Programmumschaltung


----------



## C_wie_Cäsar (6 September 2022)

Integer Wert mit einem Move Befehl in die ZU_Kamera UDT (Programm-Nummer) und zusätzlich Trigger für Programm Umschaltung auch wiederum in die ZU_Kamera UDT.

Da dann aber beim Beobachten der Ausgänge der Wert für die  Programm-Nummer immer NULL war, erscheint mir dein Ansatz, dass die Prozesswerte in einem SPS Zyklus mehrmals geschrieben werden, schlüssig. Somit funktionieren die Funktionen bei denen nur eine positive Flanke notwendig sind problemlos aber Werte die dauerhaft geschrieben werden müssen eben nicht.


----------



## Oberchefe (6 September 2022)

also hier sieht es noch so aus, als würde für die Programmumschaltung auf Ausgänge geschrieben:


			https://www.sps-forum.de/attachments/2022-08-27-09_11_51-pr%C3%A4sentation1-powerpoint-png.63147/
		


Wenn aber tatsächlich auf das UDT geschrieben wird, bevor es per DPWR_DAT zur Kamera geschickt wird, muss es unabhängig von der parallelen Prozessabbildaktualisierung funktionieren


----------



## C_wie_Cäsar (6 September 2022)

Ich hab mehrere Schritte versucht. Anfangs war die Umschaltung im FB (natürlich bevor per DPWR_DAT die Daten geschickt werden) über die UDT realisiert. Danach habe ich versucht die Daten direkt auf die Ausgänge zu schreiben. Allerdings im FB. Was natürlich nachträglich betrachtet dämlich war, da im nächsten Schritt mit dem DPWR_DAT Baustein die Ausgänge wieder überbügelt wurden. Nun schreibe ich die Daten direkt an die Ausgänge außerhalb des FBs (also im zyklischen Ablauf danach) und es funktioniert. Nach meiner Meinung können es eigentlich nur zwei Sachen sein:
1 - UDT fehlerhaft und ich schreibe die Daten an die falsche Stelle
2 - Die Prozesswerte werden nach meinem aktivem Schreibvorgang nochmal geschrieben.

Die UDT habe ich aber mehrmals kontrolliert und die dürfte passen.


----------



## TP-Inc (7 September 2022)

Also sind die 3 Netzwerke oben nur die halbe Wahrheit? Du schreibst nach dem FB direkt auf den Ausgang? Also wirklich auf ADxy? Wenn du du nicht nur so geheimnisvolle Teilauschnitte zeigen würdest, hätten wir die Lösung schon….


----------

