wie gehe ich da ran?

Zuviel Werbung?
-> Hier kostenlos registrieren
bike schrieb:
Wenn ich dich richtig verstanden habe, weißt du zu Beginn schon alle Eventualitäten, die sich bei der Programmierung und Inbetriebnahme ergeben?

Nein, da hast Du mich falsch verstanden. Ich meine, dass es kein guter Stil ist, Zuweisungen auf den selben Ausgang wild auf das gesamte Programm zu verteilen, so wie es auch PN/DP wohl schon öfter hat sehen müssen. Und alle Eventualitäten sehe ich auch nicht voraus, auch wenn sich die Anzahl der "don't cares", die tatsächlich keine sind, im Lauf der Jahre schon verringert.

Was ich ursprünglich zum Ausdruck bringen wollte, ist, dass die "Wenn-dann"-Struktur die Stärke von ST ist und man die auch nutzen sollte. Dass man dabei zu Anfang oft genug das "Sonst" ausser Acht lässt, weiss ich aus eigener Erfahrung nur zu gut. Wenn man lernfähig ist, sollte dieser Drob aber nach der ersten so programmierten Katastrophe gelutscht sein.

Bei einer simplen Aufgabe wie in meinem ursprünglichen Beispiel bevorzuge ich auch die direkte Zuweisung. Dies kann sich aber schon bei einer geringfügigen Änderung der Aufgabe umkehren. Dazu noch ein Beispiel:
Code:
IF Rueckwaerts
THEN
   Ausgabe:= -Sollwert;
ELSE
   Ausgabe:= Sollwert;
END_IF;

Ausgabe:=(1-(BOOL_TO_SINT(Rueckwaerts)*2)*Sollwert;

Ich gebe zu, dem Charme des Einzeilers schon mal erlegen zu sein. Aber jedes Mal, wenn sich ein Kollege erst mal am Kopf kratzt, bekomme ich ein schlechtes Gewissen.
 
Ich will hier nochmal drauf zurückkommen:
Das Programm von Dante zeigt sehr gut, wie sich die Denkweise beim Programmieren mit ST langsam aber sicher zum "Wenn-Dann" entwickelt. Und sobald auch nur ein wenig speichernde Logik hinzukommt, ist das in meinen Augen auch besser verständlich.
Sicher kann man mit IF...THEN...ELSE auch gute Programme schreiben, die wie mit FUP/KOP funktionieren. Mir gefällt diese Entwicklung zum Wenn-Dann aber nicht, gerade wegen der einfachen und verständlichen Formulierbarkeit (das begreift fast jeder Depp). Auch dafür ist das Programm von Dante ein gutes Beispiel: schnell was hingetippt, was auf den ersten Blick das tut, was es soll - doch wehe das Programm wird aus der Testumgebung in das reale Umfeld entlassen, mit Bedingungen, die der Programmierer nicht vorhergesehen hat.
Habs ihm schon komplett geschrieben :D

Hier die exportierte Version: (mit seinen Angaben gemacht ohne Sicherheit das die Pumpen trocken laufen oder so)
Typisch sind "schon", "komplett" und dann doch noch Einschränkungen für die reale Verwendbarkeit.

Das zeigt doch, das die Aufgabe nicht mehr zuerst durchdacht wird (*), sondern sofort losprogrammiert wird und dann mal sehen, was es tut. Die paar Macken, die beim ersten Test auffallen, sind doch schnell mit weiteren Wenn-Dann umschifft!

Das dumme an dieser Wenn-Dann-Denke ist: sie verführt unheimlich dazu, Ereignis-orientiert ("vom Eingang zu den Ausgängen") zu programmieren und möglichst alle Reaktionen inklusive aller zu schaltender Ausgänge sofort in den Dann-Zweig zu legen. Das Bilden von Zwischenmerkern und anschließendes Verknüpfen zu einer Ausgangszuweisung ist vielen Programmierern scheinbar unbekannt oder sie meinen, diesen "überflüssigen" zusätzlichen Aufwand könne man sich sparen.

Vielleicht habe ich vorhin StructuredTrash falsch verstanden, vieleicht meinte er mit "speichernde Logik" solche Zwischenmerker?

(*) Apropos vorher durchdenken: da hat Question_mark letztens was schön formuliert.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das dumme an dieser Wenn-Dann-Denke ist: sie verführt unheimlich dazu, Ereignis-orientiert ("vom Eingang zu den Ausgängen") zu programmieren

Ich glaube, dass das die Wurzel allen Übels ist.
Ereignis-Steuerung im Vergleich zu Verknüpfungssteuerung.
Was bei Windows-Programmierung gut ist, muss noch lange nicht für Automatisierung taugen.

Gruß
Dieter
 
Ich glaube, dass das die Wurzel allen Übels ist.
Ereignis-Steuerung im Vergleich zu Verknüpfungssteuerung.
Was bei Windows-Programmierung gut ist, muss noch lange nicht für Automatisierung taugen.

Gruß
Dieter

Wobei ich bis heute noch? nicht überzeugt bin, ob das bei Windows der richtige erfolgreiche Weg ist.
Doch die Hochsprachen erlauben eben dies und was funktioniert wird irgendwie genutzt.


bike
 
PN/DP schrieb:
Mir gefällt diese Entwicklung zum Wenn-Dann aber nicht, gerade wegen der einfachen und verständlichen Formulierbarkeit (das begreift fast jeder Depp).
Ich finde auch als Nicht-Depp Gefallen an gut Verständlichem.

PN/DP schrieb:
Vielleicht habe ich vorhin StructuredTrash falsch verstanden, vieleicht meinte er mit "speichernde Logik" solche Zwischenmerker?
Nein, ich meine damit das, was man allgemein darunter versteht. Logik, bei der nicht jedem Eingangszustand ein eindeutiger Ausgangszustand zugeordnet ist.


Blockmove schrieb:
Ich glaube, dass das die Wurzel allen Übels ist.
Ereignis-Steuerung im Vergleich zu Verknüpfungssteuerung.
Für die Wurzel allen Übels halte ich eher dies:
PN/DP schrieb:
Das zeigt doch, das die Aufgabe nicht mehr zuerst durchdacht wird (*), sondern sofort losprogrammiert wird und dann mal sehen, was es tut.
Davor bietet aber auch eine Verknüpfungssteuerung keinen wirksamen Schutz. Zugegeben, es ist dabei schwieriger, bestimmte Zustände bei der Programmierung unberücksichtigt zu lassen. Dafür besteht die Gefahr, dass Monster-Netzwerke entstehen, bei denen man die Funktion im normalen Betrieb vor lauter Verriegelungen kaum noch erkennt. Die Verwendung von Zwischenmerkern, wie sie PN/DP nennt, scheint da tatsächlich weitgehend unbekannt zu sein.
Es gibt eben bei jeder Programmierweise gute und böse Programmierer.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich konnte ja nur das Programmieren was ich an I/O hatte und mir an Funktion gegeben wurde. Ich denke für seinen Code dort war Wenn / Dann total okay!

In vielen Beckhoff Bausteinen wird mit Case der Programmcode realisiert. Auch hier werden alle möglichen Variablen gesetzt / rückgesetzt.

Bei der Wenn / Dann programmierung muss man halt sehen das ALLE Zustandsfälle ausgenutzt werden. Ich sehe selbst nicht das große Problem, da er mal locker noch seine Trockenlaufschalter oder Hysteresen einbauen kann. Zu kompliziert würde ich es auch net angehen und ich habe Kommentare geschrieben das auch ein Neuling sich zurechtfindet.

@PN/DP

Du kannst gerne die 2 seitige PDF bekommen und codest es besser, wenn du damit fertig bist kannst du auch gerne meinen Code kritisieren. Einfach mal den Ball flach halten und es besser machen. Es gibt gerade bei der Programmierung 1000 Wege zum Ziel.
 
Ich konnte ja nur das Programmieren was ich an I/O hatte und mir an Funktion gegeben wurde. Ich denke für seinen Code dort war Wenn / Dann total okay!

Vielleicht solltest du zuerst genauer nachdenken und nachfragen.
So ein Bruchstück schreibe ich dir wenn in meiner Kneipe auf das nexte Bier warte.
Aber! ich stell so etwas nie ins Netz.


@PN/DP

Du kannst gerne die 2 seitige PDF bekommen und codest es besser, wenn du damit fertig bist kannst du auch gerne meinen Code kritisieren. Einfach mal den Ball flach halten und es besser machen. Es gibt gerade bei der Programmierung 1000 Wege zum Ziel.

Wenn ich jetzt recht gelesen habe, bist du der Überzeugung, dass dein Code gut und richtig ist und alle möglichen Abbruch- und Ausnahmesituationen berücksichtigt werden?


bike


P.S: Ich hoffe du schreibst so nicht für uns.
 
Bei der Wenn / Dann programmierung muss man halt sehen das ALLE Zustandsfälle ausgenutzt werden. Ich sehe selbst nicht das große Problem, da er mal locker noch seine Trockenlaufschalter oder Hysteresen einbauen kann.

Vernünftige Programme entstehen nur, wenn man von der Automaten- bzw. Zustandstheorie ausgeht.

Dieses --- nah de müssen wir eben noch ein UN( O.. O ) U (..) dazuhäcken und schon passt das - ist Müll.

Wie schnell haut einem der Herr Karnough (kennste den :ROFLMAO:) die Füße weg.

Spätestens wenn man eine Teilfunktion stilllegen (auskommentieren) muß - mal eben kurz :rolleyes: - dann kracht es, weil man etwas nicht bedacht hat.

Nene, EINDEUTIGE Zustände definieren - auch für sowass "scheinbar" (nicht "anscheinend") simples wie eine Pumpensteuerung.

Wenn man klar Zustände hat, kann man diese Zustände auch klar benennen
und ggf. auch den passenden - dem Zustand entsprechenden - Text in das Faceplate einblenden.

Wenn man nicht in der Lage ist das Zustandsdiagramm zu zeichnen, dann sollte
man lieber erst garnicht programmieren.
Leider habe ich schon extremen Pfusch gesehen, daher bin ich in meinem
Auffassung ggf. etwas sehr prägnant.

Frank
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So ein Bruchstück schreibe ich dir wenn in meiner Kneipe auf das nexte Bier warte.
Aber! ich stell so etwas nie ins Netz.

Wenn ich jetzt recht gelesen habe, bist du der Überzeugung, dass dein Code gut und richtig ist und alle möglichen Abbruch- und Ausnahmesituationen berücksichtigt werden?


bike


P.S: Ich hoffe du schreibst so nicht für uns.

Darf ich mal fragen warum Du so agressiv argumentierst? Bis jetzt nörgelt Ihr alle nur rum und meint ihr könnt es besser, Dante ist aber der einzige der sich mal ne Stunde zeit genommen hat und mir als einziger zu meiner Frage und zu meien ersten Schritten in ST weitergeholfen hat. Auch wenn er mir damit vielleicht nicht den Diamanten präsentiert hat, ist voll ok. Den hätt ich wohl für den Anfang auch nicht verstanden.
 
Darf ich mal fragen warum Du so agressiv argumentierst? Bis jetzt nörgelt Ihr alle nur rum und meint ihr könnt es besser, Dante ist aber der einzige der sich mal ne Stunde zeit genommen hat und mir als einziger zu meiner Frage und zu meien ersten Schritten in ST weitergeholfen hat.

Vielleicht mag es daran liegen, dass wir uns in der Praxis zu oft mit Programmen dieser Art "vergnügen" dürfen.

Dieter
 
Darf ich mal fragen warum Du so agressiv argumentierst? Bis jetzt nörgelt Ihr alle nur rum und meint ihr könnt es besser, Dante ist aber der einzige der sich mal ne Stunde zeit genommen hat und mir als einziger zu meiner Frage und zu meien ersten Schritten in ST weitergeholfen hat. Auch wenn er mir damit vielleicht nicht den Diamanten präsentiert hat, ist voll ok. Den hätt ich wohl für den Anfang auch nicht verstanden.

Weil wir, wie Blockmove richtig schreibt, zu oft mit solchen Ergüssen beglückt werden.
Deine Anschauung in aller Ehre, doch besser nichts bekommen, als etwas falsches.
Wenn du dir etwas falsch angewöhnt hast und es mit Glück vielleicht sogar funktioniert, wirst du weiter in diese Richtung arbeiten und dann?


Daher bin ich der Meinung besser nichts als etwas falsches zu schreiben.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich finde es sehr bedauernd, dass hier immer mehr Personen im Forum unterwegs sind die mehr negative Kommentare geben als Hilfestellung. In diesem Fall hier hat er eine Aufgabenstellung zusammengestellt und diese wurde 1:1 lauffähig umgesetzt. Hier erlauben sich dann Personen ein Urteil die nicht mal die Aufgabe kennen.
Ich bin der, der sich überhaupt mal Zeit nahm und falls ihr eine twincat Schulung besuchen durftet dort wird in St noch viel niedriger begonnen. Warum soll er für seine hobbyanlage Nukularrichtlinien befolgen? Urteil darf sich nur wer erlauben der sich auch die Aufgabe angeschaut hat. Hier geht der konsens des Forums leider zugrunde. Wiewar das mit dem wissen das geteilt wird? Ich sehe keine andere Lösung oder gar einen Ansatz hier. Ganz einfach ... Aufgabe angucken und damit was besseres machen.
 
Ich gebe den anderen recht. Man sollte nicht los programmieren in der Hoffnung das man alle Fehlerzustände ausmerzt. Deshalb verdienen auch andere Firmen damit ihr Geld und das zurecht. Der Kunde sagt was er haben will und die Firma "konstruiert" das Programm. D.h. das sie sich auch vorher Gedanken machen, welche Fehler auftreten könnten und wie man das Programm am sinnvollsten schreibt. Da es sogar durch die Programmierung zu nicht vorhersehbaren Fehlern kommen kann. Vielleicht sagt dir ein KV-Diagramm was?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Grundsatzdebatte...

Ich, als nicht-Voll-Profi verfolge die Diskussion hier mit etwas gemischten Gefühlen, und möchte ein paar Punkte in die Runde werfen:

  • Was ist wirklich richtig/falsch, was ist Ansichtssache, und wer entscheidet das? (auch Profs können sich mal irren)
  • Wie habt Ihr begonnen zu programmieren? - Viele jüngere Leute (inkl. ich) lernen mit der Try-and-Error Methode, d.h. ausprobieren, versuchen, auf die Fresse fliegen, nachfragen (z.B hier), besser machen, etwas gelernt haben!
  • Für eine kleine Gartenteich-Steuerung denke ich reicht dieses Vorgehen aus. Hätte er eine profesionelle Lösung gesucht, wäre er zu einem Ingenieur-Büro gegangen. Dies schliesst Sicherheitsbedenken und gut gemeinte Ratschläge natürlich nicht aus!
  • Wenn nur noch die Profis hier Wissen vermitteln möchten, müssten ja auch immer dieselben antworten. :) - Ich denke, es gibt genug hochstehende Fragen, wo sich die Profis voll auslassen dürfen.
  • Was herrscht hier für eine Lernkultur: Darf man beim Lernen Fehler machen? - Darf man dumme Fragen stellen? - Lernen durch lehren kann sehr interessant sein, auch wenn nicht 100% alles stimmt, ist dies oft eine Win-Win Situation!
Kleine Anekdote:

  • Als Ihr in der Schule zu dividieren begonnen habt, hat die Lehrerin sicherlich mit 12 Äpfel durch 6 Schüler, nicht gerade mit dem Satz von l'Hôpital begonnen... (Div/0)
Fazit:

  • Für einfache und Anfängerfragen reichen doch einfache Code-Beispiele aus. Wenn der Fragesteller interessiert ist, werden danach laufen Nachfolge-Fragen kommen. Besser er versteht was er macht, als er macht scheinbar alles richtig, versteht aber sein Code garnicht....
P.S: Die ist als kleiner Denkanstoss gedacht, möchte mir nicht erlauben, hier jemand direkt zu kritisieren!
 
Da hast du absolut recht.
Wenn jemand ein Problem hat, es versucht zu lösen und dann sich Hilfe holt ist das absolut richtig.
Doch wenn jemand anderes ein Programm schreibt, hier publiziert und es dann nicht abkann, wenn Einwände, die auf Problem dieser Art zu programmieren hinweisen, kommen, dann ist dies ebenfalls richtig und wichtig.
Es gibt keine allgemeingültige Art zu programmieren, jedoch sollten gewisse Regeln beachtet werden.


bike
 
Ich, als nicht-Voll-Profi verfolge die Diskussion hier mit etwas gemischten Gefühlen, und möchte ein paar Punkte in die Runde werfen:

Um auch mal so ein hübsches Bild zu nutzen: *ACK*

Ich finde Elfenbeinturm-Denken gefährlicher als ein kleines, dreckiges Programm das ein Problem löst.

Aber was mich am meisten interessiert: wo ist der wirkliche Kritikpunkt?
Die Sprache ST generell?
Das vllt nicht ganz "nach Geschmack" aufgezogene Zustands-Handling? (Ich hätte es ja auch anders gemacht... Aber das ist doch egal!)

Neugierig und viele Grüße,
ahds
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich finde Elfenbeinturm-Denken gefährlicher als ein kleines, dreckiges Programm das ein Problem löst.

Ich hoffe mal nicht das dein 5er BMW nicht auch "dreckig" programmiert ist.

Diese kleinen dreckigen Programme holen dich, oder deinen Nachfolger irgendwann ein.

Ich habe heute wieder mal so ein dreckiges Programm ändern müssen:

- Merker ohne Symbolik

- L DB7.DBD38 obwohl im Ziel-DB an dieser Stelle 2 Worte definiert waren (das es dadurch nicht symbolisch dargestellt war, muss ich hoffentlich nicht weiter erwähnen)

- Datenbausteine ohne Symbolik (gut bei CFC ist das normal aber sonst nicht)

- ...

- keine Sicherungen hinterm Netzteil (ok. das ist Hardware)

usw.

Ich kann dieses Selbstgefällige - Quick und Dirty -Gerede einfach nicht mehr hören.

Was meinst du, wenn du ein Festpreisangebot machen muss und dann geht es los und du musst erst mal mühsam den Mist glattziehen - dann möchte ich dich sehen was du dann sagst.

Frank
 
Ich finde Elfenbeinturm-Denken gefährlicher als ein kleines, dreckiges Programm das ein Problem löst.


Ich hoffe, dass du kein Programmierer bist.
Mal eben quick and dirty ein Programm basteln und dann verschwinden.
Der Lackierte ist der Kunde.
Ich mache lieber ein paar Änderungen, auch wenn diese nicht im Angebot sind.
Daher kann ich auch später meinen Kunden ins Gesicht sehen.
Bisher hatte ich noch nie Probleme so wegen Anwalt oder so.

Es geht nicht um ST. Ich verwende SCL und ST auch, doch für jede Aufgabe das richtige Werkzeug, das ist meine Meinung.


bike
 
bike schrieb:
Ich hoffe, dass du kein Programmierer bist.
Mal eben quick and dirty ein Programm basteln und dann verschwinden.
Dem kann man nur zustimmen.

bike schrieb:
Es geht nicht um ST.
Ein wenig hatte ich bislang schon den Eindruck, dass es eher um Glaubensfragen ging, inkl. meiner eigenen Beiträge. Die einzige konkrete Kritik war doch diese hier:
PN/DP schrieb:
Kannst Du auf Anhieb genau sagen, was die Pumpen in Deinem Programm machen, wenn z.B. binit=FALSE und bBetrieb=FALSE oder im anderen Fall binit=TRUE und bBetrieb=TRUE sind? (Sag jetzt nicht, daß beide Fälle in Deinem Programm niemals vorkommen können).
Den Zustand bInit=False und bBetrieb=False kann das Programm nicht verhindern, dazu ist es auf die ordnungsgemässe Funktion der Sensorik angewiesen. Sich darauf zu verlassen, ist schon gefährlich. Ausserdem wird man bei einer Umsetzung der Teichsteuerung diese auch mal ausschalten wollen. Es wäre daher mindestens guter Stil, wenn nicht mehr gewesen, diesen Fall zu berücksichtigen.
bInit=True und bBetrieb=True sind dagegen im Programm verriegelt. Auf eine Reaktion darauf kann man daher wohl verzichten. Schlecht ist aber, dass man sich überhaupt mit dieser Möglichkeit beschäftigen muss. Die eindeutige Speicherung der Betriebsart in einer einzelnen Variablen wäre da besser.
 
Zurück
Oben