RANT: Konstrukte bei denen man sich manchmal fragt

vollmi schrieb:
Ich will nicht auf meinen True und Falsemerker verzichten. :)
Zum Vergrößern anklicken....

Stell dir vor, du hast 6 Modi, wie eine Maschine gefahren werden kann. Du brauchst für jeden Modus einen Merker. Und da jeder Modus auch überall Auswirkungen hat, biste dann jedesmal dabei so etwas zu fabrizieren:

Code: 
IF m1 AND NOT m2 AND NOT m3 AND NOT m4 AND NOT m5 AND NOT m6 THEN
.....
END_IF;
In der Praxis wird die Abfrage der meisten Merker dann aus Bequemlichkeit unterlassen, was eine nette Quelle für Fehler ist:

Code: 
IF m1 AND NOT m3 AND NOT m4 THEN
.....
END_IF;


Das ist in keiner Sprache vernünftig auszudrücken. Richtig nett wird es denn, wenn du einen der Merker zurücksetzen willst. Nach meiner Erfahrung, wird dass dann überall gemacht und dann nach den verschiedensten Regeln.

Ich mache das so

1. Modus festlegen
Code: 
Manuell = 0
Manuell mit Joystick = 1
Auto Vorwärts = 2
Auto Rückwärt = 3
Auto Ausgleich = 4
Auto Ausgleich mit Joystick = 5

2. Dann kann ich einfach eine Variable oder Merker vom Typ Integer festlegen und brauche mir um das Rücksetzen keine Sorgen zu machen, denn es gibt nur eine Stelle an der ich den Modus ändere

Code: 
CASE Modus OF
  0: 
       IF  Geschwindigkeit<1.0 THEN
           Modus = NeuerModus;
  END_IF;
  1: 
 IF  Geschwindigkeit<1.0 THEN
  Modus = NeuerModus;
 END_IF;
und so weiter

END_CASE



3. An Stellen wo es etwas in Abhängigkeit vom Modus zu machen gibt sieht das dann so aus:

Code: 
CASE Modus OF
 0: 
    mach was
 1: 
  mach was
 2: 

END_IF;
oder so aus

Code: 
IF Modus = 0 THEN
...
ELSE
...
END_IF;

4. Wenn man etwas nachdenkt, ist das Verfahren mit dem Joystick nur ein Untermodus. Wenn ich dann die Hauptmodi mit 10 multipliziere, dann sieht das so aus

Manuell = 0
Manuell mit Joystick = 1
Auto = 10
Auto Vorwärts = 11
Auto Rückwärt = 12
Auto Ausgleich = 20
Auto Ausgleich mit Joystick = 21

5. In FB wie einem Regler interessiert mich der Joystick nicht, ebenso nicht, ob es Rückwärts oder Vorwärts geht. Da sieht es denn so aus:

Code: 
CASE modus/10 OF
  0:  (* Manuell *)
     .....
  1: (* Auto *)
   ....
  2: (* Auto Ausgleich *)
    ... 
END_CASE;

Mach das mal mit Merkern ;)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
In CFC hab ich noch nie nen true oder false Merker benötigt, da konfiguriert man an den Bausteineingängen direkt den InstanzDB bzw. erzeugt CFC beim Übersetzen selbst die entsprechende Verschaltung mit 0 oder 1...

Aber irgendwie kommt CFC ja nicht aus seinem Schattendasein heraus bzw. bei TIA hört man davon Garnichts...

Gruß.
 
Es hängt wohl damit zusammen, das FUP und Leiterdiagramme immer noch so populär sind.

Ich selbst, mag grafische Programmiersprachen weniger, weil ich Texte beliebig kopieren kann und ich auch nicht mehr Übersicht habe. Wobei du hast recht, es würde sich lohnen, mal sich CFC anzuschauen.

Und ich muss derzeit mit CX-Programmer von Omron arbeiten. Da gibt es CFC gar nicht. CX-Programmer ist eine grosse Zumutung, weil Omron es fertigbringt, die Regional-Einstellungen für Komma und Punkt etc. in die Umgebung mit einzubinden, so dass ich dann statt 3.14 diese Zahl mit 3,14 schreiben muss. Dummerweise ändert sich der Aufruf von Parameter nicht, so das

RXD_SCU(buffer, 1,1,2,3);

als

RXD_SCU(buffer, (1,1), (2,3))

gelesen wird. So muss ich dann den Aufruf als

RXD_SCU(buffer, (1),(1),(2),(3));

schreiben. Somit sind solche Projekte auch nicht portabel.
 
drfunfrock schrieb:
Ich selbst, mag grafische Programmiersprachen weniger, weil ich Texte beliebig kopieren kann und ich auch nicht mehr Übersicht habe. Wobei du hast recht, es würde sich lohnen, mal sich CFC anzuschauen.
Zum Vergrößern anklicken....

Man schreibt ja nicht alles in CFC. Die Bausteine erstellt man weiterhin in SCL oder AWL... Nur die Verschaltung, Parametrierung und das "Drumherum" mach ich in CFC.
Bei der IBN geht das Beobachten der Instanz bzw. Änderungen viel schneller und einfacher...
Man muss sich auch nicht mehr um die ganzen IDBs kümmern, macht CFC alles selber...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
drfunfrock schrieb:
Stell dir vor, du hast 6 Modi, wie eine Maschine gefahren werden kann. Du brauchst für jeden Modus einen Merker. Und da jeder Modus auch überall Auswirkungen hat, biste dann jedesmal dabei so etwas zu fabrizieren:
Zum Vergrößern anklicken....

Meine True/False Merker nutze ich eigentlich als Konstante um eine Schnittstelle voll zu beschalten oder einen Baustein im Fup aus dem Ablauf zu nehmen etc.
Das hat in dem sinn nichts mit meiner Steuerung ansich zu tun.

Da nutze ich eigentlich genau das Konzept wie du es beschreibst :) Nur gibts bei mir keine 0 im Modus. 0 ist für mich immer Ungültig. Damit will ich vermeiden dass ein Objekt irgend einen scheiss macht wenn jemand einen DB löscht oder ein Initialwert nicht gesetzt ist.

Auch für die Übertragung nehme ich das her. Ein Befehl hat immer einen Wert über 0. Wenn der Wert über null ist, wird das Telegramm gespeichert, gesendet und der Befehl wieder auf 0 zurückgesetzt.

mfG René
 
Ich würde Omron zu dem Übelsten küren, was man sich nur denken kann. Die haben einfach alles den Regionaleinstellungen unterworfen. Der gesamte Kode ist nicht mehr portabel, weil man Zahlen mit Komma schreiben muss, während in den USA natürlich der Punkt gilt. Das hat Konsequenzen. Funktionen und FB mit Komma als Parameterseparator funktionieren nur, wenn man die Zahlen dann in Klammern setzt. Die nächste Überraschung kam dann, als ich mit dem SCADA-System "Supervisor" CSV-Dateien geschrieben hatte, um ein Interface zu anderer Software zu haben und dann auch die Feldtrenner von der Locale gesteuert wurden. Im Prinzip sind alle Konvertierungen nach String von der Locale beeinflusst. Wer es richtig macht, setzt einfach die Locale für PC auf US-Standart fest. Die haben doch einen Schuss weg.

Das ist das Schlimmste was mir bisher begegnet ist.
 
Das Punkt und Komma-Problem ist doch ein Problem von Microsoft.
Wenn ich meine Reisekosten auf einem deutschen PC mache und sie dann nach England schicke, kann der Kollege die ja auch nicht öffnen ohne an seinem PC etwas umzustellen, wenn sie in csv-Format verschickt wird.
 
bugatti66 schrieb:
Das Punkt und Komma-Problem ist doch ein Problem von Microsoft.
Zum Vergrößern anklicken....

... es ist nachher ein Problem vom Programmierer der mit dem Unsinn klarkommen muss.

Eine Reisekostenabrechnung hin gegen führt nicht direkt zum Produktionsausfall es sei denn du kannst
aufgrund nicht bezahlter Rechnungen keine schnelle Maintenance mehr machen,
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir verschicken aber keine SPS-Programme im CSV-Format. und selbst wenn ich eine Quelle eines Bausteins von Deutschland nach China schicke sollte beim Übersetzen wieder was vernünftiges rauskommen.
 
bugatti66 schrieb:
Das Punkt und Komma-Problem ist doch ein Problem von Microsoft.
Zum Vergrößern anklicken....

MS$ baut PLC Steuerungen?
Das ist ja toll, dann haben diese in Zukunft direkt einen Zugang zur NSA und Facebook.

Also diese Argumentation ist doch bei dem Problem, dass man Programme nicht einfach in verschiedenen Sprachumgebungen nutzen kann, einfach völlig daneben.
Aber vermutlich hat Omron noch nie gehört, dass eine Maschine von einem in ein anderes Land umgesetzt wird.


bike
 
bugatti66 schrieb:
Das Punkt und Komma-Problem ist doch ein Problem von Microsoft.
Wenn ich meine Reisekosten auf einem deutschen PC mache und sie dann nach England schicke, kann der Kollege die ja auch nicht öffnen ohne an seinem PC etwas umzustellen, wenn sie in csv-Format verschickt wird.
Zum Vergrößern anklicken....

Komisch, ich habe nie Probleme mit C, C++, VB, Pascal oder Python gehabt, weil dort die Locale nur für die Anwender-Strings angewendet werden. Omron hätte genau den gleichen Schwachsinn unter Linux verbrochen. Ich vermute einmal, die haben sich alles zusammengekauft und dann "schnell" internationalisiert. Und weil Omron-Programmierer aus Japan oder den USA kommen, haben die das Konzept auch nicht richtig verstanden. Nicht einmal Inder können derart dämlich sein.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für jedes Update vom Supervisor (Scada) von Omron, darf ich auch beim Kunden die Runtime updaten, inkl. Reboot usw. Weil ansonsten müssten wir die Entwickler-PC auf dem Stand von Vorgestern halten.
 
ducati schrieb:
Das ist bei Siemens aber auch so (ähnlich)...

Wir haben da für fast jede Kundenanlage ne eigene Entwickler/Test-VM.
Zum Vergrößern anklicken....

Was das Leiden nicht besser macht. ich arbeite viel in Umgebungen, die jede Änderung zu Hölle machen, weil ich teilweise für 30min Änderung 12h und mehr warten muss. Das ist zwar bezahlt aber nicht lustig. Ich will in Zukunft HTML, damit ich genau das nicht mehr habe. Ich muss mir da mal Produkte wie atvise anschauen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
drfunfrock schrieb:
Was das Leiden nicht besser macht. ich arbeite viel in Umgebungen, die jede Änderung zu Hölle machen, weil ich teilweise für 30min Änderung 12h und mehr warten muss. Das ist zwar bezahlt aber nicht lustig. Ich will in Zukunft HTML, damit ich genau das nicht mehr habe. Ich muss mir da mal Produkte wie atvise anschauen.
Zum Vergrößern anklicken....
Jo, wer kennt das nicht... Oft wird aber die Programmierumgebung/Sprache vorgeschrieben... von daher hat man eh keine Wahl...
 
Gestern durfte ich mal wieder spätabends ausrücken. In dem Programm habe ich einen zusätzlichen FB eingebaut. Den FB habe ich von A-Z durchgetestet und funktionierte. Leider funktionierte etwas im Alten teil des Programms dann nicht mehr. Das ganze war in einem FB programmiert. #VK_Auf im TEMP deklariert und wird nirgends zurückgesetzt.

Code: 
      O     #ZK_Auf      
O     "Schaltbefehle von AV"._DBX_22_6
      SPBN  VK01
      S     #VK_Auf
      S     #VK_Oeffnen


VK01: U     #VK_Auf
      FR    T     32
      L     S5T#30S
      SA    T     32
      UN    T     32
      SPBN  VK02
      R     #VK_Oeffnen
VK02: NOP   0

#VK_Oeffnen hat eine Klappe offen gehalten welche eigentlich wieder hätte zeitverzögert schliessen sollen. Nachdem die beiden Startbedingungen weggefallen sind.

Mal abgesehen vom Zugriff auf eine fremde Instanz. Wie kommt man auf die Idee S7 Timer in einem FB mit eigener Instanz einzusetzen? Und dann noch in so einer kruden Konstruktion?

mfG René
 
vollmi schrieb:
Gestern durfte ich mal wieder spätabends ausrücken. In dem Programm habe ich einen zusätzlichen FB eingebaut. Den FB habe ich von A-Z durchgetestet und funktionierte. Leider funktionierte etwas im Alten teil des Programms dann nicht mehr. Das ganze war in einem FB programmiert. #VK_Auf im TEMP deklariert und wird nirgends zurückgesetzt.

Code: 
      O     #ZK_Auf      
O     "Schaltbefehle von AV"._DBX_22_6
      SPBN  VK01
      S     #VK_Auf
      S     #VK_Oeffnen


VK01: U     #VK_Auf
      FR    T     32
      L     S5T#30S
      SA    T     32
      UN    T     32
      SPBN  VK02
      R     #VK_Oeffnen
VK02: NOP   0

#VK_Oeffnen hat eine Klappe offen gehalten welche eigentlich wieder hätte zeitverzögert schliessen sollen. Nachdem die beiden Startbedingungen weggefallen sind.

Mal abgesehen vom Zugriff auf eine fremde Instanz. Wie kommt man auf die Idee S7 Timer in einem FB mit eigener Instanz einzusetzen? Und dann noch in so einer kruden Konstruktion?

mfG René
Zum Vergrößern anklicken....


Da kommt der gute Programmierer mit seinem vorbereiteten Programm auf die Baustelle und muss dann auf die schnelle die Änderungen reinbasteln die seine Kollegen ihm nicht erzählt haben.... da bleibt dann der saubere Programmierstil und das Auskommentieren auf der Strecke.

Ob das in deinem Programm so war kann man schlecht sagen aber bei vielen Programmen ist es so ....
 
Zurück
Oben