Tipps für sinnvollen Programmaufbau Sortieranlage

[ddave]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen,

Ich baue derzeit eine Anlage zur Sortierung von Paketen.
Kurz zum Aufbau der Anlage:
Ich habe ein "Regalbediengerät", bestehend aus einer senkrechten Linearachse, auf dem die Pakete hoch und runter gefahren werden können und in ein entsprechendes Regalfach einsortiert werden können.
Dieses Regelbediengerät hat eine Ladeposition, an der das Paket von einem Pusher von einem Förderband auf fahrbare Ebene des Regelbediengeräts geschoben wird.

Ziel ist es dass ankommende Pakete bei Bedarf vereinzelt werden, dann zur Pusher-Station gefahren werden, während dem verfahren zum Pusher der auf dem Paket angebrachte Barcode gelesen wird, anhand des Barcodes wird entschieden ob das Paket in das Regal eingelagert werden soll, oder ob es durch die Anlage durchfahren soll zur nächsten Station.

Ich hoffe ich habe in der kurzen Beschreibung alles wichtige erwähnt, so dass ihr das ganze verstehen könnt, sonst einfach fragen

Kurz zu meinem Hintergrund:
Ich habe Elektrotechnik studiert, und im Studium auch mit Automatisierungstechnik (Codesys) zutun gehabt.
Haben damals z.B. eine kleine Modell-Taktstraße automatisiert.
Allerdings war das meiner Meinung nach immer etwas rudimentär, was wir programmiert haben hat schon funktioniert, allerdings würde ich sagen dass das Meilenweit von einer Steuerung entfernt war die man an einen Kunden ausliefern könnte. Fehler und Störungen wurden eher rudimentär abgefangen ...
Wobei genau dieses Fehlerhandling eigentlich das ist was mich wie man das richtig macht.
Ich möchte nicht dass ich bei der kleinsten Störung die Anlage leer fahren muss, komplett zurücksetzen usw ..., das haben wir leider nicht behandelt, das eigentliche Programmieren ist ja das einfachste würde ich behaupten ...

Meine eigentliche Kompetenz ist aber die Entwicklung von Embedded Soft- und Hardware, programmiere viel in C und C#, daher ist das programmieren auf der SPS in ST z.B. doch eine kleine Umstellung für mich


Ich benötige gerade Hilfe beim überlegen wie denn die Programmstruktur aussehen soll, bzw. am interessantes fände ich eigentlich wenn ich mir irgendwo die Programmierung echter Automatisierungsprojekte ansehen könnte, allerdings suche ich schon echt einige Zeit, finde aber praktisch nichts (ist ja auch logisch, wer veröffentlicht schon sein geistiges Eigentum ...).

Die Umsetzung erfolgt übrigens mit einer WAGO PFC100, entsprechende erfolgt die Programmierung im e!Cockpit (was ja quasi Codesys ist ...)

Ich habe bisher vor den Programmablauf ca. so zu gestalten:
Die Anlage besteht für mich aus 3 Blöcken:
- Förderband
- Pusher
- Regalbediengerät (ich nenne das im folgenden einfach mal RBG zur Vereinfachung)

Nun würde ich für jedes Element einen FB anlegen, und die einzelnen FBs miteinander über entsprechende Variablen sprechen lassen.

Ein Programmablauf sieht dabei für mich so aus:
- Paket am Förderband verfügbar
- prüfen ob Pusher eingefahren, wenn ja dann Transport zur Pushposition starten
- Barcode des Pakets lesen und prüfen ob das Paket einsortiert werden muss, falls nein Paket bis zum Ende des Förderbands weiter fahren
- wenn Paket sortiert werden muss und an Pushposition angekommen, prüfen ob RBG bereit zur Aufnahme des Pakets (muss an richtiger Position stehen, und der Platz auf dem RBG frei sein), falls nicht Anforderung an RBG schicken
- wenn RBG bereit ist, Pusher starten, wenn Pusher wieder in der eingefahrenen Endlage angekommen ist, den Sortiervorgang des RBGs starten
- gleichzeitig sobald Pusher in eingefahrener Endlage angekommen ist kann bereits das nächste Paket zum Pusher transportiert werden falls am Eingang schon neue Pakete bereit liegen


Das klingt jetzt wenn ich das durchlese garnicht mal sooo schwierig, allerdings fehlt dabei ja noch die ganze Überwachung auf Störungen usw.
Und wie setze ich die Kommunikation zwischen den 3 FBs um?
Ich hätte gesagt für den Triggereingang eines FBs eine Flankenerkunng auf die steigende Flanke zu nehmen.
Jeder block bekommt einen Error Ausgang, die Error-Ausgänge der 3 Blöcke dann verodern und einen stop Eingang jedes FBs geben.
Wie setze ich sinnvollerweise einen Reset bei Fehlern um?

Für mich ist nicht die eigentliche Programmierung das Problem, sondern die Umsetzung des großen Ganzen so hin zu bekommen dass die Anlage möglichst robust funktioniert, und der Bediener sich nicht täglich darüber aufregt

Gibt es irgendwelche Literatur wo so "best practice" Lösungen oder so beschrieben sind?
Die Aufgabenstellung die ich habe ist ja eigentlich ein alltägliches Problem in der Automatisierungstechnik würde ich behaupten.


Beste Grüße
David

 

[dingo]

Das Buch "Speicherprogrammierbare Steuerungen für die Fabrik- & Prozessautomation" von Prof.Dr. Matthias Seitz
finde ich persönlich sehr Gut:

https://www.seitz.et.hs-mannheim.de/sps-lern-und-uebungsseite.html

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich das hier lese, dann muss ich erstmal schmunzeln.
Ein Hochsprachenprogrammierer wird auf eine Fördertechnik losgelassen
Nun Fördertechnik gehört zu den Dingen die gerne unterschätzt werden.
Eine Maschine mit Bearbeitungsstationen hat feste Abläufe (meist Schrittketten).
Bei der Fördertechnik ist dies anders. Pakete klemmen, Lichtschranken flackern, Pakete werden von Hand entnommen oder aufgelegt.
Ein robustes Programm reagiert auf all dies mit möglichst wenig Benutzereingriffen.
Bei Fördertechnik ist die Hardwarekonstruktion schon sehr wichtig.
Wer hier an Sensoren spart, spart an der falschen Stelle. Am besten ist, wenn du deine Pakete an jeder Stelle "siehst".
Wenn du zu wenig Sensoren hast, dann brauchst du Weg- oder Transportmerker. "Verschwindet" ein Paket beim Transport, dann brauchst du irgendwelche Resets.
Flattert dir der Schmetterling durch die Lichtschranke kommt gern mal alles durcheinander.
Für Fördertechnik empfield sich die gute alte Verknüpfungssteuerung am besten in KOP.
Aber du kannst natürlich auch gerne Zustandsautomaten in SCL nehmen
Wird nur der Instandhalter nicht so gerne sehen.

Gruß
Blockmove

 

[ddave]

Danke für eure Antworten.

@dingo das sieht tatsächlich interessant aus, hab auch schon einige gute Hinweise daraus bekommen.

@Blockmove
Um ehrlich zu sein, zu meinen Lieblungsaufgaben gehört das auch nicht
"Richtiges" programmieren gefällt mir schon besser.

Bzgl. Robustheit, das Gute ist dass das entscheidende Förderband dass das Material in die Anlage bringt sowieso eingehaust wird in einer "Tunnelabdeckung" um zu verhindern dass man gefährlichen Anlagenteilen zu nahe kommen könnte.
Daher ist der Fall dass einfach so Pakete fehlen schon mal auszuschließen immerhin.
Interessant wird es erst wenn bei einer Störung die Abdeckung geöffnet wird, das muss der Bediener dann halt entsprechend quittieren.

Hast du denn ein Beispiel für sowas ähnliches in KOP?
Mit KOP habe ich noch nie was gemacht, das war für mich immer absolut unlogisch.
Im Moment habe ich vor den Großteil in ST zu machen, oder evtl. auch etwas mit AS.

Wie detailliert ihr so eine Anlage in euren Programmen?
In dem von dingo verlinkten Buch wird erstmal für jeden Aktor und Sensor ein FB geschrieben, bei mir wären das folgende Aktoren/Sensoren:
- Pneumatikzylinder mit Endlagensensoren
- Motor [für Förderbandantrieb]
- Linearantrieb für Regalbediengerät
- Barcodescanner
- Lichttaster (aber das sind ja ganz normale IOs, da wüsste ich nicht was ich in nem Sensor-FB machen sollte ...)

Wie seht ihr das?

 

[Paul]

Ein Programmablauf sieht dabei für mich so aus:
- Paket am Förderband verfügbar
- prüfen ob Pusher eingefahren, wenn ja dann Transport zur Pushposition starten
- Barcode des Pakets lesen und prüfen ob das Paket einsortiert werden muss, falls nein Paket bis zum Ende des Förderbands weiter fahren
- wenn Paket sortiert werden muss und an Pushposition angekommen, prüfen ob RBG bereit zur Aufnahme des Pakets (muss an richtiger Position stehen, und der Platz auf dem RBG frei sein), falls nicht Anforderung an RBG schicken
- wenn RBG bereit ist, Pusher starten, wenn Pusher wieder in der eingefahrenen Endlage angekommen ist, den Sortiervorgang des RBGs starten
- gleichzeitig sobald Pusher in eingefahrener Endlage angekommen ist kann bereits das nächste Paket zum Pusher transportiert werden falls am Eingang schon neue Pakete bereit liegen

Das was du hier schreibst hat schon Hand und Fuß, aber es ist nur ein sehr kleiner Teil der Gesamtaufgabe.
Die eigentliche Herausforderung ist meiner Ansicht nach, die Regalfächer zu verwalten.
Sprich: Wohin mit dem Paket wenn auf dem RBG steht? Welches Fach ist noch frei?
Dann unterstelle ich mal, dass das RBG die Pakete ja ach wieder rausholen soll.
Du brauchst also mindestens 2 Automatik Betriebsarten Einlagern + Auslagern.
Dazu noch Einrichtbetrieb etc.
Auf dem Panel die Möglichkeit mal was am Fachstatus gerade zu biegen (z. Bsp. bei Handentnachme.....)
Alles in Allem eine interessante Aufgabe.

PS:
@ddave
Um ehrlich zu sein, zu meinen Lieblungsaufgaben gehört das auch nicht :grin:
"Richtiges" programmieren gefällt mir schon besser.

Wenn es bei dem RBG mal ordentlich scheppert und ein paar tausen Euro Schaden entstehen weil du einen
kleinen Tippfehler gemacht hast, dann wirst du schon noch merken was "Richtiges" programmieren ist

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du brauchst also mindestens 2 Automatik Betriebsarten Einlagern + Auslagern.

Ggf. noch das berüchtigte umlagern

 

[Blockmove]

Ggf. noch das berüchtigte umlagern

"Türme von Hanoi" in KOP wär ja mal ganz interessant

Um ehrlich zu sein, zu meinen Lieblungsaufgaben gehört das auch nicht
"Richtiges" programmieren gefällt mir schon besser.

Tja, schau mer mal.
Ich meinen langen Jahren habe ich 2mal erlebt, dass Programmierer einen Nervenzusammenbruch bekommen haben.
Beides mal an einer Fördertechnik.

Gruß
Blockmove

 

[Paul]

Ggf. noch das berüchtigte umlagern

Das klingt auch nach viel Spaß

Strategie bei nicht lesbarem Barcode fällt mir so spontan noch ein.
Und wenn dann noch eine "sportliche" Taktzeit verkauft wurde und an den Sensoren gespart wurde.....

 

[ddave]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die eigentliche Herausforderung ist meiner Ansicht nach, die Regalfächer zu verwalten.
Sprich: Wohin mit dem Paket wenn auf dem RBG steht? Welches Fach ist noch frei?
Dann unterstelle ich mal, dass das RBG die Pakete ja ach wieder rausholen soll.
Du brauchst also mindestens 2 Automatik Betriebsarten Einlagern + Auslagern.
Dazu noch Einrichtbetrieb etc.
Auf dem Panel die Möglichkeit mal was am Fachstatus gerade zu biegen (z. Bsp. bei Handentnachme.....)


Wenn es bei dem RBG mal ordentlich scheppert und ein paar tausen Euro Schaden entstehen weil du einen
kleinen Tippfehler gemacht hast, dann wirst du schon noch merken was "Richtiges" programmieren ist

Auslagern gibt es so in der Form nicht.
Die Anlage sortiert die Pakete in ein Regal ein, was gleichzeitig ein Rollwagen ist.
Sprich wenn der Wagen/Regal voll ist wird dieser entnommen und ein neuer leerer Wagen in die Anlage gestellt.
Die Auswertung welches Paket wo hin soll wird außerhalb der SPS passieren, die SPS schickt nur einen HTTP-Request mit dem Barcode an unser "ERP", das sagt mir dann zu welchem Auftrag das Paket gehört, und oder auch direkt in welches Fach das Paket soll (wird immer nach Auftrag sortiert).

Man muss natürlich aufpassen was man da veranstaltet und, aber das ist generell anzuraten wenn man mit teurem Material arbeitet ...
Ich hab die Anlage extra so konstruiert dass selbst wenn etwas nicht richtig gegeneinander verriegelt ist, der Schaden nicht all zu hoch sein dürfte

Ggf. noch das berüchtigte umlagern

Wie oben geschrieben, das ganze ist One-Way

Tja, schau mer mal.
Ich meinen langen Jahren habe ich 2mal erlebt, dass Programmierer einen Nervenzusammenbruch bekommen haben.
Beides mal an einer Fördertechnik.

Ich kann dich beruhigen, ich bin mir extrem sicher dass das nicht passieren wird. Da hab ich schon deutlich schlimmere Sachen gemacht.

Das klingt auch nach viel Spaß

Strategie bei nicht lesbarem Barcode fällt mir so spontan noch ein.
Und wenn dann noch eine "sportliche" Taktzeit verkauft wurde und an den Sensoren gespart wurde.....

Entweder schleuse ich den nicht gelesenen Barcode halt aus, oder die Anlage geht auf Störung und der Bediener muss sich das anschauen.



Ich komme übrigens langsam weiter.
Bin gerade dabei mir eine Simulations der gesamten Anlage auf zu bauen.

Bzgl. Handbedienung:
Wie macht ihr das am geschicktesten?
Nehmen wir an ich hab einen FB für den Pusher der das Paket vom Förderband befördert.
Der hat jetzt zwei Ausgänge für ein und ausfahren des Pneumatikzylinders.
Würdet ihr jetzt hinter den FB die Umschaltung zwischen Hand- und Automatikbetrieb bauen, oder direkt in den FB für den Pusher integrieren?

Was gibt es da für Vor und Nachteile?

 

[roboticBeet]

Würdet ihr jetzt hinter den FB die Umschaltung zwischen Hand- und Automatikbetrieb bauen, oder direkt in den FB für den Pusher integrieren?

Ich würde das komplett in den Pusher-FB integrieren, um die gesamte Funktionalität des Pushers zusammen zu haben (Stichwort: Wiederverwendbarkeit)

 

[Paul]

Bzgl. Handbedienung:
Wie macht ihr das am geschicktesten?
Nehmen wir an ich hab einen FB für den Pusher der das Paket vom Förderband befördert.
Der hat jetzt zwei Ausgänge für ein und ausfahren des Pneumatikzylinders.
Würdet ihr jetzt hinter den FB die Umschaltung zwischen Hand- und Automatikbetrieb bauen, oder direkt in den FB für den Pusher integrieren?

Was gibt es da für Vor und Nachteile?

Also ich habe einen FC für die Ventilansteuerung.
Dieser FC wird so oft aufgerufen wie es eben Zylinder / Ventile gibt.
Der FC wird auf der Eingangsseite beschaltet mit:
Betriebsart
Anforderung Grundstellung HAND
Anforderung Grundstellung AUTO
Anforderung Arbeitsstellung HAND
Anforderung Arbeitsstellung AUTO

Auf der Ausgangsseite:
Ventil Grundstellung
Ventil Arbeitsstellung

In dem FC dürfen natürlich keine absoluten Adressen verwendet werden (wegen Mehrfachaufruf)
Im FC wird die Verknüpfung zwischen Betriebsart und Anforderung GS/AS gemacht

Die Anforderungen für Automatik werden im Schrittkettenbaustein gebildet.
Die Anforderungen für HAND über Panel-Schaltflächen.

Wenn man will kann man in den FC auch noch eine Statusanzeige fürs Panel reinpacken.
Also Endlagenschalter mit abfragen und Zustand auf den Panel anzeigen.
Ist Geschmackssache wie weit man das treiben will.

Zusätzlich habe ich noch eine FC für die Laufzeitüberwachung jedes Zylinders
Sprich:
Wenn der Ausgang <Grundstellung> angesteuert wird erwarte ich dass in x Sekunden auch der Eingang <Grundstellung> kommt.
Das Gleiche gilt natürlich für die Arbeitsstellung.
Andernfalls Störmeldung.
Die Zeit messe ich mit dem 1/10 Sekunden Takt der CPU den ich in eine Hilfsvariable zählen lasse.

Ist meine Methode mit der ich ganz gut fahre.
Möglichkeiten gibt es aber jede Menge..........

 

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vor allem bei Transporsystemen musst du ab und zu dazwischen von Hand eingreifen.
Das Grundproblem dabei ist, dass wenn man die ganze Anlage auf Hand schaltet meist auch automatisch was Resetet werden muss
(das kommt immer so im Laufe der Zeit, wenn man bestimmte Schwierigkeiten beseitigten muss, auch wenn man sich das vorher anders ausgedacht hat
und schups ist man soweit, dass man alles ausräumen muss oder definiert anfahren.)
Oft würde es reichen, kurz in der Handsteuerung einzugreifen, ohne dass der Bediener überhaupt in die Anlage rein geht.

Ein globales Programmkonzept das sich bei uns bwährt hat sieht so aus:

- Jedes Gerät (z.B) Antrieb, Stopper bekommt einen eigen FB (der ist prinzipell immer gleich und kann für Alle Antriebe druchkopiert werden)
- Für ein Transportband mit Stopper heist das es gibt:
FB_TransportBand1_Main
FB_TransportBand1_Antrieb
FB_TransportBand1_Stopper

Jedes Device bekommt eine Standard Flag-Struktur, welche den Status z.B. des Antriebs anzeigt.
Dies sieht z.B. für einen Antrieb so aus, egal ob Pumpe oder Transportband

Stauts_Flags
Bit 0: Hand
Bit 1: Auto
Bit 2: ReadyToStartAuto
Bit 3: Run
Bit 4: Run fwd
Bit 5: Run rev
Bit 6:
Bit 7:

Dann würde ich dem Transportband noch verschiedene Startmerker geben.
Genau 8 (wieder ein Byte). So dass jedes Automatikprogramm einen eigenen
Startmerker für den Transport setzen kann. Das ist extenziell wichtig
für die spätere Fehlersuche.

Start1: wäre dann z.B. der exklusive Startmerker für Automatikprogramm 1
Start2: wäre dann z.B. der exklusive Startmerker für Automatikprogramm 2

Automatikprogramm 1 verwendet dann nur Start1 um den Transport zu starten
Automatikprogramm 2 verwendet dann nur Start2

Ein einziger Startmerker der wild von verschiedenen Programmteilen angesteuert wird.
ist wie ein Schalter den jeder drücken kann. Man weis später nicht mehr wer es war
und warum das jetzt ein oder aus ist.

Dabei hat sich bewärt, die Startmerker direkt dem Datenbereich des Antriebs zuzuordnen.
D.h.
Transport1.Start1
Da das für das durchkopieren der Antriebs-FB besser ist, als
Programm1.StartFuerTransport1

------------------------------------------
Das Betriebsartproblem Hand/Auto
------------------------------------------

Wir haben das mittlerweile so in den Griff bekommen:

Jeder Antrieb und jeder Stopper usw. bekommt seine eigene Betriebsart HAND/AUTO
(in der Prozesstechnik für Lüfter und Pumpen verwenden wir AUS/HAND/AUTO,
wobei Hand dort HAND-EIN ist, da man nur 1 Drehrichtung hat.
Für Transportantriebe die vw/rw laufen, muss man HAND/AUTO verwenden und das vw/rw dann
nochmals extra erledigen - das ist etwas mehr Programmierarbeit).

Jedes einzelne Gerät hat somit einen eigen Schalter auf dem HMI, welcher es erlaubt,
dessen Betriebsart unabhängig vom gesmaten System zu schalten. Somit kann ich einen
einzigen Transportanstrieb oder nur einen einzigen Stopper aus dem Automatikprogramm
rausnehmen und diesen im Hand steuern.

Jetzt kann man aber nicht jedem Bediener wild alles Hand/Auto steuern lassen.
Weiterhin kann man nicht verlangen, dass vom Bediener jedes einzelne Gerät in Auto geschaltet
wird, damit alles korrekt automatisch läuft.

Deswegen gibt's einen Betriebsartenhandler, vorgeschaltet vor dem individuellen Betriebsartschalter
der Geräte.

Der Betriebsartenhandler macht folgendes:
man kann diesen auf Globale kontrolle stellen: dh. es gibt 2 Schaltmodes

1: den Global Control, dafür gibt es einen Parameter, der die Schaltrechte bestimmt

--- hier der Auszug aus der Programmdoku -----
Golbal Control:
Mode 0: User can operate all (OFF/ON/AUTO)
Mode 1: Global HAND: User can operate (OFF/ON) - AUTO is DISABLED
Mode 2: Glabal AUTO: User can operate nothing - Set DeviceMode fix to AUTO
For this SET cfg_Global_Parent = FALSE and
iGlobalMode=Global_UserRights_Switch

2.. den Parent Control Mode
--- hier der Auszug aus der Programmdoku -----
In Parent Control:
The Device is a Child Device and it's Mode is directly controlled by the
Parent Device. For this SET cfg_Global_Parent = TRUE and
iParentMode='ModeOfParent'

Damit lassen sich nur folgende Szenarien erledigen:

Ich kann dem Bediener alle Rechte entziehen und das Gerät fest auf Automatik stellen.
Ich kann dem Bediener nur die Handbedienung feigeben, so dass er nur Ein/Aus schalten kann

Mit dem ParentControlMode kann ich ein Gerät, z.B. Antrieb oder Stopper fest an eine übergeordnete
Betriebsart binden. Z.B. die Betriebsart der Station. Damit hat man sehr feine Konfigurationsmöglichkeiten
für den Eingriff.

Speziell für die Inbetriebnahme ist das genial.

Für den Elektriker der die Anlage aufbaut und alles nur mal im Hand testen muss, geb ich nur die
Handsteuerung frei. Somit kann schon keiner rumspielen und eine Automatik testen die evtl. noch gar
nicht korrekt funktioniert.

Während der Inbetriebnahme schalte ich mir vollen Hand/Auto Zugriff auf unterster Ebene frei.
D.h. direkter Handeingriff am Gerät während des vollen Automatikbetriebs.
Dies ist genial, wenn man weis was man tut! Man kann z.B. wenn es irgendwo hackt, weil das Autoprogramm
nicht korrekt funktionert, schnell mal das per Handsteuerung erledigen. Z.B. schnell den Stopper per
Hand absenken!


Damit das alles korrekt zusammenspielt muss man z.B. beim Übertransport von Tisch1 auf Tisch2
die oben erwähnten Flags abfragen.

Tisch1.Flag_Run_fwd ist z.B. High, egal ob ich das per Automatik oder Hand vw fahre.
Somit es für Verriegelungen und Überwachungen egal warum der Tisch läuft.


------------------------------------------
Das Weitergabeproblem von Tisch zu Tisch
------------------------------------------

Für die Weitergabe von Produkten von Tisch zu Tisch hab ich einen
Master Slave Handler

Wenn ich z.B. von Tisch1 nach Tisch 2 fahren will.
Hab ich 2 Möglichkeiten.

a) Tisch 2 startet als Master und Tisch 1 läuft als Slave mit
b) Tisch 1 startet als Master und Tisch 2 läuft als Slave mit

Sind deine Produkte nicht kürzer als der Tisch, ist das fast egal.
Gehen Produkte wie Platten über mehrer Tische ist as extentziell wichtig.

Für Pakete, die wohl wesentlich kürzer als die Transporte sind, würd
ich wohl komplett auf den Master/Slave Handler verzichten und einfach
eine Schrittkette oder Logik verwenden.

------------------------------------------
Anfahr-, Reset und Plausiblitätsprobleme
------------------------------------------

Probleme gibt es immer, wenn Produkte zwichen Sensoren liegen, so dass man beim Anfahren
oder nach Reset, nicht weis, ob da wirklich was ist.
Evtl. muss man auch wissen ob ein Paket abhanden gekommen ist!

Wir lösen das so:

jeder Transportantrieb bekommt einen eigenen Encoder (bei uns einfach ein Plastikring, in den
4 Schrauben eingelassen sind, diese werden mit einem iduktiven Sensor erfasst- also ein 4-Impuls Encoder)

Damit kann man foldens machen:

1. beim Anfahren kann ich kucken ob noch irgendwo ein Produkt liegt.
ich lass also den Tisch losfahren, ist die maximale Wegstrecke abgelaufen, ist der Tisch leer und
wird angehalten.
Bei jedem undefinierten Start der Anlage kann man so alle Tische loslaufen lassen. Produkte die irgendwo
zwischen den Lichtschranken liegen laufen dann eine Sensorposition an.

2. Ich kann virtuelle Sensoren verwenden.
Ich kann über das Encodersignal die Position von Lichtschranken um eine Anzahl von Impulsen verschieben
und hab virtuelle Sensoren an Positionen, an die ich sonst z.B. keinen Sensor anbauen kann.

3. Ich kann die belegte und/oder freie Wegstrecke nach einer Lichtschranke erfassen.

4. Ich kann meine Lichtschrankensignale in einen Ringpuffer legen, welcher mit dem Encoder getriggert wird.
Somit hab ich ein digitales Abbild der Sensorsignale über die komplette Tischlänge
Damit weis ich, wo ein Produkt auf dem Tisch liegt, wíeviele Produkte auf dem Tisch liegen, wie lang diese sind.

Das kann man dazu verwenden um Plausiblitätsprüfungen zu machen:
Durch den Ringpuffer weis ich, wann das Produkt an der Ende Lichtschranke ankommen müsste. Tut es das nicht,
war es entweder ein Fehlsignal von der Anfang Lichtschranke oder das Produkt ist verschwunden. Sprich es hat
jemand weggenommen.

Hat man z.B. Barcodescanner und scannt das Paket, schreibt man den Barcode mit den Lichtschrankensignalen in einen
Ringpuffer. Somit kann man am nächsten Barcode Scanner nun die beiden gescannten Codes verlgeichen.
Sind sie unterschiedlich, dann stimmt was nicht!



------------------------------------------
Noch ein Tip für Codesys
------------------------------------------

Codesys erlaubt im Gegensatz zu Step7 die komplett hirarchische Anlage von Benutzerdefinierten Datentypen.
Eine vorgensweise, die bei CodeSys viel Sucharbeit spart ist das Intellisense daraufhin zu trimmen einem
seine ganzen Objekte anzuzeigen:


Das Intellisens von Codesys beherrscht hirachische Typstrukturen, so dass man in der Entwicklungsumgebung

dann foldenes eintppen kann

Anlage.Tisch1.SensorAnfang, statt Anlage nimmt man besser m wie Maschine oder a wie Anlage (das geht einfach schneller)



Man erzeugt sich UDTs

Type Zylinder
Ventil : Bool;
Sensor_Eingefahren : Bool;
Sensor_Ausgefahren : Bool;
EndType

Type Tisch
SensorAnfang : Bool;
SensorEnde : Bool;
EncoderSignal: Bool;
EncoderValue : DINT;
Stopper : Zylinder;
EndType

Dann macht man einen Typ für seine Maschine, dort trägt

Type m
Tisch1: Tisch;
Tisch2: Tisch;
Tisch3: Tisch;
Tisch4: Tisch;
EndType

Soviel ich mitbekommen habe kann man bei CodeSys3, was Wago eCockpit ja ist,
bei der Hardwaredefintion mittlerweile die Signale irgendwie direkt den Typstrukturen zuweisen.
(bin mir aber nicht sicher!)


jetzt kennt Intellisense die ganze Maschine. Um ein Signal zu finden tippt man

m. Intellisense öffnet nun die Auswahl Tisch1 .. Tisch4

m.Tisch1. Intellisense öffnet die Liste mit den Werten für Tisch

m.Tisch1.Stopper.Sensor_Eingefahren


---------------------------------------------------------------------------------------------------------------------

Als erstes würde ich dir raten, mal die Ocat Library zu besorgen, das ist eine Open Source Library für
Codesys.

Dann hab ich noch eine Library die löst auch einige der obigen Probleme, ist aber für Step7,
hätte nichts dagen, wenn die mal jemand auf Codesys convertiert.

Gibt's zum Download für Step 7 unter
https://github.com/Maagic7/Maagic7

ist noch die Version von 2016, kann aber die aktuelle nicht hochladen, da irgendwas mit meinem GitHub Account nicht funktionert

 

[RPC-VK]

Dann hab ich noch eine Library die löst auch einige der obigen Probleme, ist aber für Step7,
hätte nichts dagen, wenn die mal jemand auf Codesys convertiert.

Gibt's zum Download für Step 7 unter
https://github.com/Maagic7/Maagic7

ist noch die Version von 2016, kann aber die aktuelle nicht hochladen, da irgendwas mit meinem GitHub Account nicht funktionert

Deine Bibliothek schaut interesant aus, sicherlich ein paar nützliche Sachen dabei

Die aktuelle Version kannst du doch auch hier im Forum mit anhängen.

 

[Mrtain]

Das Konzept mit den virtuellen Sensoren erschließt sich mir nicht so ganz. Könntest du etwas näher erläutern?

Gruss

 

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Martin

virtuelle Sensoren.

Beispiel:
Ich hab einen Transporttisch (für Platten) mit Sensoren Tisch_Anfang, TischEnde_Bremsen, Tisch_Ende
Dann noch einen incremental Encoder mit z.B. 4 Impulsen (wir nehmen Plastikring mit 4Stk. M8 Schrauben 6-Kant)

Rollendruchmesser 100m => Umfang 314 mm => 1 Impuls des Encoders = 314/4 = 78.5mm (ca. 80mm) Wegstrecke des Transportes.

Der Sensor Tisch_Anfang sitzt mechanisch direkt am Anfang, d.h. bei Maß 0mm
Brauch ich jetzt aber das Positionssignal nicht bei 0m sondern z.B. bei 300mm, weil dort ein Stopper oder sonst was ist,
dann bräucht ich eigentlich einen zusätzlichen Sensor direkt beim Stopper.

Jetz kann sein
- dass dort einfach keine Sensor reinpasst
- dass man möglicht sparen möchte und wenig Sensoren verbauen
- man hat erst auf der Baustelle festgestellt, dass man dort noch einen Sensor benötigen würde

jetzt kann man den Sensor Tisch_Anfang verwenden und diesen mit dem Encoder Pulsweise verschieben.
D.h, im Streckenabstand von 78.5mm
Für ca. 300m brächte ich jetzt etwa 3,8 Impulse (nun muss ich mich für 3 oder 4 glatt entscheiden, jenachdem was noch geht)

Ich entscheide mich mal für 3 Impulse = 3x78.5mm = 235,5mm
D.h. ich hab somit einen virtuellen Sensor der einem bei Tisch-Maß 235mm montierte echten Sensor entspräche

Zustätzlich mit dem Verschieben des echten Sensors erfasse ich noch die Anzahl der Impulse, die nach dem echten Sensor frei und belegt sind.
Mit den frei Impulsen hat man eine einfache Methode für Mindestabstände.

Die belegte Wegstrecke nach dem echten Sensor kann man für verschiedenste Dinge verwenden.
- Wenn man die Länge der Platte kennt, weiß man, wann die Hinterkante naht (z.B. Bremsen an Hinterkante)
- man kann damit entscheiden, ob es ein wirkliches Produkt war, oder viel zu kurz (z.B. bei Fehlsignal des Sensors)