fragen zur programmierphilosophie

[alb]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich habe jetzt die ersten Grundlagen der SPS programmierung verinnerlicht und mache mich an ein erstes, erstmal nur simuliertes, Projekt. Die automatisierung eines VAkuumpumpstandes:

Der Benutzer kann einen von vier Sollzuständen anwählen. Die SPS soll die Anlage dann auf sicherem Weg in den Gewünschten Zustand bringen. Die Anlage kennt theoretisch sehr sehr viele zustände. Diverse ventile und ähnliches. Ich habe 12 zustände definiert, die die relevanten Eigenschaften abdecken. z.B. für Zustand 6 ist es unwichtig wie Ventil 3 steht. Die Anlage sollte ieigentlich immer in eine dieser "klassen" fallen. Beispiele für solche zustände können sein: Vorbereitet zum Pumpen (Ventile stehen richtig), Pumpen, abgepump (solldruck ist erreicht) und Störzustände.

Es gibt einen Funktionsblock, welcher anhand der Eingangsdaten, Endlagenschalter der Ventile und Ähnliches, ermittelt in welchem Zustand sich die Maschiene befindet.

Dieser FB wird beim starten aufgerufen und bestimmt den Zustand. soll die sps einen anderen zustand, z.B. durch dass schließen eines Ventils einstellen, gibt es zwei mögliche Strategien:
die sps gibt Anweisung zum Ventilschließen und trägt den neuen Zustand in die Zustandsvariable ein wenn die rückmeldung ventil geschlossen kommt.
ODER:
die SPS gibt Anweisung zum Ventilschließen. Der Zustandsbestimmungs FB wird zyklisch aufgerufen und gibt den Zustand anhand der Eingangsdaten vor.

Die Frage ist also: SPS gibt Anweisung und bestimmt wo sie ist vs. SPS gibt Anweisung und guck wo sie jetzt ist. ein bisschen wie Steuern vs Regeln.

Bedeutng bekommt der Unterschied wenn sich die anlage nicht verhält wie sie soll. Bei der zweiten Variante bräuchte ich extra Fehlerroutinen. Bei der ersten ist fraglich, ob der code lesbar, verständlich, und bei komplexeren sachen überhaupt so möglich ist.


Eine zweite frage:
Ich habe meine 12 zustände. z.B. kann auf zustand 3 der Zustand 4 oder auch sieben folgen. theoretisch könnte jeder beliebige Zustand folgen, der müßte aber evtl. mit einer komplizierten routine eingeleitet werden. Die als direkte Folgezustände gewählten zustände können sehr direkt eingeleitet werden. z.B. ein Ventil schließen. Ein sehr verschiedener Zustand wird über einen Pfad über zwischenzustände erreicht.
In meiner Projektplanung habe ich das modellhaft gezeichnet, was etwa so aussieht:
Zustände als Kreise mit Nummern. Pfeile auf die möglichen Folgezustände. An diesen Pfeilen stehen zahlen, wenn du nach Zustand 0 möchtest, nimm den Pfeil wo die 0 dran steht.
Das ist ein sehr eigenwilliger Prograqmmierstiel. Es gibt keine Routine "belüften" sondern nur eine Kontroll struktur die guckt, wo bin ich und wo will mich der nutzer hinhaben. davon abhängig wird dann z.B. ein bestimmtes Ventil geschaltet. Das bringt die anlage in den nächsten zustand, dieser weiß dann wieder was zu tun ist. Die Logik eines jeden einzelnen Zustands ist sehr einfach, meißt gibt es nur einen folgezustand, verzweigungen sind eher selten. Statt einer komplizierten Routine gibt es das Langhangeln an PFaden.
Die Frage: ist das Sinnvoll oder sollte ich mir das schnell wieder aus dem Kopf schlagen.
Der Code selber, ist schwer verständlich. Mit hilfe des "Pfad-Plans" ist es sehr gut verständlich.
Komplexe Rutienen werden auf einfache zustandsübergänge reduziert. (Divide and Qonquer)
keine Ahnung in wie weit das bei komplizierteren Anlagen überhaupt umsetzbar ist. wie sich das erweitern und warten läßt.

so, das waren meine Fragen. Ich habe schon mitbekommen, das Fragen zum Programmierstiel meißt ins unendliche führen und jeder seinen etas eigenen Stiel hat. Ich bin eben Anfängeer und muss meinen stiel erstmal finden. da bin ich für jede unterstützung dankbar.

 

[Verpolt]

Hallo,

Die Frage ist also: SPS gibt Anweisung und bestimmt wo sie ist vs. SPS gibt Anweisung und guck wo sie jetzt ist. ein bisschen wie Steuern vs Regeln.

Bedeutng bekommt der Unterschied wenn sich die anlage nicht verhält wie sie soll. Bei der zweiten Variante bräuchte ich extra Fehlerroutinen. Bei der ersten ist fraglich, ob der code lesbar, verständlich, und bei komplexeren sachen überhaupt so möglich ist.

z.B.: Schrittketten verwenden

-Schritt 1: Ventil 1 schalten

-Schritt 2: Ventil 2 schalten, Ventil 4 schalten

.
.
.
Parallel zu diesen Schritten die Position abfragen (Störungen)

U Schritt1
U "Ventil1Vor"
UN "Ventil1Vorne" //Sensor EndPos erreicht
L S5T#1S
SE T1
U T1
="Störung1" //Ventil nicht vorne

Ein sauber strukturiertes Projekt, das auch mal ein anderer "schnell" verstehen kann, ist immer besser als ein "Code-Trauma".

Klar definierte Abläufe in Unterprogramme aufteilen.
Die Maschine hat idR. Teilaufgaben (z.B.rodukt Zufuhr, Produkt Bearbeitung 1..2..3... , Produkt Ausschleusung, usw..)
Auf Wiederverwendbarkeit achten (Funktionsbausteine).

 

[JOHKU]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo alb,

ich glaube dass Du auf dem absolut richtigen Weg bist.
Wenn ich alles richtig verstehe definierst Du deine Aufgabe als Zustandsautomat, vom Typ Moor.
Erstens musst Du den Computer ausschalten und einen Zustandsgraphen auf Papier definieren. In einem Zustand kann der Automat solange verbleiben bis durch ein externes Ereignis, sprich Signal, eine Transition zu einem Folgezustand ausgelöst wird.
Den zustand des Automaten schreibst Du in ein Zustandsregister.
Das bedeutet dass der Folgezustand sich immer mit Hilfe einer Logik, aus den Eingängen und dem aktuellen Zustand sprich Zustandsregister, ableiten lässt.
Die Ausgänge des Automaten werden nur anhand der Zustandsnummer definiert.
Zur Fehlerbehandlung und Diagnose solltest Du auch Fehlerzustände Berücksichtigen in denen Dein Automat bis zur Quittierung verharrt.
Realisieren würde ich die Aufgabe in SCL und würde auch nicht vor einer großen CASE Anweisung zurückschrecken.
Für jeden Zustand kann noch eine Wartezeit und eine Überwachungszeit definiert werden.
Wartezeit und Überwachungszeit werden beim Zustandwechsel geladen. Der Zustand darf nicht vor Ablauf der Wartezeit verlassen werden und muss vor Ablauf der Überwachungszeit in einen Folgezustand bzw. danach in einen Fehlerzustand übergehen.
[FONT=&quot]Viel Spass!


[/FONT]

 

[Verpolt]

Habs das Thema nochmal gelesen

...und weg

 

[Boxy]

Evtl. sollte sich der TE dann Gedanken über High-Graph machen
Da könnte man es als Zustandsgraphen programmieren.

Aber irgendwie verstehe ich die ganze Beschreibung / Fragestellung nicht so

 

[alb]

Zuviel Werbung?
-> Hier kostenlos registrieren

HAllo,
erstmal danke für die Antworten. Einige leute hatten wohl probleme zu verstehen, was ich so richtig meine. Hab meinen eigenen text nochmal gelesen und kann die Verständnisschwierigkeiten auch verstehen. Als ich das geschrieben habe, sass ich schon einige stunden vorm REchner, und war schon etwas durch den Wind. Auf das kommunizieren mit Rechnern statt mit menschen eingestell ;-)

Meine zweite Frage wurde von JOHKU richtig verstanden. Ich wollte soetwas wie einen Moore-Automaten beschreiben. Die Frage war also:
Nehme ich einen Mooreautomaten oder Löse ich das Problem in dem ich mir Zwei Routinen schreibe, eine zum Be- und eine zum Entlüften.
Inzwischen denke ich, dass man die Frage nicht wirklich beantworten kann. Hängt wohl vom persöhnlichen Geschmack und der konkreten Aufgabenstellung ab.

Die erste Frage:
Welche der Folgenden beiden Möglichkeiten ist besser, um den Zustand der Anlage festzulegen?
1.: Es gibt eine Funktion Zustandsbestimmung, die guckt sich alle eingangsdaten an, bestimmt den Zustand und "diktiert" dann, in welchem Zustand sich die SPS befindet.

2.: Die Routine Belüften schaltet ein Ventil, prüft ob es umgeschaltet ist und bestimmt dann selber dass sie im nächsten Zustand angekommen ist.

Ich denke, die erste Variante ist wohl etwas eigenwillig und entspricht nicht dem Standart. Ich habe mich also für die 2. enschieden.

Hoffentlich ist jetzt etwas deutlicher geworden was ich meine. Wenn nicht betrachten wir den Thread einfach als geschlossen. Ich dneke inzwischen auch, dass man dazu nicht biel sagen kann. hab hier meine "wirren" gedanke reingeschrieben. Sorry falls das zusehr in Richtung spamen geht.

lg

ps.: Der Simulierte Pumpstand funktioniert. Allerdings noch ohne jegliche Fehlererkennung und Sicherheit.

 

[bike]

Ich denke, die erste Variante ist wohl etwas eigenwillig und entspricht nicht dem Standart.

Stimmt, das ist nicht Standard.


bike

 

[JOHKU]

HAllo,



Die erste Frage:
Welche der Folgenden beiden Möglichkeiten ist besser, um den Zustand der Anlage festzulegen?
1.: Es gibt eine Funktion Zustandsbestimmung, die guckt sich alle eingangsdaten an, bestimmt den Zustand und "diktiert" dann, in welchem Zustand sich die SPS befindet.

2.: Die Routine Belüften schaltet ein Ventil, prüft ob es umgeschaltet ist und bestimmt dann selber dass sie im nächsten Zustand angekommen ist.

Ich denke, die erste Variante ist wohl etwas eigenwillig und entspricht nicht dem Standart. Ich habe mich also für die 2. enschieden.


lg

ps.: Der Simulierte Pumpstand funktioniert. Allerdings noch ohne jegliche Fehlererkennung und Sicherheit.

Hallo,
ich denke die 1. Variante ist der Versuch eines basisdemokratischen Automaten vom Typ alb.
Wenn Dein Programm aus den Eingängen den Zustand der Anlage 100% ermitteln kann handelt es sich nicht um eine sequentielle Logik (Zustandsautomat) sondern um eine kombinatorische Logik, UND/ODER ohne speichernde Funktion.
Ein Automat sollte immer einen Zustand 0 "Initialisierung" besitzen und danach die volle Kontrolle der Anlage übernehmen.

lg

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein Automat sollte immer einen Zustand 0 "Initialisierung" besitzen und danach die volle Kontrolle der Anlage übernehmen.

Auf jeden Fall. Dazu muss die gesteuerte Maschine aber auch einen entsprechenden Zustand kennen und sich dorthin bringen lassen. Bei diesem Punkt legen einem die Konstrukteure gern so manchen Stolperstein in den Weg. Beim Start der SPS macht es deshalb schon Sinn, einmal die Sensorik abzufragen, um so viel wie möglich über den aktuellen Zustand in Erfahrung zu bringen und der SPS die Initialisierung zu erleichtern.

 

[JOHKU]

Auf jeden Fall. Dazu muss die gesteuerte Maschine aber auch einen entsprechenden Zustand kennen und sich dorthin bringen lassen. Bei diesem Punkt legen einem die Konstrukteure gern so manchen Stolperstein in den Weg. Beim Start der SPS macht es deshalb schon Sinn, einmal die Sensorik abzufragen, um so viel wie möglich über den aktuellen Zustand in Erfahrung zu bringen und der SPS die Initialisierung zu erleichtern.

Eventuell habe ich mich nicht klar ausgedrückt, aber jedes SPS Programm muss den Kaltstart/Initialisierung sicher ausführen.
Selbstverständlich werden die Sensoren abgefragt und danach ein "aktueller Zustand" ermittelt der auch ein Fehlerzustand sein kann.
Der Zustand des Automaten hat mit den Zuständen des Prozesses primär nichts zu tun.
Sollte der Prozess keinen sichern Zustand besitzen wie z.B ein Flugzeug in der Luft, muss er manuell in einen Zustand gebracht werden aus dem der Automat dann die Kontrolle übernehmen kann. Bis zu diesem Zeitpunkt bleibt der Automat in einem Fehlerzustand.

Das Jammern über die Konstrukteure die das Genie der Programmierer nicht würdigen ist hier weit verbreitet, bringt uns aber nicht wirklich weiter.
Eine Anlage ist entweder funktionsfähig und dann kann man auch eine Steuerung dafür programmieren oder sie ist es nicht und dann hilft auch der beste Programmierer nicht weiter.
Ein gutes Systemgespräch mit den Konstrukteuren sollte aber am Beginn der Arbeit stehen. Wenn man dann das Ergebnis in Form eines Lastenheft/Pflichtenheftes festhält hat man eine reelle Chance gute Arbeit abzuliefern.

lg

 

[StructuredTrash]

Das Jammern über die Konstrukteure die das Genie der Programmierer nicht würdigen ist hier weit verbreitet, bringt uns aber nicht wirklich weiter

Ich jammere nicht, und schon gar nicht über fehlende Anerkennung meines Genies. Schon der Umstand, dass die Beschäftigung mit irregulären Zuständen der Maschinen weitgehend mir überlassen bleibt, ist ja schon Anerkennung genug.

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Jammern über die Konstrukteure die das Genie der Programmierer nicht würdigen ist hier weit verbreitet, bringt uns aber nicht wirklich weiter.
Eine Anlage ist entweder funktionsfähig und dann kann man auch eine Steuerung dafür programmieren oder sie ist es nicht und dann hilft auch der beste Programmierer nicht weiter.

Dann würde ich schreiben träum wieter.

Es ist doch ein Wunschdenken, dass man eine Maschine oder Anlage bekommt, die solch eine Sensorik hat, dass man damit immer fehlerfrei in Grundstellung kommt.

Es ist die Aufgabe eines Entwicklers, nicht nur den Ablauf sondern alle Sonderzustände zu erkennen und dafür Strategien zu entwickeln und zu programmieren, damit es weitergeht


bike

 

[JOHKU]

@Bike

Lieber Kollege

ich träume nicht ich habe 23 Jahre Kraftwerks- und Feuerungstechnik hinter mir. Ich glaube klare Vorstellungen über die Bedeutung von Störfallbeherrschung zu haben.
Sich die richtigen Gedanken darüber zu machen wie eine Software auf Ausnahmesituationen zu reagieren hat ist "Business as usual". Dafür gibt es keine Tapferkeitsmedaille.
Im Fachjargon der Informatiker redet man gern von „Exception handling“.
Aber wir können uns ja weiter gegenseitig beweihräuchern und uns bestätigen dass wir die Größten sind.

lg

 

[bike]

Bin ich jemandem auf die Hühneraugen getreten?
Ich bin echt begeistert wie lange du so toll programmierst, ich kann das nicht.

Uns geht es meist so, dass wir minimale Technik(Mechanik) mit einem maximalen Programm versorgen müssen. Entwicklungskosten sind einmalig, Mechanik sind laufende Kosten bei jeder Maschine

Fakt ist doch, dass ein gutes Programm eine Sch... Maschine zum rennen bringt.
Ein Sch.. Programm bremst jede noch so gute Mechanik aus.

Zum Thema beweihräuchern nur soviel: Mich kotzt es an, wenn für jede Lösung die Software gefordert wird und Einwände weggeschoben werden.
Mit deinem Geschreibe passt du nahtlos in die Reihe unser Konstrukteure.

Nix für ungut


bike

 

[JOHKU]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lieber Kollege

ich habe zu keinem Zeitpunkt behauptet toll zu programmieren, habe nur versucht gegen den Vorwurf eines Träumers Stellung zu nehmen.

Im übrigen was findest Du denn daran so verwerflich wenn mann eine teuere Mechanik mit einem gekonnten Softwaretrick ersetzt?
Ich gestehe gern, für sowas sollte mann dann auch die Anerkennung seiner Kollegen, am besten auch in metallischer Form, bekommen!
Aber, mit Verlaub, das gehört nicht in dieses Forum.

 

[Blockmove]

Auch wenn Sonntag ist ... Weihrauch sollte in der Kirche bleiben.

Sinn und Zweck eines SPS-Programms ist nun mal die Steuerung bzw. Regelung von Maschinen, Anlagen, Prozessen. Und somit steht die Anlage bzw. der Prozess im Vordergrund und nicht dass SPS-Programm bzw. das Ego des Programmierers.

Gruß
Dieter

 

[RobiHerb]

Miteinander Reden ...

Also, das einfachste ist immer noch mit dem Kollegen von der anderen Fachrichtung die Probleme zu diskutieren.

Wir sollten schon etwas von Hydraulik und Mechanik verstehen, die sollten wissen, dass wir keinen Windows Rechner zum Steuern verwenden. Eine kleine interne Schulung, was eine SPS so an Einschränkungen hat, kann da Wunder wirken.

Wenns denn nichts bringt, es gibt ja auch irgendwo einen Chef und der ist in der Regel sehr daran interessiert, dass die Zusammenarbeit auch über Fraktionsgrenzen funktioniert.