wie gehe ich da ran?

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich frage einen Zustand ( START oder BETRIEB ) zweier Tanks, je nach den Füllständen meiner Teichanlage ab.

Ich denke, es geht weder um Kunden, noch um Anwälte, sondern um einen Heimwerker, der niemandem etwas verkaufen will. (Hoffe ich zumindest sehr!!)

Die eindeutige Speicherung der Betriebsart in einer einzelnen Variablen wäre da besser.
Nur zu meinem Verständnis, meinst du damit indirekt auch gerade die Verwendung einer CASE Struktur?

Code:
CASE iBetriebsart OF
0: (* Init *)
10: (* aus *)
20: (* Normalbetrieb *)
30: (* Niveau absenken oder sonst was *)
END_CASE
 
CASE OF bietet sich für so etwas meistens an. Ich würde allerdings die Werte für die Betriebsarten als Konstanten oder als Enumeration deklarieren. Die Wahrscheinlichkeit, dass durch Flüchtigkeitsfehler undefinierte Werte zustandekommen, wird damit geringer.
Ausserdem sollte die CASE-Anweisung einen ELSE-Zweig enthalten, mit dem die Anlage in einen definierten Zustand gebracht bzw. dort gehalten wird. Im einfachsten Fall kann dort die selbe Aktion oder der selbe FB wie bei "Aus" aufgerufen werden. Ein, zumindest in der Entwicklumgsumgebung, sichtbarer Hinweis darauf, dass dieser Aufruf irregulär zustandegekommen ist, kann dabei aber nicht schaden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hoffe, dass du kein Programmierer bist.
Mal eben quick and dirty ein Programm basteln und dann verschwinden.
Der Lackierte ist der Kunde.

Naja also wir kennen uns ja alle nicht - und ich sowieso niemanden, wo ich doch recht neu in diesem Forum bin. Auch musst Du was mich betrifft nichts hoffen oder Dich bangen. ;)

Grundsätzlich stimme ich Dir ja schon zu: ein kleiner Hack kann viel ausrichten und man sollte schon probieren, es "richtig"(tm) zu machen. Mein Elfenbeinturm bezog sich jedenfalls darauf, jedes noch so kleine Problemlösung auseinanderzupflücken - ohne den Kontext u.a. im Auge zu halten. Natürlich MUSS ein großes Projekt sauber geplant sein und die Architekturvorgaben müssen eingehalten werden. Auch andere Konventionen etc. spielen dann eine große Rolle.
Aber machen wir uns nix vor: Für ein kleines Ding, dass nebenher gelöst werden muss - damit es läuft und man keinen Doktortitel (ob mit oder ohne KGT sei mal dahingestellt) dafür braucht, da reicht auch der kleine Hack.
Und als Anstoss für jemanden, der sowieso neu in der Materie erst recht.

Jedenfalls ist das meine Meinung.

Und nach als Randbemerkung: ich habe interessante Einblicke in die Auto-Steuerungstechnik bzw. die Entwicklung derselben bei Audi erhalten. Und danach wunderte ich mich doch sehr, dass überhaupt ein Audi je am Ziel ankommt! Ich sag nur "Produkt reift beim Kunden." Und das gilt nicht nur für Audi! Die Elektronikprobleme des Alfas eines Bekannten sind in meinem Bekanntenkreis schon legendär!
:)

Insofern: die Realität (=deadline) holt doch auch den ausgebufftesten Programmierer ein! Wissen wir doch alle. Also wieso soviel Wind wegen einem kleinen Hack, der doch nur als Startschuss dienen sollte? Und eben als einfache Lösung?

Liebe Grüße
ahds
 
ahds schrieb:
Für ein kleines Ding, dass nebenher gelöst werden muss - damit es läuft und man keinen Doktortitel (ob mit oder ohne KGT sei mal dahingestellt) dafür braucht, da reicht auch der kleine Hack.
Warum sollte man privat weniger hohe Ansprüche an sich selbst stellen als beruflich? Gerade da geht es doch an den eigenen Geldbeutel, wenn man etwas in Grund und Boden fährt.

ahds schrieb:
Und als Anstoss für jemanden, der sowieso neu in der Materie erst recht.
Der Anstoss gibt oft auch eine Richtung vor, und die sollte schon stimmen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja also wir kennen uns ja alle nicht - und ich sowieso niemanden, wo ich doch recht neu in diesem Forum bin. Auch musst Du was mich betrifft nichts hoffen oder Dich bangen. ;)

Meine Bedenken hatten eigentlich nichts direkt mit dir zu tun.
Ich dachte eher an die betroffenen Kunden.


Aber machen wir uns nix vor: Für ein kleines Ding, dass nebenher gelöst werden muss - damit es läuft und man keinen Doktortitel (ob mit oder ohne KGT sei mal dahingestellt) dafür braucht, da reicht auch der kleine Hack.
Und als Anstoss für jemanden, der sowieso neu in der Materie erst recht.

Jedenfalls ist das meine Meinung.

Wenn du gelesen hast, möchte hier nicht jemand einen "Hack" mal eben machen, sondern das Programmieren lernen. Und da ist genug Zeit um es gleich und richtig zu machen.


Und nach als Randbemerkung: ich habe interessante Einblicke in die Auto-Steuerungstechnik bzw. die Entwicklung derselben bei Audi erhalten.

Insofern: die Realität (=deadline) holt doch auch den ausgebufftesten Programmierer ein! Wissen wir doch alle. Also wieso soviel Wind wegen einem kleinen Hack, der doch nur als Startschuss dienen sollte? Und eben als einfache Lösung?

Wenn es andere falsch machen, muss ich es auch falsch machen?
Nur wenn die Messlatte hoch liegt und man die überqueren muss, kommt Qualität heraus.


bike
 
Wenn es andere falsch machen, muss ich es auch falsch machen?

Im Grunde stimme ich Dir doch durchweg zu.

Ich habe nur meine persönliche Situation gesehen und mich an meine eigenen Erfahrungen eben mit Elfenbeinturm-Anspruchsdenken in unserem Betrieb (von mir und anderen) nochmal vor Augen gehalten - und an die Konsequenzen gedacht. Und so kam mein Kommentar zustande.

Insofern bitte nichts für ungut und
liebe Grüße,
ahds

PS: Ich finde aber Diskussionen über SPS-Programmieren bzw. über Programmorganisation usw. grundsätzlich schon sehr interessant - eben weil ich "neu" in dieser Domäne bin.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich hatte die letzten tage keine Zeit in Forum zu gehen und habe eben noch mal aufholend nachgelesen....

Wenn ich das alles richtig verstanden haben, geht es zusammenfassend darum:

Das Programm sieht keine Aktionen auf nicht berücksichtigte und ungeklährte Zustände vor. Diese könne man zwar einbauen aber dafür wären die IF THEN ELSE dann zu unübersichtlich?

Scheinbar geht es auch primär um den Startschuss - oder?

Ist das so richtig?

Mal abgesehen davon, dass ich mir den eventuell in Frage kommenden (nicht berücksichtigten) Zuständen selbst bewusst werden muss, was wäre denn da eine gute alternaive von der Programmierung her?

Die beschriebene CASE ?

Darf ich mich in der CASE neben den festen Werter eigenlich auch solches beziehen?

CASE iBetriebsart OF
T1<100 AND T2<100: (* Init *)
usw...

END_CASE
oder muss ich diese "Nenner vorher setzen und diese dann gezielt abfragen?

Dazu erst einmal Danke!

Zum Schuss noch mal eins... Dante hat mich bei der Übermittlund darauf hin gewiesen, das auf Grund fehlender Informationen Schutzmechanissmen nicht berücksichtigt wurde. z.B. Pumpentrockenlauf usw. Das ganze ging wie anfangs gesagt auch erst einmal nur um das Verständnis. Im gesamten hat mir der gesamte Beitrag dann schlussendlich viel gelehrt.

Gruß aus Hamburg...
 
Darf ich mich in der CASE neben den festen Werter eigenlich auch solches beziehen?

CASE iBetriebsart OF
T1<100 AND T2<100: (* Init *)
usw...

END_CASE

Nein, als CASE-Selektoren können nur konstante Werte dienen. Also z. B. so
Code:
CASE iBetriebsart OF
   0: (*Aus*)
   1: (*Init*)
   2: (*Betrieb*)
END_CASE;
oder besser so
Code:
VAR CONSTANT
BaAus:BYTE:=0;
BaInit:BYTE:=1;
BaBetrieb:BYTE:=2;
END_VAR

CASE iBetriebsart OF
   BAAus:
   BAInit:
   BABetrieb:
END_CASE;
Vor der CASE-Anweisung musst Du einen der Werte an iBetrieb zuweisen, und zwar so, dass iBetrieb auf jeden Fall =BAAus wird, wenn weder die Bedingung für BAInit noch die für BABetrieb gegeben ist.

Und noch etwas zum Startschuss. Ich gebe zu, dass ich das Programm zunächst nur kurz überflogen habe. Und als dann der Begriff "Schmiedehammer" eingeworfen wurde, habe ich gedacht, dass es vorrangig um den verschwenderischen Einsatz von IF THEN ELSE ginge.
Mittlerweile habe ich mir das Programm etwas genauer angeschaut und kann den teilweise scharfen Ton der Kritik schon verstehen.
Nimm z. B. dies hier
IF nTank_1<100 AND nTank_2<100 AND F_TRIG_Filterung.Q=FALSE AND bBetrieb=FALSE THEN bInit=TRUE;
Wozu dient das "AND F_TRIG_Filterung.Q=False"? Doch wohl dazu, einen zweiten Init-Anlauf zu verhindern. Aber wieso funktioniert das? F_TRIG_Filterung.Q ist doch der Ausgang eines Flankenerkennungs-FB's, der eigentlich nur für einen Zyklus True sein sollte. Weisst Du es? Und wenn ja, hältst Du es für eine saubere Lösung?
 
Zuletzt bearbeitet:
Und noch etwas zum Startschuss. Ich gebe zu, dass ich das Programm zunächst nur kurz überflogen habe. Und als dann der Begriff "Schmiedehammer" eingeworfen wurde, habe ich gedacht, dass es vorrangig um den verschwenderischen Einsatz von IF THEN ELSE ginge.
Mittlerweile habe ich mir das Programm etwas genauer angeschaut und kann den teilweise scharfen Ton der Kritik schon verstehen.

Den Schmidehammer habe ich "eingeworfen"
Grund hierfür war:
ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen. Sowas geht in der Regel schief. KOP und FUP sind hier - meines Erachtens - weniger kritisch, da hier Programme meist verknüfungsorientiert porgrammiert werden. Die meisten ST/SCL-Programme sine eher ereignisorientiert. Oder einfach gesagt: Bei KOP / FUP steht der Ausgang im Vordergrund, bei ST/SCL der Eingang.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen. Sowas geht in der Regel schief. KOP und FUP sind hier - meines Erachtens - weniger kritisch, da hier Programme meist verknüfungsorientiert porgrammiert werden. Die meisten ST/SCL-Programme sine eher ereignisorientiert. Oder einfach gesagt: Bei KOP / FUP steht der Ausgang im Vordergrund, bei ST/SCL der Eingang.
*ACK*

Vor meinen ersten Automations-Gehversuchen in Pascal habe ich jahrelang mit Schleicher-P02-Steuerungen gearbeitet. Die liessen sich nur in KOP programmieren und kannten noch nicht einmal R/S-Befehle. Ohne diesen Hintergrund würde ich meinem Nick wohl nicht nur bei Spass-Denkaufgaben nach dem Motto "Wer präsentiert die abgedrehteste Lösung" gerecht werden.
 
Mittlerweile habe ich mir das Programm etwas genauer angeschaut und kann den teilweise scharfen Ton der Kritik schon verstehen.

Du siehst es so wie andere hier.
Besser nichts schreiben als falsch.

Und zu Kop mal der Hinweis, nicht nur du hast solche hochtechnischen PLC programmieren dürfen.
Doch gibt es zwischen KOP und ST noch verschiedenes, das für ANfänger sinnvoll ist.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen.

Gäbe es einen "100% No-Ack", den würd ich jetzt drücken. ;)

Mit derselben Einstellung hätte die PC-Programmierung nie die Assembler-Schmuddelecke verlassen und hoch-effiziente Compiler hätten nie das Licht der Welt entdeckt. Auch interpretierte Sprachen (Java, C#, Python, ...) die auf all diesen Technologien aufsetzen, wären heute nicht in der Werkzeugkiste.

Meine Meinung also: Es geht alles in allem doch nur um SPS-Programmierung. Zu fordern, dass man erstmal "Hardware-nah" sich die Finger wund tippen muss, um zwei alberne Eingänge miteinander zu vergleichen nur "um ein Gespür für eine SPS zu bekommen", der macht sich doch ein wenig lächerlich. Sorry, ist ja nicht persönlich gemeint.

ST und Konsorten sind ja doch wohl (auch) da, um all das zu vereinfachen und eben Programmierer aus anderen Domänen (wie mich) schneller und leichter in die SPS-Welt produktiv einzuführen.

Und das ist auch gut so. Oder? :)

liebe Grüße,
ahds
 
Mit derselben Einstellung hätte die PC-Programmierung nie die Assembler-Schmuddelecke verlassen und hoch-effiziente Compiler hätten nie das Licht der Welt entdeckt. Auch interpretierte Sprachen (Java, C#, Python, ...) die auf all diesen Technologien aufsetzen, wären heute nicht in der Werkzeugkiste.

Meine Meinung also: Es geht alles in allem doch nur um SPS-Programmierung.

Deine Argumentation ist schlichtweg nur polemenisch und realitätsfremd.
Programmiersprachen sind Werkzeuge. Nicht mehr und nicht weniger.
Die Aufgabe bestimmt die Wahl des Werkzeuges. Du kannst deinen Garten mit einem Kaffeelöffel umgraben und deine Torte mit einem Spaten essen. Beides wird funktionieren und zum Ziel führen. Nur unter welchem Umständen?

Auch wenn es deiner Meinung nach "nur um SPS-Programmierung" geht, dann sollte man vielleicht nicht vergessen, dass so manches Menschenleben von der Sorgfalt des SPS-Programmierers abhängt (Stichwort: Sicherheits-SPS).

Dieter
 
Deine Argumentation ist schlichtweg nur polemenisch und realitätsfremd.
Programmiersprachen sind Werkzeuge. Nicht mehr und nicht weniger.
Die Aufgabe bestimmt die Wahl des Werkzeuges. Du kannst deinen Garten mit einem Kaffeelöffel umgraben und deine Torte mit einem Spaten essen. Beides wird funktionieren und zum Ziel führen. Nur unter welchem Umständen?

Auch wenn es deiner Meinung nach "nur um SPS-Programmierung" geht, dann sollte man vielleicht nicht vergessen, dass so manches Menschenleben von der Sorgfalt des SPS-Programmierers abhängt (Stichwort: Sicherheits-SPS).

Dieter

Ich gebe dir vollkomen recht, nicht umsonst werden Sicherheits SPS 'en wie
Siemens nur in FUP oder KOP programmiert. Für jede Art das richtige Werkzeug,
für einfache Verknüpfungen sind die altbewährten Sprachen FUP, KOP und
natürlich AWL das richtige Werkzeug, alles andere macht einfach keinen Sinn.

Aber das mit den Spaten für den Kuchen werde ich morgen beim Sonntags-
Kaffee ersteinmal versuchen, ich glaube da werde ich um einiges effizienter :ROFLMAO:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ST / SCL halte generell nicht für Anfänger geeignet. Man sollte sich erstmal mit der Arbeitsweise einer SPS vertraut machen und nicht versuchen einfach PC-Programmierung auf die SPS zu übertragen.
Gäbe es einen "100% No-Ack", den würd ich jetzt drücken. ;)
Das zeigt mir, daß Du anscheinend auch zu der Sorte Programmierer gehörst, die (noch) nicht begriffen haben, daß SPS völlig anders als PC programmiert werden müssen.
Die Betonung in der Aussage von Blockmove liegt in "sich erstmal in der Arbeitsweise einer SPS vertraut machen" - siehe die danach folgenden Sätze, die Du nicht zitiert hast.
Für den kompletten Beitrag von Blockmove gibt es meine volle *ACK*.

Meine Meinung also: Es geht alles in allem doch nur um SPS-Programmierung. Zu fordern, dass man erstmal "Hardware-nah" sich die Finger wund tippen muss, um zwei alberne Eingänge miteinander zu vergleichen nur "um ein Gespür für eine SPS zu bekommen", der macht sich doch ein wenig lächerlich. Sorry, ist ja nicht persönlich gemeint.
Es geht nicht "nur" um SPS-Programmierung, sondern um die Programmierung von Maschinen und Anlagen, die bei solchen undurchdachten Programmen, wie sie mit ST und Konsorten leicht möglich sind, immerhin einigen materiellen Schaden und gesundheitliche Beinträchtigungen bis hin zum Tod von Menschen anrichten können. Deshalb sind SPS anders konstruiert und arbeiten anders als z.B. Windows-PC. Und deshalb kann man die überwiegend ereignisorientierte (und unzuverlässige!) Programmierweise aus der PC-Welt nicht in die SPS-Welt übertragen. Eine SPS ist eine Zustandsmaschine, die unter allen Umständen zu einem kontrollierten Schalt-Ergebnis kommen muß. Die speziellen SPS-Programmiersprachen FUP/KOP/AWL wurden nicht erfunden, damit man sich "die Finger wund" tippt (und Hardware-nah würde ich die auch nicht bezeichnen), sondern damit man einfach übersichtliche und zuverlässige logische Verknüfungen erstellen kann. Wie immer gilt: Für jede Aufgabe soll man das richtige Werkzeug benutzen. ST ist für mich NICHT das richtige Werkzeug um logische Verknüpfungen zu programmieren.

ST und Konsorten sind ja doch wohl (auch) da, um all das zu vereinfachen und eben Programmierer aus anderen Domänen (wie mich) schneller und leichter in die SPS-Welt produktiv einzuführen.
Klar ist ST auch dazu da, das Programmieren zu vereinfachen, ABER: nicht losprogrammieren ohne die Technik und die Prozesse zu verstehen!

Harald
 
Ich kann auch nicht erkennen das Mann sich an AWL die finger wund
Programmieren soll.
Code:
U(
O #Start
O #Antrieb
)
U #Eingang_1
U #Eingang_2
U #Eingang_3
UN #Stop
= #Antrieb

so kleine Konstrukte lassen sich doch schnell runter tippen und später
wunderbar warten.

Habe ich aber solche Lösungen wie hier heute von Thomas_V2.1 erstellt,
ziehe ich die eindeutig vor, obwohl ich es in AWL programmiert hätte, weil
leider in SCL nicht so fit bin.

Code:
FUNCTION FC2000 : VOID

VAR_INPUT
    DATA: ARRAY[1..50] OF INT;
END_VAR

VAR_IN_OUT
    OUT1 : ARRAY[1..100] OF BOOL;
END_VAR

VAR_TEMP
    i : INT;
    x : INT;
END_VAR

BEGIN
    // Ausgangsarray initialisieren
    FOR i := 1 TO 100 DO
        OUT1[i] := false;
    FOR i := 1 TO 50 DO
        x := DATA[i];
        IF x >= 1 AND x <= 100 THEN
            OUT1[x] := true;
        END_IF;
    END_FOR;       
    
END_FUNCTION
 
Ich kann auch nicht erkennen das Mann sich an AWL die finger wund
Programmieren soll.
Code:
U(
O #Start
O #Antrieb
)
U #Eingang_1
U #Eingang_2
U #Eingang_3
UN #Stop
= #Antrieb
so kleine Konstrukte lassen sich doch schnell runter tippen und später
wunderbar warten.
oh... ist das hässlich. Aber wohl Geschmackssache.
AWL mit Selbsthaltung ist jetzt nicht mein Favorit.

Und zu dem Sicherheitsgelaber von einigen Kollegen hier kann ich echt nur noch den Kopfschütteln. Wenn ich mir die wilde AWL Pointerei, Zugriffe auf Lokaldaten und fehlende Typcast ansehe möchte ich mal darauf hinweisen warum man für ST Pascal als Vorlage gewählt hat:
Heute findet Pascal im universitären Bereich (Entwicklung/Ausbildung) und in sicherheitskritischen Bereichen (z. B. Verkehrstechnik, Energieversorgung, Medizintechnik, Raumfahrt, Militär, teilweise im Banken- und Versicherungswesen) Anwendung. Dies beruht hauptsächlich auf der guten Prüfbarkeit und Wartbarkeit des Codes und der klaren Zuordnung der Variablen. So ist die 2005 eingeführte Betriebsleittechnik IV der Transrapid-Versuchsanlage Emsland in Pascal programmiert.
Quelle: http://de.wikipedia.org/wiki/Pascal_(Programmiersprache)
 
Zurück
Oben