Aufrufen vieler Instanzen

[der.saboteur]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe einen FB den ich relativ häufig aufrufen möchte. Eingangs- und Ausgangs-Variablen unterscheiden sich nur durch eine Zahl im Namen. Datentypen können REAL INT oder auch BOOL sein. Hier mal ein Beispiel:

VAR
    e1    : BOOL;
    q1    : BOOL;
....
    e11    : BOOL;
    q11    : BOOL;
    FB1 : FB;
    FB2 : FB;
....
    FB11 : FB;
    
END_VAR

FB1(in := e1, out => q1);
....
FB11(in := e11, out => q11);

Wenn ich das 11 mal mache und auch noch mehrere Variablen hinzukommen, wird das allerhand Code. Da Frage ich mich, ob das nicht kürzer geht. Auch ohne dieser aufwendigen Deklarierung.

Es muss ein FB sein, da ich mit Zeiten arbeite. Außerdem könnte ich einen ARRAY verwenden, das würde aber auchnicht soooo viel ausmachen.

Ich verwende Solution Center 2.50.

Grüße

 

[JSEngineering]

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

11 Instanzen eines FB einzeln aufrufen ist doch kein "allerhand Code" (höchstens für schreibfaule Programmierer). Wenn man das mit Gewalt auf FB-Arrays umstrickt, dann kann da sogar größerer Code bei rauskommen, auf jeden Fall aber langsamerer und undurchsichtigerer Code.

Harald

 

[JSEngineering]

11 Instanzen eines FB einzeln aufrufen ist doch kein "allerhand Code" (höchstens für schreibfaule Programmierer). Wenn man das mit Gewalt auf FB-Arrays umstrickt, dann kann da sogar größerer Code bei rauskommen, auf jeden Fall aber langsamerer und undurchsichtigerer Code.

Harald

Das kommt auf den Anwendungsfall an. Ich bin gerne schreibfaul...
Es gibt Anwendungsfälle, da macht es keinen Sinn, aber wenn man viele gleichartige Aufrufe oder Auswertungen hat, ist das angenehm.
Vor allem wenn dann mal was erweitert werden muß gibt es viel weniger Fehlermöglichkeiten...

 

[ducati]

irgendwo müssen dann aber die Arrays der Ins und Outs auch versorgt werden... also ich schließe mich mal der Meinung von PN/DP an

 

[der.saboteur]

Zuviel Werbung?
-> Hier kostenlos registrieren

momentan habe ich 11x var_input und 28x var_output ...
das bringt mich auf die Idee, ein Array eines eigenen Datentyps zu erzeugen

der Code wird so compiliert, dass die for Aufrufe in einem Zyklus durchgehen, richtig?
wenn bereits Variablen vorliegen, die geich heißen sich aber nur durch eine Zahl unterscheiden, gibt es da auch die Möglichkeit in der Syntax die eine Zahl zu variieren?

zB

    Schalter1oben : BOOL;
    Schalter1unten : BOOL;
...
    Schalter9oben : BOOL;
    Schalter9unten : BOOL;

 

[der.saboteur]

irgendwo müssen dann aber die Arrays der Ins und Outs auch versorgt werden... also ich schließe mich mal der Meinung von PN/DP an

das ist in diesem Fall am Feldbus (bei Bachmann unter Vernetzung)
daher würde ich im Code mit dem von mir zusammengedachten Objekt weiter machen

 

[JSEngineering]

Wenn die I/Os so systematisch liegen, daß sie mit den Indizes in Verbindung gebracht werden können, könntest Du auch eventuell über Mio_GetValue darauf zugreifen.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

irgendwo müssen dann aber die Arrays der Ins und Outs auch versorgt werden... also ich schließe mich mal der Meinung von PN/DP an

Da ich die I/Os in der Regel indirekt adressiere (so lassen sich die Programme leichter auf verschiedene Hardware portieren bzw. der Inbetriebnehmer kann über das HMI die Kanalbelegung ändern), habe ich die eh in einem Array vorliegen. Daher kein Problem. Macht eher das Leben bei der Parametrierung der Software einfacher.

Ich sage ja: Es kommt auf den Anwendungsfall an, wie so viele Diskussionen, die im Rahmen von "Programmierstrategien" geführt werden, nicht klar mit "gut oder schlecht" beschlossen werden können.

 

[Frohnius]

ich habe so etwas auch schon mal gemacht ..
und das mapping der IOs dann eben auf z.b. varInIrgendwas[5] ...
über konstanten habe ich dann meine array-index so definiert, dass es noch gut lesbar bleibt ... varOut[ScheckeBlau2].Qout

nach einigen erweiterungen wurde mir das dann zu unübersichtlich und ich empfand den code als "unsauber" ....
für funktionsblöcke mit wenig i/o mag das sinn machen

ich würde mich aber JSEngineering anschliessen und das weder als gut, noch als schlecht bezeichnen.

 

[PN/DP]

Da ich die I/Os in der Regel indirekt adressiere (so lassen sich die Programme leichter auf verschiedene Hardware portieren bzw. der Inbetriebnehmer kann über das HMI die Kanalbelegung ändern), habe ich die eh in einem Array vorliegen.

Bei vielen Kunden ist sowas nur in Blackbox-Serien-Maschinen zulässig, die ausgereift sein sollten und keine Diagnose durch Programmbeobachtung erfordern. Also an uns könntest Du sowas nicht liefern.
Ein Umverdrahten von E/As ist bei fester indizierter Adressierung in E/A-Arrays nicht möglich, da kann dann z.B. in RUN bei einem defekten Analogeingang nicht auf einen anderen freien/vorbereiteten Analogeingang gewechselt werden.

Daher kein Problem. Macht eher das Leben bei der Parametrierung der Software einfacher.

Ja, sowas kenne ich auch. Da wird bei der IBN erstmal ein Frischling vorgeschickt, der muß nur Handy halten können und am HMI Häkchen setzen und Zahlen eingeben können... und beim nächsten Remanenzverlust sind die ganzen vielen Einstellungen weg...

Ich sage ja: Es kommt auf den Anwendungsfall an, wie so viele Diskussionen, die im Rahmen von "Programmierstrategien" geführt werden, nicht klar mit "gut oder schlecht" beschlossen werden können.

SPS-Programmierer denken immer, Ihre paar Stunden Arbeitszeit wären sooo wertvoll, daß sie da durch irgendwelche tricky Programmierung noch die eine oder andere Stunde einsparen müssten. Wenn beim Kunde wegen unerklärlichem Anlagenstillstand das Programm beobachtet werden muß, und das dauert wegen undurchsichtiger Programmierung eine halbe Stunde länger als bei einem schön einfach linear programmierten Programm, dann kostet das den Kunde oft schon mal eine fünfstellige Summe ... das sind aber die Kosten des Kunde und nicht die Kosten des supertollen Lieferanten-Programmierers.

Harald

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei vielen Kunden ist sowas nur in Blackbox-Serien-Maschinen zulässig, die ausgereift sein sollten und keine Diagnose durch Programmbeobachtung erfordern. Also an uns könntest Du sowas nicht liefern.
Ein Umverdrahten von E/As ist bei fester indizierter Adressierung in E/A-Arrays nicht möglich, da kann dann z.B. in RUN bei einem defekten Analogeingang nicht auf einen anderen freien/vorbereiteten Analogeingang gewechselt werden.


Ja, sowas kenne ich auch. Da wird bei der IBN erstmal ein Frischling vorgeschickt, der muß nur Handy halten können und am HMI Häkchen setzen und Zahlen eingeben können... und beim nächsten Remanenzverlust sind die ganzen vielen Einstellungen weg...


SPS-Programmierer denken immer, Ihre paar Stunden Arbeitszeit wären sooo wertvoll, daß sie da durch irgendwelche tricky Programmierung noch die eine oder andere Stunde einsparen müssten. Wenn beim Kunde wegen unerklärlichem Anlagenstillstand das Programm beobachtet werden muß, und das dauert wegen undurchsichtiger Programmierung eine halbe Stunde länger als bei einem schön einfach linear programmierten Programm, dann kostet das den Kunde oft schon mal eine fünfstellige Summe ... das sind aber die Kosten des Kunde und nicht die Kosten des supertollen Lieferanten-Programmierers.

Harald

Ich programmiere in der Regel keine produktiven Maschinen, dafür aber Anlagen, die der Kunde / Endkunde / Programmierlaie gerne selbst in Betrieb nimmt. Zum einen, weil es schwierig ist, zu den Anlagen jedes Mal einen Programmierer zur Inbetriebnahme zu schicken, zum anderen der Endkunde dafür kein Geld ausgeben möchte. Und in den Fällen ist es schon vielfach hilfreich gewesen, wenn dieser Programmierlaie an der Anlage selbst die E/As ändern konnte. Die Parametrierung findet anhand einer vorbereiteten Excel-Maske statt, so daß bereits bei der Parametrierung Fehler minimiert werden können.
Richtig: Die Anlagen sind vor der Inbetriebnahme durchgetestet, aber auch da sehe ich bei einem vernünftigen Konzept kein Problem. Ich habe schon "lineare" Programme gesehen, die deutlich schwerer zu verstehen waren.
Aber warum sollte ein Umrangieren von E/As im Run nicht möglich sein? Programm guckt im nächsten Zyklus auf einen anderen Eingang... Fertig.
Und warum soll ein Programm mit Arrays schwerer zu debuggen sein?
Ob ich FB_Irgendwas oder FB_Anonym[Irgendwas] öffne zum Beobachten, macht meines Erachtens keinen Unterschied.
Was aber den Unterschied macht: Ob ich 100 Programmzeilen mit gleichem Inhalt hintereinander habe oder 5, weil die Instanzen in einer FOR-Schleife abgearbeitet werden.
Deinen Remanenz-Verluste habe ich noch nicht erlebt - vielleicht auch, weil ich nicht (mehr) so viel mit Siemens arbeite. Bei wichtigen Daten programmiere ich zusätzlich auch Import-Export-Funktionen, so daß man die Einstellungen als CSV wegsichern kann.

Ich kann nur wiederholen: Es kommt auf den Einsatz und natürlich auch den Kunden an. Und wenn der Endkunde selber weiterentwickeln will, gibts eine Dokumentation der Programmierung in schriftlicher Form.

 

[Mrtain]

SPS-Programmierer denken immer, Ihre paar Stunden Arbeitszeit wären sooo wertvoll, daß sie da durch irgendwelche tricky Programmierung noch die eine oder andere Stunde einsparen müssten. Wenn beim Kunde wegen unerklärlichem Anlagenstillstand das Programm beobachtet werden muß, und das dauert wegen undurchsichtiger Programmierung eine halbe Stunde länger als bei einem schön einfach linear programmierten Programm, dann kostet das den Kunde oft schon mal eine fünfstellige Summe ... das sind aber die Kosten des Kunde und nicht die Kosten des supertollen Lieferanten-Programmierers.

Naja, wir bekommen immer von unseren Vertrieblern zu höhren, dass die Softwarekosten zu hoch sind...

 

[ducati]

Naja, wir bekommen immer von unseren Vertrieblern zu höhren, dass die Softwarekosten zu hoch sind...

Ich bekomm von unseren Vertrieblern immer zu hören, dass sie noch mehr und noch mehr Funktionen haben wollen bzw. versprochen haben

oder mal wieder das HMI umgeschmissen haben ...

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das kommt auf den Anwendungsfall an. Ich bin gerne schreibfaul...
Es gibt Anwendungsfälle, da macht es keinen Sinn, aber wenn man viele gleichartige Aufrufe oder Auswertungen hat, ist das angenehm.
Vor allem wenn dann mal was erweitert werden muß gibt es viel weniger Fehlermöglichkeiten...

Bei Solchen Aufgaben ist es oft zielführender die Schreibarbeit z.B. Excel zu übergeben. Da kann man dann schnell ne Tabelle mit ensprechenden Eingängen Text etc machen so mit Runterziehen und so weiter. Und dann den Code entweder als Quelle raus lassen oder direkt per Copy&Paste weiterverarbeiten.

Das senkt die Fehlerquote, Der Code ist immernoch voll bearbeitbar und lässt sich im gegensatz zu nem haufen Schlaufen und Arrayaufrufen einfacher Online beobachten.

"Voll Bearbeitbar" heisst nicht das man unbedingt am Code rumbasteln soll, sondern lieber dann an der Exceltabelle.

Als beispiel. Diesen Baustein rufe ich über 100 mal auf. Den könnte ich jetzt noch an der Schnittstelle optimieren, voll die fancy Programmiererkniffe einfliessen lassen um die Konfiguration automatisch erkennen zu lassen etc.
Und dann mit der FOR Schleife durchlaufen und müsste nix mehr programmieren.
Nur in 10 Jahren verzweifelt jeder der den Code anpassen müsste, oder irgendwo was reinbauen muss. Hier ist die Quelle ein Liste die mir den Code einfach auswirft. Und die Daten lassen sich in der Datenbank wesentlich einfacher verwalten.

    #"FLS-BAS-S1-47002"(Helligkeit := #Helligkeit_Offen,
                        Betriebsart := #Globale_Betriebsart,
                        Line_ID := 1,
                        Signal_ID := 2,
                        AR_override := "Override_DB"."sonstige",
                        config := "DB_Fut_Configuration"."24_VZ",
                        Treiber := "Signale"."Signale-Q47002-BAS"[0],
                        AR_InOut0 := "Signale an VLS-AR"."FLS-BAS-S1-47002",
                        WEB := "Signal_Web"."Sig_Web"[3]);
    
    #"FLS-BAS-S2-47002"(Helligkeit := #Helligkeit_Offen,
                        Betriebsart := #Globale_Betriebsart,
                        Line_ID := 1,
                        Signal_ID := 1,
                        AR_override := "Override_DB"."sonstige",
                        config := "DB_Fut_Configuration"."24_VZ",
                        Treiber := "Signale"."Signale-Q47002-BAS"[1],
                        AR_InOut0 := "Signale an VLS-AR"."FLS-BAS-S2-47002",
                        WEB := "Signal_Web"."Sig_Web"[4]);

FOR Schleifen sparen ja auch keine Zykluszeit, sie sparen nur Tipparbeit und Speicher. Speicher ist mittlerweile extrem billig, das man lieber Gewicht auf Lesbarkeit legen sollte. Tipparbeit ist zwar teuer, aber lässt sich oft umgehen indem man sich z.B. eine Tabellenkalkulation für den Wiederholungsfaktor hernimmt.

 

[JSEngineering]

Wir sind hier wieder in einer Diskussion gelandet, wo zwei Extrempositionen für 100% aller Anwendungsfälle verteidigt werden

Nein: Ich nutze auch nicht immer Funktions-Arrays.
Ja: Ich nutze auch einzelne Instanzaufrufe, wenn es sinnvoll und übersichtlich ist.
Ja: Ich nutze auch gerne und viel Excel, um Code zu automatisieren.

Ich sage nur, daß es solche und solche Anwendungsfälle gibt.
Nur ich habe versucht, auf Post #3 zu antworten, indem Funktions-Arrays m.M. nach pauschal verteufelt werden. Und diese Pauschalisierung sehe ich eben anders.

So, jetzt ist hoffentlich klar, was ich ursprünglich sagen wollte

PS:
Zur Excel-Tabelle muß aber der Vollständigkeit halber auch dazu gesagt werden, daß, so wie Du oben schreibst, die bei Erweiterungen weiter benutzt werden sollen, diese natürlich dem Quellcode beiliegen müssen... Oft genug ist es so, daß natürlich nur der Quellcode gesichert und gepflegt wird.
Fairnesshalber muß man sagen, daß es auch genügend Leute gibt, die nicht mit Excel umgehen können und solche vorbereiteten Tabellen schnell "kaputtoptimieren", wenn es zu Änderungen kommt.

Hat halt alles Vor- und Nachteile...

 

[PN/DP]

FOR Schleifen sparen ja auch keine Zykluszeit, sie sparen nur Tipparbeit und Speicher.

Schlimmer noch: weil in der Schleife alles indirekt adressiert wird, steigt die Programm-Abarbeitungszeit auf das Mehrfache.

Harald

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nur ich habe versucht, auf Post #3 zu antworten, indem Funktions-Arrays m.M. nach pauschal verteufelt werden. Und diese Pauschalisierung sehe ich eben anders.

In #3 werden Funktions-Arrays nicht verteufelt, schon gar nicht pauschal. Sondern nur auf die negativen Folgen hingewiesen.

11 Instanzen eines FB einzeln aufrufen ist doch kein "allerhand Code" (höchstens für schreibfaule Programmierer). Wenn man das mit Gewalt auf FB-Arrays umstrickt, dann kann da sogar größerer Code bei rauskommen, auf jeden Fall aber langsamerer und undurchsichtigerer Code.

Harald

 

[ducati]

11 Instanzen eines FB einzeln aufrufen ist doch kein "allerhand Code" (höchstens für schreibfaule Programmierer).

Zum Thema schreibfaul, es ist ja auch nicht so, dass man den Code 11 mal komplett tippen muss... Strg+C Strg+V sollte eigentlich überall funktionieren.

 

[Frohnius]

Zum Thema schreibfaul, es ist ja auch nicht so, dass man den Code 11 mal komplett tippen muss... Strg+C Strg+V sollte eigentlich überall funktionieren.

richtig ...
und am ende - auch wenn der code länger wird - bleibt es für MICH übersichtlicher ....
jede instanz bekommt dann im code einen //Baustein xzy usw usw ...