Bekämpfung flackernder Lichtschranken

iga-graz

Level-1
Beiträge
46
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
ich habe folgendes Problem und wollte eure Meinung dazu lesen:
:confused:
Ich habe ein Teilstück Fördertechnik das aus einzelnen Bandelementen besteht (insg. 13) dort sollen Kleidungsstücke "aufgetaktet" werden. Also die Produkte werden nacheinander aufgestaut. Auf jedem Element befindet sich eine Sick Laserlichtschranke als Stopposition vorne. Jetzt hab ich das Problem, wenn z.b. ein sehr dünnes Produkt vorbeifährt, dass ich dieses zwar an der vorderen Kante erwische, aber beim wegfahren, der Laserstrahl entweder knapp über dem Produkt drüber streift, und/oder durch die Verpackung reflektiert wird.
:confused:
Jetzt wollte ich eine "Entkoppelung" meiner physischen Eingänge und den in der Software benutzten Eingänge erreichen.

Also beispielsweise
das Produkt kommt zu LS und wird erkannt, wenn das Produkt zum nächsten Element weiterfährt wird der Eingang quasi gesperrt (also künstlich für eine best. Zeitdauer auf true gehalten).
Erst nach der abgel. Zeit wird der Eingang wieder eingelesen und dessen Status benutzt.

Code:
u e_stop_vorne_element1
s v_e_stop_vorne_element1 // virtueller eingang

u v_e_stop_vorne_element1 
u a_vorwärts_element1
l s5t#750ms
si t1

u t1
r v_e_stop_vorne_element1

Hat jemand von euch vielleicht mit ähnlichen Problemen zu kämpfen, oder vielleicht andere Lösungsvorschläge. Die extrem genaue Positionierung der LS ist leider auch nicht unproblematisch, da das Band, wenn des startet, sich leicht erheben kann und mir somit auch eine falsche Belegung widergeben könnte. Ist leider auch schon passiert.

Da ich auf diese LS positioniere brauche ich die Belegung 100%ig.

Vielen Dank im voraus. bg chris
 
Die Bedingung, die zu formulieren wäre, ist die, dass nach einem Stopp, der nächste Stopp nicht vor Ablauf einer bestimmten Zeit kommen kann. Da die Geschwindigkeit des Bandes bekannt ist, sollte das kein Problem sein.


Zustand 1)
Warten auf Stopp-Signal

Zustand 2)
Stoppen

Zustand 3)
Anlauf und Timer starten

Zustand 4)
Warten das Timer auf True geht

Zustand 5)
Gehe zu Zustand 1)
 
Ja, entspricht deinem code!
Aber wie wäre es denn, wenn du den Eingang erst Frei gibst, wenn das Fördergut bei der nächsten Lichtschranke eingetroffen ist?


Grüße
 
Hi, jackjones

danke für deinen Ansatz, er gefällt mir gut, nur habe ich noch das Problem, dass ich mit meiner derzeitigen SW die negative Flanke des Eingangs mitbekommen muss, um zu wissen wann das Produkt übergeben wurde, und um den Timeout zu stoppen. Und das möchte ich nicht ändern.

Wenn ein 2. Produkt gleich hinter dem 1. kommt, dann würde ich nie mehr eine neg. Flanke des LS mitbekommen.

bg chris
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also wir machen das so:
Erst wenn das Fördergut auf dem nächsten Segment angekommen ist, bekommt das Segment was nun nach vorne Fördern möchte die Freigabe. usw...

Ich denke du musst mal ein wenig was von deinem Code posten. Wartest du nicht bis das Fördergut ein Segment weiter ist, lässt du das vorgesetzte Segment direkt in das noch nicht frei gewordene einfördern?

Wir nutzen für unsere Förderer auch vorgefertigte Bausteine. Mit denen kann man einiges parametrieren wie z.b. die Kaskade, Lichtschranke pos. oder neg. Flanke, verzögerung etc... bei interesse kann ich dir mal ein Beispiel schicken.

Ich denke es wäre nicht "sauber" die Eingänge auf Virtuelle Eingänge zu schieben. Vieleicht sollest du die ganze Struktur noch mal überdenken. Bei 13 Segmenten ist das doch relativ schnell getan.
 
Zuletzt bearbeitet:
hi jackjones, code posten wird etwas schwierig.

also ich hab das so gelöst:
ich habe die einzelnen Module als Multiinstanzen in einem Aufruf FB ausgeführt. Die Module untereinander arbeiten mit einem Handshake, womit das nächste Modul das vorige aktiviert usw. Soweit so gut.

Ich habe jetzt noch die zusätzliche Anforderung, dass, wenn die Produkte auf den Modulen hintereinander aufgestaut sind, diese "gestauten" Module dann gleichzeitig aktiviert werden müssen (damit wir auf Leistung kommen). Wir nennen das einen Blockabzug. Die restlichen "leeren" Module müssen sich aber nach wie vor über den Handshake unterhalten und befüllt werden, bis sie auch den "aufgestauten" Status bekommen.

Das Problem an deinem Ansatz ist, das bei mir der User in die Linie eingreifen kann. Also er könnte theoretisch ja ein Produkt von einem Modul entfernen oder es während der Übergabe wegnehmen. Diese Fälle müsste ich halt dann auch noch gesichert mitbekommen.
Möglich wäre es über einen Timeout abzufragen, ob das Produkt schon angekommen ist.

Da meine SW ja grundsätzlich funktioniert, möchte ich an diesem Konzept eher nichts mehr angreifen.

Vielleicht kannst du mir wirklich ein Beispiel von dematic geben, wie ihr diese Problematik in den Griff bekommt.

vielen Dank chris

ad drfunfrock: bin auch deiner Meinung, dass das Codieren immer das Letzte ist.:s1:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
puhh.. das sind ja doch etwas "anspruchsvollere" Aufgaben.

In diesem Fall, da dein Programm ja auch schon steht, würde ich einfach mit einer Verzögerung arbeiten. Du weisst ja in etwa wie Groß die Lücken sind, und wie schnell das Band sich bewegt. Da solltest du dann mit deinem Timer arbeiten.
Beispiel suche ich später von uns mal raus. Allerdings werden bei uns auch immer Datensätze zur jeweiligen Ladeeinheit mit geschoben. Ist noch etwas anders.
 
hallo jackjones, du hast Recht, das ganze Projekt ist für die eigentlich einfache Aufgabe (Produkt von A nach B) schon rel. komplex geworden. Aber da ich Auftragsdaten mitziehen muss, und diese bei definierten Stati übergebe, kann ich nicht so einfach weitertakten. Danke auf jedenfalls für deine Vorschläge. bg chris
 
Zurück
Oben