Teileverfolgung ohne Identifikationssystem

[Marius_100]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag,

ich bin im Moment dabei die Teileverfolgung für eine Produktionslinie zu programmieren. In der Anlage werden Holzdielen befördert, vermessen, bearbeitet und zum Schluss einsortiert. Leider gibt es keine Möglichkeit zur eindeutigen Identifikation der Teile mittels QR-Code oder RFID.

Die Daten der einzelnen Teile müssen in der Steuerung (S7-1500) gespeichert und mitgeführt werden.
Da sich die Anordnung der Teile nicht ändert und diese nur eine Transportrichtung haben, habe ich an den Einsatz von Schieberegistern/ FIFOS gedacht. Im Forum konnte ich dazu auch schon einige hilfreiche Tipps finden.

Nun zu meinen Ansätzen und den Problemstellung:

1) Wenn sich die Teile im Durchlauf befinden, erfasse ich immer mit einer fallenden Flanke einer Lichtschranke oder eines Abstandssensors (Breite, Länge, Dicke), dass ein Teil in einen Abschnitt der Anlage eingefördert wurde. Im gleichen Zuge speichere ich die Position des Förderbandes (und ggf. einen Messwert) und schreibe diese in ein Schieberegister. Passiert das Teil eine weitere Lichtschranke oder eine Messstelle, kopiere ich die Daten aus dem letzten Element des Registers und validiere anhand der letzten Teileposition und der aktuellen Position des Förderbandes, ob Teile entnommen wurden oder nicht. Wurden Teile entnommen, lösche ich die Daten. Stimmt die Position überein, schreibe ich die Daten in ein neues Schieberegister und lösche den Eintrag anschließend aus dem vorherigen Register.
Um einen Teilestau zu erkennen, erfasse ich wie lange die Sensoren belegt sind. Über die Teilelänge und die Fördergeschwindigkeit errechne ich mir die Dauer (+Toleranz) die der Sensor belegt sein darf. Bei Überschreitung der Zeit wir die Anlage gestoppt und die Teile müssen manuell entnommen werden.

2) Nun habe ich dass Problem, dass ich eine Winkelübergabe auf dem Transportweg habe. Die Validierung anhand der Position ist hier leider nicht möglich. Ich habe in dem Fall überlegt, mit Zeitstempeln zu arbeiten. Allerdings sehe ich das problematisch, da im Falle eines Anlagenstopps die Systemzeit weitergezählt wird.

3) In einem Abschnitt befindet sich ein Scanner, der die Bretter optische Beurteilen soll. Das Problem hierbei ist, dass der Scanner mit dem Verlassen des Teil aus aus dem Scannbereich, je nach Maße und Geschwindigkeit der Teile, bis zu über eine Sekunde benötigt die Daten auszuwerten und an die Steuerung zu senden. Hier habe ich überlegt ein zweites Register anzulegen um die Messdaten des Scanners zu speichern. Passieren die Teile eine Lichtschranke, die weit genug hinter dem Scanner liegt, so nehme ich die ältesten Einträge aus dem "Messdaten-Register" und dem "Transport-Register" und kombiniere die Daten. Problematisch hierbei ist, dass ich irgendwie erkennen muss, dass ein Teil vor oder nach der Messung entnommen wurde und ggf. den Messwert zu löschen.

Leider hab ich bisher noch keine Teileverfolgung aufgezogen, außerdem hatte ich auch noch keinen Fall, wo mir die Daten mit so hoher Verzögerung zur Verfügung standen. Daher bin ich über weitere mögliche Ansätze oder Verbessrungsvorschläge sehr dankbar.

 

[PN/DP]

Spätestens wenn man Daten mit den Teilen mitschieben will, braucht man ein richtig robustes Teileübergabe-Programm zwischen Transportabschnitten mit Schrittketten und Handshakes. Da kann man nicht mehr einfach von Lichtschranke zu Lichtschranke auf Stau fahren. Kannst Du Dir vorstellen, welches Datenchaos entsteht, wenn zur Unzeit eine Lichtschranke schaltet (weil vielleicht ein Vogel oder eine Person eine Lichtschranke betätigt)?

Harald

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der Anlage werden Holzdielen befördert, ...

Im gleichen Zuge speichere ich die Position des Förderbandes (und ggf. einen Messwert) und ...

Wenn Du die so abgespeicherte Position des Förderbandes von der aktuellen Position des Bandes subtrahierst, hast Dur die aktuelle Position des Teils entlang der Förderstrecke.

 

[Ralle]

Wenn das Band einen Positionswert ausgibt, dann würde ich auch wie @Heinileini schon schrieb die Teileinfo mit dieser Position verknüpfen. Dort kann dann auch eine Teile-ID genutzt werden, über die man die Scannerdaten (Bei Start des Scanners Teile-ID speichern) dann, wenn sie zur Verfügung stehen, zur richtigen Teileinfo hinzufügen kann. Werden Teile entnommen, merkt man das, weil an der betreffenden Position des Bandes (Fenster) eine LS kein Teil sieht. Zusammenschieben von Teilen ist immer schlecht, das müßte man wirklich detektieren und die Teile dann entnehmen. Oder man gestaltet das Band so, dass ein Zusammenschieben nicht möglich ist, aber das Band wird bei dir sicher schon vorhanden sein oder es geht mech. nicht.

 

[Heinileini]

Zusammenschieben von Teilen ist immer schlecht, das müßte man wirklich detektieren und die Teile dann entnehmen. Oder man gestaltet das Band so, dass ein Zusammenschieben nicht möglich ist, aber das Band wird bei dir sicher schon vorhanden sein oder es geht mech. nicht.

Die Hoffnung, dass es kein Zusammenschieben gibt, hatte ich, weil Marius100 schrieb:

Da sich die Anordnung der Teile nicht ändert und diese nur eine Transportrichtung haben, ...

Die relative Lage der Teile zueinander muss natürlich erhalten bleiben (bzw. ein Verschieben müsste noch nachträglich verhindert werden), damit die Positionen in den "Hochrechnungen" der Daten nachvollziehbar sind.

 

[Marius_100]

Zuviel Werbung?
-> Hier kostenlos registrieren

Spätestens wenn man Daten mit den Teilen mitschieben will, braucht man ein richtig robustes Teileübergabe-Programm zwischen Transportabschnitten mit Schrittketten und Handshakes.

Wie könnte so ein Handshake/ eine robuste Teileübergabe denn Aussehen?
Aktuell lege ich für jeden Transportabschnitt eine Schrittkette an sowie einen Datenbaustein in welchem ich die Registerinhalte speichere.
In jeder Schrittkette lese ich das älteste Datenfach aus dem vorherigen DB und validiere die Daten. Erst dann speichere ich die Daten in den neuen DB und lösche das Datenfach des vorherigen DBs.

Wenn das Band einen Positionswert ausgibt, dann würde ich auch wie @Heinileini schon schrieb die Teileinfo mit dieser Position verknüpfen. Dort kann dann auch eine Teile-ID genutzt werden, über die man die Scannerdaten (Bei Start des Scanners Teile-ID speichern) dann, wenn sie zur Verfügung stehen, zur richtigen Teileinfo hinzufügen kann.

Aktuell sehen die Datenfächer meiner Register/ Arrays so aus, dass ich für jedes Teil die aktuelle Auftragsnummer, eine Teile-ID, die Position + Geometrische und optische speichere. Also die Teileinfos und die Position werden immer zusammen gespeichert.
Die Teile-ID für die Scanner-Daten zu speichern ist eine gute Idee. Dann würde ich zyklisch abfragen ob das Teil gescannt würde und das Datenfach mit der entsprechenden ID suchen. So könnte ich dann auch das zusammenschieben von Daten vermeiden.

Zusammenschieben von Teilen ist immer schlecht, das müsste man wirklich detektieren und die Teile dann entnehmen. Oder man gestaltet das Band so, dass ein Zusammenschieben nicht möglich ist, aber das Band wird bei dir sicher schon vorhanden sein oder es geht mech. nicht.

Das Band ist schon vorhanden. Ein Umgestaltung ist leider nicht mehr möglich. Theoretisch können sich die Teile beispielsweise im Fall eines Bandstopps verschieben. In dem Fall sehe ich auch keine Möglichkeit außer den Abschnitt wieder freizufahren und die Teile zu entnehmen.

 

[Heinileini]

Theoretisch können sich die Teile beispielsweise im Fall eines Bandstopps verschieben. In dem Fall sehe ich auch keine Möglichkeit außer den Abschnitt wieder freizufahren und die Teile zu entnehmen.

Wodurch würden sich die Teile verschieben? Durch ihre MassenTrägheit, wenn sie beim Abbremsen ins Rutschen kommen?
Oder durch nachfolgende Teile, wenn diese nicht auch gestoppt werden?

 

[Marius_100]

Wodurch würden sich die Teile verschieben? Durch ihre MassenTrägheit, wenn sie beim Abbremsen ins Rutschen kommen?
Oder durch nachfolgende Teile, wenn diese nicht auch gestoppt werden?

Vorwiegend durch die Massenträgheit bei einem plötzlichen Stopp oder durch einen Stau. Möchte ich den Transport kontrolliert anhalten würde ich erst alle Transporte sanft abbremsen oder warten bis die restlichen Teile ausgeschleust wurden.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

... oder durch einen Stau.

Wie kann es zu einem Stau kommen? Kann sich ein Teil auf dem Band irgendwo festhaken, so dass es durch das Band nicht weitertransportiert wird?
Das Be- und Ent-schleunigen des Bandes an einer Rampe dürfte auf jeden Fall hilfreich sein, Verschiebungen zu vermeiden.

Dein Stichwort FIFO aus Beitrag #1 trifft die Sache schon recht gut. Die Reihenfolge der Teile auf dem Band ändert sich (normalerweise?) nicht, aber die Anzahl der auf dem Band befindlichen Teile kann sich durchaus im Laufe der Zeit ändern.
Aber vermutlich wirst Du nicht ausschliesslich auf die Daten des ersten und letzten Teils im FIFO zugreifen wollen/müssen, sondern auch auf die Daten weiterer Teile auf dem Band.
So gesehen könnte ein FIFO zu "spezialisiert" für Dein Vorhaben sein. Ein Array of Struct sollte genügen bzw. besser geeignet sein.
Allerdings müsstest Du Dir wohl Gedanken machen, wie Du die "Datensätze" suchen/finden willst.
Die Reihenfolge der Teile auf dem Band in den Daten abzubilden, kann durchaus hilfreich sein, muss es aber nicht unbedingt - je nach Anforderungen.

 

[Marius_100]

Erstmal danke für die Antworten bisher. Ihr habt mir schon einige Denkanstöße gegeben.

Wie kann es zu einem Stau kommen? Kann sich ein Teil auf dem Band irgendwo festhaken, so dass es durch das Band nicht weitertransportiert wird?

Genau. Es ist zwar unwahrscheinlich, aber nicht auszuschließen.

Die Reihenfolge der Teile auf dem Band ändert sich (normalerweise?) nicht, aber die Anzahl der auf dem Band befindlichen Teile kann sich durchaus im Laufe der Zeit ändern.

Die Reihenfolge bleibt erhalten sofern nicht ein Teil während des Transportes händisch entnommen wird. Dies ist aber nicht erwünscht und muss detektiert werden können. Je nach Auftrag, kann sich die Maße der Teile und damit die maximale Anzahl der Teile pro Förderband ändern.

So gesehen könnte ein FIFO zu "spezialisiert" für Dein Vorhaben sein. Ein Array of Struct sollte genügen bzw. besser geeignet sein.
Allerdings müsstest Du Dir wohl Gedanken machen, wie Du die "Datensätze" suchen/finden willst.
Die Reihenfolge der Teile auf dem Band in den Daten abzubilden, kann durchaus hilfreich sein, muss es aber nicht unbedingt - je nach Anforderungen.

Im Prinzip habe ich im Moment einen Datenbaustein, mit einem Array of Struct welchen ich pro Band/ Abschnitt anlege. Über einen wieder verwendbaren FB lese ich einzelne Daten/ Elemente aus dem Array, lösche diese oder ich schreibe/ überschreibe Daten je nach Aufruf des FBs. Die Daten würde ich anhand der Teile-IDs durchsuchen, wenn ich diese überschreiben muss. Ansonsten entnehme ich die Daten der Reihenfolge nach aus dem Array oder füge die der Reihenfolge nach an. Ich erhoffe mir dadurch, dass man die Daten so besser nachvollziehen kann.

 

[Maagic7]

Wenn die Teile auf den Bändern nicht weit verrutschen, dann Ringpuffer. Das ist ziemlich stabil. Ausserdem kann man
dazwischen einzelne Produkte z.B. per Hand rausnehmen, ohne dass das System mit Datenchaos zusammenbricht.
Ich mach das z.B. für die Glasfertigung zur Scheibenverfolgung durch die ganze Anlage über mehrere Transporttische.
Ich gehe da sogar soweit, dass ich einen Zentralen DB für die Datensätze hab. Durch die Anlagenringpuffer wandern dann
nur die Datensatznummern. Dadurch verbraucht man relativ wenig Speicher und hat alle Datensätze an zentraler Stelle.
Man braucht mindestens soviel Datensätze wie Produkte in die Anlage passen. Ich hab eine Scheibendrehanlage (Scheibenmass bis 5,5m), die stellt sich schon mit den Saugtellern auf die Mitte der Scheibe ein, kurz bevor die Scheibe ankommt und muss dann nur noch kurz über Kantensuche kontrollieren ob das wirklich stimmt. Das sieht ziemlich erstaunlich aus. Die Versuche des Kunden druch willkürliches rausnehmen einzelner Scheiben (Simulation von Scheibenbruch) das ausser Tritt zu bringen ist mit großen Augen und Verwunderung gescheitert.


Das geht unter folgenden Voraussetzungen.

1. Jeder Transport muss einen Wegimpulsgeber haben. Das kann ein einfacher Schraubensensor sein. Damit erzeugt man alle Xcm einen Impuls. Das ist der Schreibimpuls für den Ringpuffer. Damit kann man dann je nach Speicherplatz seine Anlage bestimmte Streckenabschnitte unterteilen. Nimmt man z.B. 1cm Impulse, dann benötigt man pro 1m Länge der Anlage 100 Einträge.

2. Bei mehreren Förderstrecken benötigt man einen Ringpuffer für jede Förderstrecke (angepasst auf die Förderlänge und Impulsauflösung)

3. Die Übergabe unter den Förderstrecken erfolgt folgendermaßen: Jede Förderstrecke bekommt einen festen Datensatz für Dateneingang und Datenausgang. Der Dateneingangspuffer wird mit jedem Schreibimpuls als neuer Datensatz in den Ringpuffer übertragen.
Der Datenausgangspuffer wird nach Förderstreckenlänge aus dem Ringpuffer bei jedem Impuls ausgelesen.
Der Ausgangspuffer wird auf den Eingangspuffer des nächsten Abschnitts kopiert (das kann man mit Lichtschranken verbinden)

Damit erreicht man eine komplette Abbildung der Fördersituation nach Wegraster.
Bei Ringpuffern muss man nichts schieben. Die Datensätze werden im Kreis immer wieder überschrieben (man braucht nur mehr Datensätze als seine Anlage lang ist).

Das wichtigste ist der Ringpuffer Zeiger. Dieser läuft z.B. bei einem 256 Einträge Puffer immer von 0..256-0..256
wegen der korrekten Überlaufberechungen ist es sinnvoll volle 2er Potenzen als Anzahl der Einträge zu verwenden. 0..255, 511, 1023

Wenn man z.B. bei Zeiger 100 steht, 1cm Auflösung hat, dann stehen 50 Einträge weiter zurück im Puffer die Daten des Produktes welches bereits 50cm weiter transportiert wurde. Ist ein Produkt z.B. 10 cm lang, dann taucht es im Ringpuffer 10x hintereinander auf! D.h. an den Position liegt dann Produkt mit IDxy

Der Punkt wann das nicht mehr funktioniert ist, wenn Produkte auf den Förderstrecken manuell verschoben werden (Schlupf). Denn dann passt die virtuelle Position im Ringpuffer nicht mehr zum tatsächlichen Produkt.
Einzelne Produkte dazwischen rausnehmen ist hingegen kein Problem. Wenn man beim passieren von Sensoren ausliest, bekommt man sogar mit welche Position fehlt!

Das ganze ist nicht trivial und erfordert eine Menge Programmierarbeit und noch mehr Testarbeit. Wichtig ist, dass man sich die Daten auf der Visu anzeigt, so dass man bei der Inbetriebnahme sofort die Fehler sieht.

 

[IoT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn die Teile auf den Bändern nicht weit verrutschen, dann Ringpuffer. Das ist ziemlich stabil. Ausserdem kann man
dazwischen einzelne Produkte z.B. per Hand rausnehmen, ohne dass das System mit Datenchaos zusammenbricht.
Ich mach das z.B. für die Glasfertigung zur Scheibenverfolgung durch die ganze Anlage über mehrere Transporttische.
Ich gehe da sogar soweit, dass ich einen Zentralen DB für die Datensätze hab. Durch die Anlagenringpuffer wandern dann
nur die Datensatznummern. Dadurch verbraucht man relativ wenig Speicher und hat alle Datensätze an zentraler Stelle.
Man braucht mindestens soviel Datensätze wie Produkte in die Anlage passen. Ich hab eine Scheibendrehanlage (Scheibenmass bis 5,5m), die stellt sich schon mit den Saugtellern auf die Mitte der Scheibe ein, kurz bevor die Scheibe ankommt und muss dann nur noch kurz über Kantensuche kontrollieren ob das wirklich stimmt. Das sieht ziemlich erstaunlich aus. Die Versuche des Kunden druch willkürliches rausnehmen einzelner Scheiben (Simulation von Scheibenbruch) das ausser Tritt zu bringen ist mit großen Augen und Verwunderung gescheitert.


Das geht unter folgenden Voraussetzungen.

1. Jeder Transport muss einen Wegimpulsgeber haben. Das kann ein einfacher Schraubensensor sein. Damit erzeugt man alle Xcm einen Impuls. Das ist der Schreibimpuls für den Ringpuffer. Damit kann man dann je nach Speicherplatz seine Anlage bestimmte Streckenabschnitte unterteilen. Nimmt man z.B. 1cm Impulse, dann benötigt man pro 1m Länge der Anlage 100 Einträge.

2. Bei mehreren Förderstrecken benötigt man einen Ringpuffer für jede Förderstrecke (angepasst auf die Förderlänge und Impulsauflösung)

3. Die Übergabe unter den Förderstrecken erfolgt folgendermaßen: Jede Förderstrecke bekommt einen festen Datensatz für Dateneingang und Datenausgang. Der Dateneingangspuffer wird mit jedem Schreibimpuls als neuer Datensatz in den Ringpuffer übertragen.
Der Datenausgangspuffer wird nach Förderstreckenlänge aus dem Ringpuffer bei jedem Impuls ausgelesen.
Der Ausgangspuffer wird auf den Eingangspuffer des nächsten Abschnitts kopiert (das kann man mit Lichtschranken verbinden)

Damit erreicht man eine komplette Abbildung der Fördersituation nach Wegraster.
Bei Ringpuffern muss man nichts schieben. Die Datensätze werden im Kreis immer wieder überschrieben (man braucht nur mehr Datensätze als seine Anlage lang ist).

Das wichtigste ist der Ringpuffer Zeiger. Dieser läuft z.B. bei einem 256 Einträge Puffer immer von 0..256-0..256
wegen der korrekten Überlaufberechungen ist es sinnvoll volle 2er Potenzen als Anzahl der Einträge zu verwenden. 0..255, 511, 1023

Wenn man z.B. bei Zeiger 100 steht, 1cm Auflösung hat, dann stehen 50 Einträge weiter zurück im Puffer die Daten des Produktes welches bereits 50cm weiter transportiert wurde. Ist ein Produkt z.B. 10 cm lang, dann taucht es im Ringpuffer 10x hintereinander auf! D.h. an den Position liegt dann Produkt mit IDxy

Der Punkt wann das nicht mehr funktioniert ist, wenn Produkte auf den Förderstrecken manuell verschoben werden (Schlupf). Denn dann passt die virtuelle Position im Ringpuffer nicht mehr zum tatsächlichen Produkt.
Einzelne Produkte dazwischen rausnehmen ist hingegen kein Problem. Wenn man beim passieren von Sensoren ausliest, bekommt man sogar mit welche Position fehlt!

Das ganze ist nicht trivial und erfordert eine Menge Programmierarbeit und noch mehr Testarbeit. Wichtig ist, dass man sich die Daten auf der Visu anzeigt, so dass man bei der Inbetriebnahme sofort die Fehler sieht.

Genau so arbeiten viele Fördertechnik-SPS-Programme! Wirklich gut, so kann man Tracking sicher gestalten… (und lässt sich auch gut in Sub-FCs und FBs aufteilen).

Wie schon gesagt, der Schlüssel liegt zudem in einem echten Wegsignal (Inkrementalgeber, INI am Kettenrad, etc.) welches man für das Weiterschieben im FIFO nutzen kann. So kann man sein Produkt am Ende des jeweiligen Abschnitts sauber eintragen / austragen aus dem „quasi FIFO“ und kann somit auch fehlende Teile rausschmeißen.

Viel Erfolg!