Was haltet ihr von solchen Funktionen?

thomasgull

Level-2
Beiträge
172
Reaktionspunkte
3
Schreiben in IDB.png

Was haltet ihr von Programmierschritten die irgendwo bei gewissen Aktionen statische Variablen in Instanzdatenbausteinen verändern?

Nach meiner Meinung ein NO-Go da die Funktion des Bausteins ausser Kontrolle geraten kann.

Thomas
 
Schön isses nicht.

Siemens schreibt bei den Reglern auch gerne in den IDB.

such mal hier nach Instanzdatenbaustein, HMi-Zugriff usw...

Da wurde das bis zum Erbrechen durchgekaut
 
Wenn der Bereich definiert ist oder in di inVariablen kann ich noch nach vollziehen.
Aber variablen die dort gelesen und geschrieben werden kann ich nicht befuerworten da sie instabilitaet bergen.
Auch wurde der baustein nicht dafuer entworfen.
Die Firma versuchte so nur einen Mangel im Baustein zu kitten, anstelle es korrekt im Baustein zu programmieren
 
Ist leider nicht das einzige Flickwerk in der ganzen Software

da werden Und/Oder Verknüpfungen gemacht mit 60 Anweisungen und zig Klammerausdrücken, da kann man unmöglich noch die Funktion erkennen.

Wenn es funktionieren würde da wäre noch das eine aber da bleibt die Anlage ab und zu stehen und nichts geht mehr. Zum "reparieren werden dann noch 3 Zeilen zugefügt.



Da hat es Funktionen drin wie

O Eingang1
O Eingang2
O (
U Eingang1
U Eingang2
)
= Ausgang

nur 60 Anweisungen lang
 
IDB-Zugriffe habe ich früher komplett abgelehnt. Inzwischen (1200+1500) mache sich das schon auch mal, wenn der FB alle seine (eingesammelten) Daten in den IDB schreibt und in sich abgeschlossen ist. (Wie z.Bsp. der FB125/126 Profibus von Siemens das schon immer macht). Ansonsten muß man alle Daten über eine Schnittstelle in einen anderen FB/FC übergeben oder erst nochmals in einen globalen DB auslagern und das geht dann u.U. zu Lasten der Performance und des Arbeitsspeichers, insbesondere, wenn es um große Datensammlungen geht. Auch werden in TIA ja nun immerhin symbolisch adressierte Daten bei evtl. Änderungen automatisch nachgezogen, so dass es zumindest nicht ganz so gefährlich ist, wie bei den 300/400 und Klassik. Aber insgesamt versuche ich Querzugriffe in den statischen Speicher der FB hinein zu vermeiden, ist m.E. kein wirklich guter Programmierstil. Aber wie immer, Ausnahmen bestätigen die Regel. :-)
 
@Ralle
Du meinst auch dass du direkt iVariablen, anstelle von Temporären die die du wiederum am Baustein als In benötigst, oder Lesend sehe ich weniger ein Problem. So wie es du beschreibst ist es ist es aber auch so Designt dass die Daten Direkt verwaltet werden.
Hier wurde es gemacht um Funktionen im Baustein zu ändern die sie selber falsch erstellt haben und dies nicht an einer Stelle sondern zu Duzenden. Die Mängel der Funktionen werden so "Behoben" oder besser gesagt verschoben, denn es treten so ganz andere Fehler auf.
Gefordert waren sauber der Funktion entsprechende Bausteine und übersichtliche Strukturen, so haben wir alles andere als das.

Der Programmierer ist der Ansicht "das ist schon gut so".

Ich habe die Antwort nicht akzeptiert, da das ganze nochmals ähnlich aufgebaut werden soll und er meint ist ja nur Copy Paste. Das ganze überzieht etwa 50 Bausteine an 20-40 Netzwerke. Also alles ander als nur klein und fein.
 
@Ralle
Du meinst auch dass du direkt iVariablen, anstelle von Temporären die die du wiederum am Baustein als In benötigst, oder Lesend sehe ich weniger ein Problem. So wie es du beschreibst ist es ist es aber auch so Designt dass die Daten Direkt verwaltet werden.
Hier wurde es gemacht um Funktionen im Baustein zu ändern die sie selber falsch erstellt haben und dies nicht an einer Stelle sondern zu Duzenden. Die Mängel der Funktionen werden so "Behoben" oder besser gesagt verschoben, denn es treten so ganz andere Fehler auf.
Gefordert waren sauber der Funktion entsprechende Bausteine und übersichtliche Strukturen, so haben wir alles andere als das.

Der Programmierer ist der Ansicht "das ist schon gut so".

Ich habe die Antwort nicht akzeptiert, da das ganze nochmals ähnlich aufgebaut werden soll und er meint ist ja nur Copy Paste. Das ganze überzieht etwa 50 Bausteine an 20-40 Netzwerke. Also alles ander als nur klein und fein.

Da gebe ich dir absolut Recht, wenn Funkionen, die eigentlich in den FB gehören (bei Reset z.Bsp.) nach außen verlagert werden und dann dort IDB-Daten manipuliert wären, dann ist das auf jeden Fall kein guter Stil!
Hast du mich vielleicht nicht ganz richtig verstanden oder ich hab mich schlecht ausgedrückt :rolleyes:, ich vermeide solche Dinge auch auf jeden Fall.
 
Zuletzt bearbeitet:
Vor einiger Zeit die selbe Diskussion mit Siemens zu diesem Thema gehabt.
Ich hatte mir erhofft, dass bei TIA die Instanzen objektorientierter werden und dort z.B. Deklarationen ala "public" und "private" möglich werden.

Gruß
Dieter
 
Ich hatte mir erhofft, dass bei TIA die Instanzen objektorientierter werden und dort z.B. Deklarationen ala "public" und "private" möglich werden.

Lässt du uns dazu auch an der Antwort von Siemens teilhaben? Würd mich mal intressieren...
 
Die Aussage war, dass sich am Befehlssatz und den Funktionen der 1500er noch einiges ändern wird.
Es wurden einige Dinge "angedeutet", jedoch darf ich hierzu nichts weitergeben.

Gruß
Dieter
 
Die Aussage war, dass sich am Befehlssatz und den Funktionen der 1500er noch einiges ändern wird.
Es wurden einige Dinge "angedeutet", jedoch darf ich hierzu nichts weitergeben.

Hoffentlich ist das nicht die gleiche Quelle die euch mitgeteilt hat, das TIA würde alles in einer SQL-Datenbank ablegen...

Für Zugriffsmodifizierer wie public oder private muss auch nichts im Befehlssatz erweitert werden, da es rein auf Übersetzungsebene funktioniert. Zumindest in allen nicht-Siemens-TIA-Schnappsideen ist das so.
Wenn der Compiler direkt Maschinencode und nicht diesen Zwischencode erzeugen würde, wäre jede Funktionserweiterung auf jeder noch so alten CPU lauffähig. Zumindest wenn man sich bei der Erstversion ein vernünftiges Konzept ausgedacht hätte. Durch das jetzige Konzept hat man die Probleme, dass nichts mehr Ab- oder Aufwärtskompatibel ist.
 
Die Aussage war, dass sich am Befehlssatz und den Funktionen der 1500er noch einiges ändern wird.
Es wurden einige Dinge "angedeutet", jedoch darf ich hierzu nichts weitergeben.

Gruß
Dieter

Ich weiß es ist OT, aber sehr seltsam ist es, dass ein System ausgeliefert wird, das nicht fertig ist.
So darf ich doch deine Aussage verstehen.
Wenn dem so ist, kann man ja gut und erfolgreich gegen Big$ klagen. :rolleyes:
Denn vor Gericht werden die Knaben aussagen müssen.

Könnt ihr euch erinnern, wie vor so ungenau 4 Jahren über TIA und die neuen CPU euphorisch nach der Hirnwäsche von Big$ hier geschrieben wurde.


bike
 
Ich weiß es ist OT, aber sehr seltsam ist es, dass ein System ausgeliefert wird, das nicht fertig ist.
So darf ich doch deine Aussage verstehen.

Willst du damit etwa andeuten das Step7 fertig ist?
Versuch da mal eine SCL Multiinstanz online zu betrachten.
Oder ein Projekt über alles zu übersetzen und zu laden das mehr als 5 CPUs hat.

mfG René
 
Bike, wieviele Funktionen wurden bei der 300 oder 400er eingebaut?
Vergleich mal die Systembausteine einer CPU 412 von 95 mit einer aktuellen

Stimmt, es wurde nachgerüstet.
Doch der Vergleich von dir hinkt etwas.
Big$ will alles in das OS der CPU reinbuttern, damit die Nachbauer scheitern.
So kann man seine eigene Unfähigkeit verstecken und es als Innovation verkaufen.

@René: kann man bei einem anderen Hersteller über 100 CPU alles ohne Probleme fehlerfrei übersetzen?
Ich habe bisher wenig Probleme mit unseren Projekten und deren Übersetzung.
Liegt es, wenn es bei dir nicht klappt an Big$ oder an dir?
Wenn bekannt ist, dass etwas nicht bzw nicht fehlerfrei funktioniert, dann muss es eben anders machen.
Nimm einen Compiler und schicke zu einem div durch Null.
Solch ein Vergleich wie du ihn anstellst hinkt nach meiner Meinung wie Stördebecker auf seinem letzten Weg.

Mist, jetzt verteidige ich Big$ schon, so weit ist es gekommen.


bike
 
Zurück
Oben