Produktverfolgung / Robustheit

arcis

Level-1
Beiträge
129
Reaktionspunkte
9
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt folgendes Problem:

Abgebildet werden soll eine Transportstrecke mit Verarbeitungseinheit. Am Eingang der Strecke gibt es einen Trackingsensor, der das Stückgut meldet, das in die Strecke einfährt. Am Ausgang gibt es einen Trackingsensor, der meldet, wenn das Stückgut die Strecke wieder verlässt. Die Verarbeitungseinheit auf der Strecke weisst jedem bearbeiteten Stückgut ein Ergebnis zu. Das Ergebnis wird am Ausgangssensor an nachfolgende Anlagenteile weitergereicht. Die Transportgeschwindigkeit der Strecke ist bekannt und konstant.

Das Stückgut kann unterschiedlich gross sein und kann unterschiedliche Abstände haben. Es kann sich also "beliebig" viel Stückgut vor und nach der Verarbeitungseinheit befinden.

Die Implementierung schaut jetzt so aus:

Es wurde eine Stückgut-Queue (FIFO) realisiert. Die Datenstruktur ist ein Datenbaustein mit z.B 10 UDT`s mit Stückgutdaten als Einträgen. Mit dem Eingangssensor wird ein neuer Eintrag in die Queue eingetragen. Der älteste Eintrag wandert mit jedem neuen Eintrag um einen Platz weiter (Shift). Das Ergebnis der Verarbeitungseinheit wird dem ältesten Eintrag, der noch kein Ergebnis hat, zugewiesen. Am Ausgang wird jeweils der älteste Eintrag mit einem Ergebnis ausgewertet und aus der Queue gelöscht.

Prinzipiell nichts dramatisches.

Die Frage und das Problem ist jetzt aber:

Wie kann gewährleistet werden, dass diese Datenstruktur mit dem realen Zustand auf der Transportstrecke übereinstimmt? Vorstellbar wäre z.B., dass ein Operator aus Unwissenheit ein Teil von der Transportstrecke nimmt und somit die Zuordnung der Verarbeitungsergebnisse am Ausgangssensor nicht mehr stimmt. In so einem Fall sollte auf jeden Fall ein Alarm gesetzt werden.

Bis jetzt bin ich noch am Grübeln, ob sowas überhaupt möglich ist.
 
Zuletzt bearbeitet:
Wenn man eingreifen kannst, hast Du keine Chance das sicherzustellen.

Es sei den du hast an jeder Bearbeitungssstation einen Sensor, der das zuordnen kann.

Was meinst Du mit Trackingsensor einen Rfid oder nur eine Lichtschranke oder was das für eine Erkennung ?
 
Zuletzt bearbeitet:
+

Theoretisch könnte man sich überlegen, zu den Produktdaten in der Queue noch einen TimeStamp t1 hinzuzufügen. Dieser TimeStamp wird gesetzt, wenn das Produkt in Queue eingefügt wird. Wenn der älteste Eintrag in der Queue am Ausgangssensor aus der Queue entfernt wird, dann muss die Zeit t2 zu diesem Zeitpunkt um t=Sensorabstand/Transportgeschwindigkeit grösser sein. Wenn jetzt ein Produkt entfernt oder verschoben wurde, stimmen am Ausgang die erwarteten Zeiten mit den Zeiten im ältesten Eintrag in der Queue nicht mehr überein.

Wenn das Transportband stehen bleibt, muss diese Stillstandszeit gemessen werden und beim Wiederanlauf auf alle existierenden Timestamps in der Queue addiert werden.

Jetzt muss ich mal schauen, ob es bei der CPU313C eine Möglichkeit gibt, die Systemzeit in ms-Auflösung auszulesen.
 
In deinem Fall würde ich Ein- und Auslaufkontrolle dazu sagen.
Ein Trackingsystem beinhaltet für mich den Einsatz einer Identifikation sei es Rfid, Barcode oder ähnliches.
Bei nur zwei Sensoren für Einlauf / Auslauf gibt es keinen 100% Schutz.


Hab gerade ein ähnliches problem: Ich lege NIO-Bauteile auf ein Band, die werden im Schieberegister gespeichert, am Ende vom Band ist wieder ein Sensor, wenn der ein Teil erkennt wird ein Etikett gedruckt. Funktioniert eigentlich wunderbar... aber da sind noch Werker im Einsatz.
Die nehmen dann z.B. das Teil vom Band bevor es in die Lichtschranke fährt usw.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

ich glaube arcis ist auf dem richtigem Weg. Über die Zeit ist es vielleicht etwas ungenau, wegen Anlauf- und Bremsrampen. Wie wäre es mit nem Dreh-Encoder oder sowas an der Strecke. Du wüsstest dann bei welcher Position das Teil ankommen muss...

Torsten
 
+

Wie wäre es mit nem Dreh-Encoder oder sowas an der Strecke.
Wer soll das bezahlen,
Wer hat das bestellt,
Wer hat so viel Pinke-pinke,
Wer hat so viel Geld?

Das ist das eigentliche Problem. Seit einiger Zeit schon.

Natürlich muss man da mit einem einstellbaren Fangbereich arbeiten. Wenn die Differenz der Zeiten kleiner als dieser Fangbereich ist, dann handelt es sich wohl um das richtige Produkt.
 
Man könnte auch eine Art Bit-FIFO bauen, wo z.B. alle 10 cm Maschinen-Vorschub ein bit weitergeschoben wird. Ist zum Schiebe-Zeitpunkt der Eingangs-INI belegt, so wandert eine "1" in das FIFO, sonst eine "0". Damit ließe sich die Position des Werkstücks auf einfache Weise mitverfolgen (sogar ohne Inkr.Geber wenn Vorschub annähernd konstant ist oder der Vorschub-Sollwert den FIFO-Takt bestimmt)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man könnte auch eine Art Bit-FIFO bauen, wo z.B. alle 10 cm Maschinen-Vorschub ein bit weitergeschoben wird. Ist zum Schiebe-Zeitpunkt der Eingangs-INI belegt, so wandert eine "1" in das FIFO, sonst eine "0". Damit ließe sich die Position des Werkstücks auf einfache Weise mitverfolgen (sogar ohne Inkr.Geber wenn Vorschub annähernd konstant ist oder der Vorschub-Sollwert den FIFO-Takt bestimmt)

und dann verschiebt ein Spassvogel - ggf. bei ausgeschalteter Anlage - ein
Packet - GUTE NACHT. Bei solchen Applikationen ist der Programmierer
der Ar... :ROFLMAO: Da hilift nur RFID, 2D-Matrixcode oder Stichcode!
 
Na na na na ...

Ich habe etwas ähnliches sogar schon zum Absteuern von Aggregaten gesehen - nennt sich da dann Streckensteuerung - funktionierte wunderbar ...

Wenn ich eine Maschine par-tout durcheinanderbringen will, dann gibt es dafür IMMER eine Möglichkeit. Verschieben von Werkstücken (oder dazulegen) kann ich so natürlich nicht abfangen, aber darauf reagieren könnte ich durch einen Gegencheck mit dem Ausgangs-INI schon :
Ist das erwartete Werkstück mit der erwarteten Länge jetzt am Ausgang - wenn Nein dann wenigsten Meldung an den Bediener

Gruß
LL
 
+

Wenn ich eine Maschine par-tout durcheinanderbringen will, dann gibt es dafür IMMER eine Möglichkeit.
1. Das ist der harmlose Fall.

Du weisst, dass Du die Maschine durcheinander bringst, dass der Hardware- und Softwarezustand inkonsistent sind, die Maschine also irgendwelchen Mist macht.

2. Der nicht harmlose Fall.

Der Operator entnimmt von der Transportstrecke, wie auch immer, ein Teil und denkt sich nichts Böses dabei. Die Maschine läuft weiter, schaut ganz normal aus, dabei stimmen aber am Ausgang die Produktdaten wegen falscher Zuordnung nicht mehr und keiner merkts. Unser Kunde schickt also irgendwelchen unbrauchbaren Schrott an seine Kunden und hat umgehend Riesenärger am Hals. Hatten wir alles schon. Mit Schadensersatzforderungen und bla-bla-bla-tra-la-la.

Deswegen muss in diesen Anlagenteil auf alle Fälle ein Plausibilitätscheck in die Produktverfolgung.

Die Systemzeit kann übrigens mit dem SFC 64 in ms Auflösung ausgelesen werden. Anscheinend gab es da in der Vergangenheit Probleme mit sporadischen Fehlern. Mal schauen, ob das in einer CPU313C von 2008 noch relevant ist.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
... was spricht in diesem Fall dann dagegen, den Plausibilitäts-Check auf die von mir vorgeschlagenene Art und Weise zu machen ...? Du könntest so auf einefache Weise gegenchecken, ob das erwartete Werkstück an der erwarteten Position in der Förderstrecke vorhanden ist. Ist hier eine (zu große) Abweichung vorhanden, dann kann man entsprechend reagieren :
- Bediener-Entscheidung
- Anlage anhalten und Fehler melden
- fragliche Teile ausschleusen
- oder was auch immer

Das würde auch für den Fall gelten, wo ein Teil angefahren kommt, wo keins sein darf. Mein Motto wäre da : "lieber 10 gute Teile wegschmeissen als ein fragwürdiges Teil zum Kunden durchzulassen ..."

Gruß
LL
 
+

... was spricht in diesem Fall dann dagegen, den Plausibilitäts-Check auf die von mir vorgeschlagenene Art und Weise zu machen ...?
Man muss konkurrenzfähig bleiben (auch kostenmässig) und deswegen gibt es

1. auf dieser Transportstrecke KEINEN Encoder mit entsprechender SPS-Hardware

und

2. genau ZWEI optische Sensoren. Einen am Eingang der Transportstrecke und den anderen am Ausgang.

Eine Synchronisation zwischen Hardware und Softwarezustand kann nur an diesen beiden Sensoren stattfinden. Dazwischen bewegen sich die Teile mit konstanter und bekannter Geschwindigkeit. Die Queue und die Art der Zuweisung des Verarbeitungsergebnisses (der älteste Eintrag in der Queue ohne Ergebnis bekommt das aktuelle vorliegende Ergebnis) sorgen dafür, dass mich die eigentliche Position des Stückguts auf der Strecke nicht zu interessieren braucht. Es muss also nicht künstlich eine Art von Pseudoproduktverfolgung innerhalb der Transportstrecke gemacht werden. Es muss lediglich dafür gesorgt werden, dass die Front der Queue (der älteste Eintrag) mit dem jeweils aktuellen Teil am Ausgangssensor übereinstimmt. Das kann mit dem von mir beschriebenen Timestampverfahren gewährleistet werden.
 
OK, OK, ich habe verstanden ...
Du möchtest einen Ansatz, der etwas an "deinem" System verbessert ohne gleichzeitig irgend etwas an der Hardware oder an der Software zu verändern.
Deine Begründung dazu :
- Hardware-Änderungen sind zu teuer
- Software-Änderungen sind nicht nötig.
Habe ich das so in etwa richtig zusammengefasst ?
Wenn ja, dann verstehe ich den Sinn dieses Beitrages nicht ...
Trotzdem ein letzter Vorschlag :
Lass die Anlage einfach ausgeschaltet ... oder wenn sie unbedingt eingeschaltet sein muss ... benutze sie nicht.
Vielleicht hilft dir dann dieser Vorschlag weiter ...

Gruß
LL

Never change a runing System ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hi arcis!

also wenn da keine schadensersatzforderungen mehr reinkommen sollen, muss man auch dementsprechende hardware einbaun, damit man jedes stück definitiv zuordnen kann. hierzu verwendet man in der regel Strichcodepickerl, oder RFID implantate oder andere gelaserte codes.
das ist eingentlich vorraussetzung eines trackingsystems.

das was du da vorhast ist kein trackingsystem.
das ist nur eine "prüfe ob gleich" routine die max. eine 50%ige erkennungssicherheit liefert.

du hast geschrieben dass du zwei sensoren hast (am anfang und am ende der station) und dass du eine konstante förderbandgeschwindigkeit hast bei verschiedenen produktlängen.

du kannst deine produkte mit den sensoren "abmessen" wenn du herausgefunden hast, wie viel zentimeter dein förderband pro sekunde macht. diese angaben schiebst du fortlaufend und indexiert in einen DB(FIFO). ist das produkt am 2. sensor wird auch dort die länge gemessen und mit dem wert im DB verglichen. ist es gleich lang ist es "höchstwahrscheinlich" das selbe produkt. ist es ungleich lang, vergleichst du es mit einem direkt vorhergehenden und ein nachkommenden wert im DB.
stimmt das mit einem überein, wurde ein produkt vor oder nach dessen entfernt (=alarm oder was auch immer), stimmt es mit keinem überein wurde das produkt selber enfernt....

nur so eine überlegung


grüsse
 
@Funkdoc:

... Es muss also nicht künstlich eine Art von Pseudoproduktverfolgung innerhalb der Transportstrecke gemacht werden. Es muss lediglich dafür gesorgt werden, dass die Front der Queue (der älteste Eintrag) mit dem jeweils aktuellen Teil am Ausgangssensor übereinstimmt. Das kann mit dem von mir beschriebenen Timestampverfahren gewährleistet werden.

Nicht an der Software ändern ...!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
achso naja dann viel spass, wenn sich hier die leute schon selbst ihre fragen beantworten.

grüsse

Das ist ja nichts Schlechtes, man hat halt eine Bestätigung der eigenen Vorgehensweise :ROFLMAO: . Aber den Larry muß man erstmal dazu bekommen leicht säuerlich zu reagieren, alle Achtung arcis :p .
 
+

du kannst deine produkte mit den sensoren "abmessen" wenn du herausgefunden hast, wie viel zentimeter dein förderband pro sekunde macht. diese angaben schiebst du fortlaufend und indexiert in einen DB(FIFO). ist das produkt am 2. sensor wird auch dort die länge gemessen und mit dem wert im DB verglichen. ist es gleich lang ist es "höchstwahrscheinlich" das selbe produkt. ist es ungleich lang, vergleichst du es mit einem direkt vorhergehenden und ein nachkommenden wert im DB.
stimmt das mit einem überein, wurde ein produkt vor oder nach dessen entfernt (=alarm oder was auch immer), stimmt es mit keinem überein wurde das produkt selber enfernt....
Das ist im Wesentlichen das, was ich mir überlegt und was ich hier zur Diskussion gestellt habe. Ich halte das vorgestellte Konzept mit minimalem Hardware- und mäßigem Softwareaufwand für realisierbar und ausreichend robust, um auch auf Fehlbedienungen reagieren zu können. Sinn der Übung für mich war, das Konzept auf Unstimmigkeiten oder sonstige Fallstricke abzuklopfen. Für die vielen Anregungen bedanke ich mich. Sollte ich irgendjemanden zu nahe getreten sein, möchte ich mich dafür entschuldigen.
 
Ist ja schön, dass dir der Beitrag von Funkdoc besser gefallen hat. Er stellt aber im Sinn nichts anderes als mein Vorschlag dar. Wichtig zu beachten ist aber auf jeden Fall :
Es muss etwas umprogrammiert werden ...!
Ich hoffe, das ist dir klar ...

Eigentlich macht es mit Spass, dem Einen oder Anderen weiterzuhelfen, aber solche komischen Kommentare wie der von dir :
Es muss also nicht künstlich eine Art von Pseudoproduktverfolgung innerhalb der Transportstrecke gemacht werden. Es muss lediglich dafür gesorgt werden, dass die Front der Queue (der älteste Eintrag) mit dem jeweils aktuellen Teil am Ausgangssensor übereinstimmt. Das kann mit dem von mir beschriebenen Timestampverfahren gewährleistet werden.
... und auch der Rest des genannten Beitrags können es einem dann schon mal vermiesen ...
 
Zurück
Oben