S7 Barcodescanner CLV620 mit Beckhoff Modul KL6031

Straubli

Level-1
Beiträge
4
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,
also habe eine CDU 314 2DP im Einsatz, ein OP177B dran und an einem Beckhoff BK3150 ein KL6031 im Einsatz.
das ganze soll jetzt in Betrieb genommen / Programmiert werden.
Es soll ein Sick Barcode Scanner Typ CLV620 ausgewertet werden.

Das Beckhoff Modul scheint elektrisch zu funktionieren, wird wohl auch erkannt, habe es im Harware Manger direkt als ersten Teilnehmer im BK3150 integriert.
Nun versuche ich den Scanner anzusprechen, habe den SFC 14 und den SFC 15 geladen, die HEX Adresse des KL6031 angegeben, allerdings bekomme ich keinerlei Daten, bzw immer die gleichen.
Egal ob ich den Scanstrahl aktiviere ( seperater Ausgang ) oder nicht.

laut Auskunft der fa. sick ist der Scanner richtig parametriert und auch korrekt angeschlossen an dem KL6031.

Falls jemand Ratschläge hat oder sich ( noch besser ) damit auskennt ....... wäre sehr dankbar für Hilfe.

Gruß und danke im voraus
Straubli
 
Es gibt ein (zugegebenermaßen dürftiges) Beispielprogramm von Beckhoff für die KL6031. Woher ich das hatte, kann ich gar nicht mehr sagen, ich habs dann weggehauen und selbst einen Baustein geschrieben. Hast du die Anleitung, die zur KL6031 gehört, zumindest gibt es eine kompilierte Hilfedatei, die funzt bei mir nur, wenn ich sie direkt auf dem Desktop ablege. Die Beckhoff-Klemme zeigt Datenempfang durch Toggeln eines Bits an. Reagiert man darauf nicht, kommt nichts mehr in die SPS.Anhang anzeigen KL6031.awl.txt Die Einbindung dieser Klemme in S7 ist eigentlich nicht wirklich schön, die Funktion der Klemme über das Toggeln auch nicht, aber immerhin, es funzt.

Ich hänge dir mal meinen Baustein an, das Ganze am Besten in einem leeren Beispielprojekt als Quelle importieren und dann übersetzen.

Hier noch der Aufruf des Bausteins:

Aufruf_KL6031.jpg

Damit hättest du zumindest mal einen Start.

PS: das .TXT an der Datei bitte vor dem Import löschen

Anhang anzeigen KL6031.awl.txt

Die ZIP-Datei ist von Beckhoff, keine Ahnung, woher ich die bekommen habe...

PS2: Senden brauchst du wahrscheinlich nicht, wenn du extern triggerst, dann nur empfangen. In diesem Falle tut es vielleicht auch das Beckhoff-Beispiel in der ZIP.
 

Anhänge

  • Kl6031.zip
    311,6 KB · Aufrufe: 70
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Ralle!

Ich habe den Baustein auch in mein Programm eingebunden.
Die ersten Test verliefen auch ohne Probleme. Nun aber kommt bei etwa jedem zweiten Barcode ein Timeout.

Die Ansteuerung verläuft wie folgt:
  1. FB meldet bereit
  2. Barcode wird gescannt und Bit New_Data_Receive wird gesetzt
  3. Daraufhin setze ich das Bit Receive_Start
  4. Der FB setzt das Bit Receive_Start zurück, Bereit = TRUE, busy = FALSE, New_Data_Receive = FALSE, String_vorhanden = TRUE
Im Fehlerfall lautet Punkt 4 wie folgt:
4. Der FB setzt das Bit Receive_Start zurück, Bereit = FALSE, busy = TRUE, New_Data_Receive = FALSE, String_vorhanden = FALSE, Timeout = TRUE

Der Timeout-Wert steht auf 3 Sekunden.

Hast du eine Idee wo mein Fehler liegen könnte?
 
Ich mache das auch so, wenn "New_Data_Receive" True wird, setze ich "Receive_Start".
Timeout kommt, wenn noch Daten erwartet werden, aber die Klemme keine Daten mehr liefert.
Wieviele Zeichen scannt du?
Kannst du mal versuchen, einen kürzeren und einen längeren String zu scannen.
Den Timeout kannst du mal sehr hoch setzen (120 Sekunden) und dann in der Schrittkette (Netzwerk 26) nachsehen,
in welchem Schritt er "steckenbleibt".
Schau auch mal im IDB, ob im receive.Data-Array überhaupt etwas abgelegt wurde.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht liegt da das Problem, die Klemme empfängt immer 22 Zeichen, wenn ich mich nicht irre. Vielleicht gibt es genau bei der Grenze ein Problem, daß der Baustein noch mein, da kommt noch etwas, die Klemme aber nichts mehr hat. Sieh dir in dem Zusammenhang online mal Netzwerk 36 an.
 
So ich konnte nun einige Tests machen.
Die Barcodelänge scheint kein Einfluss zu haben. Ich habe mehrere Test gemacht wo die Länge des Barcodes konstant blieb. Getestete Barcodlängen sind 13, 20 und 22 Zeichen plus je ein CR am Ende welches der Scanner hinzufügt. Bei allen Längen habe ich das Timeoutproblem gehabt. Nach einem Init des FB's trat das Problem nach unterschiedlichen Anzahl an Scannvorgängen auf. Manchmal schon direkt der erste.

In den Netzwerken 31 und 36 scheint es an dem Bit #Rcv_Quitt_Bit zu hängen (siehe Screenshots).
NW5.JPGNW31.JPGNW36.JPG
 
Und kommen trotzdem Daten im IDB an?

Nachtrag: Die größten Probleme hatte ich mit dem Potential der KL, die war da extremst zickig.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
So, ich glaube ich habs gelöst bekommen.

Im Fehlerfall war das Status-Bit Receive-Request durch den Schritt4 schon zurückgesetzt worden, das Control-Bit Receive-Accept blieb aber noch gesetzt (Durch das weiterspringen in Schritt 5 wurde die Anweisung U Receive-Bit = Request-Bit nicht mehr bearbeitet).
Ich habe die Anweisung einfach zusätlich in den Schritt 5 eingefügt und seit dem funktioniert es.
 
Hm, eigenartig, kann mich nicht erinnern, dass das bei mir auch auftrat.
Ist irgendwie nicht ganz so logisch weil du dadurch u.U, zwei Mal toggelst, was für größere Datenpakete schlecht wäre.
Funktioniert das auch, wenn du Datenpakete >22 Byte empfangen willst?

Aber immerhin, für deine Anwendung läuft das nun mal.
 
Zurück
Oben