Frage zur Programmierung

[1schilcher]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hatte bei einer unseren Maschinen eine Störung, wo ein Magnetventil nicht angesteuert wurde. (S7 Steuerung). Die Anlage besteht aus ca. 100 Magnetventile und ca. 20 Luftpumpen! Alle sind wie es sich gehört (so denke ich) mit mehreren FB´s, den dazugehörigen IDB´s bzw. Multiinstanzen programmiert. Die Handsteuerung der Ventile habe ich sofort verstanden - beim Aufruf des FB´s gabs eine IN Variable "Hand Ein = Db1.dbxx.x). Die Automatikfunktion - "Auto Ein" blieb ganz einfach leer. Trotzdem wurde das Ventil in Automatik angesteuert, und ich konnte einfach nicht feststellen wie oder wo die IN Variable gemacht bzw. angesteuert wurde. Heute habe ich (nach 8 Std.) herausgefunden, das diese Firma das Bit (DBX.dbx.xx für Auto Ein) im Instanz DB setzen!!??! Das Bit wird in einem FC ganz normal gesezt bzw. Rückgesetzt! Wieso macht diese Firma das so - oder ist das normal. Für mich persönlich ist das ja kompletter Schwachsinn - wenn ich zb. den FB ändere - würde das ganze Programm nicht mehr funktionieren - da kann ich Übersetzen wie will!! Oder sehe ich das falsch - was sagt Ihr zu dem Fall?

 

[Larry Laffer]

wenn ich zb. den FB ändere - würde das ganze Programm nicht mehr funktionieren - da kann ich Übersetzen wie will!! Oder sehe ich das falsch - was sagt Ihr zu dem Fall?

Ich sehe das grundsätzlich so wie du ...
Diie Firma hat das sicherlich so gemacht, weil es so in dem Moment warscheinlich am Einfachsten war ... Vielleicht wollte (oder sollte) der Programmierer den Baustein auch nicht ändern ...

Gruß
LL

 

[godi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Frage mal Machtnix und lese dir folgenden Thread durch:
https://www.sps-forum.de/showpost.php?p=133142&postcount=22
https://www.sps-forum.de/threads/19452

godi

 

[1schilcher]

Diese Firma (will den Namen nicht nennen) ist eine ziemlich arrogante!! Kann es nicht einfach sein, das die nicht wollen, das diese Software ein normaler IH versteht!!

 

[Ralle]

Diese Firma (will den Namen nicht nennen) ist eine ziemlich arrogante!! Kann es nicht einfach sein, das die nicht wollen, das diese Software ein normaler IH versteht!!

Glaub ich nicht, aber Arroganz und Dummheit gehen häufig eine unheilige Ehe ein, siehe unsere deutsche Politikerriege. Ansonsten gibt es unbelehrbare und welche, die sich für schlauer als alle anderen halten, das kannst du in godis Links verfolgen (s.o.), da ging es genau darum .

 

[Bitverbieger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kenne auch solche Firmen und bin fest davon überzeugt das dies
gezielt gemacht wird. Da braucht man dann ja gar keine Bausteinschutz mehr.

 

[HeizDuese]

Grundsätzlich ist es möglich so zu programmieren.

Ein riesen Nachteil besteht darin, später per Referenz nicht alle Verwendungsstellen finden zu können. Wenn man so programmiert (dafür kann es auch schon mal Gründe geben, für die es immer eine andere Lösung gibt ), sollte man zu mindest an den Pin des Aufrufs die Instanzadresse dranschreiben (macht nur bei symbolischer Adressierung richtig Sinn) - sieht in AWL recht lustig aus. Hat den Vorteil, dass man den Bausteinaufruf und die entsprechnede Stelle, an der die Variable beschrieben wird im Programm per Referenz wieder findet. Außerdem kann man nun, im Gegensatz zu einem freigelassenen PIN den Status erkennen, den die (Instanz-) Variable (und damit der Baustein-Pin) hat.

 

[Machtnix]

Heute habe ich (nach 8 Std.) herausgefunden, das diese Firma das Bit (DBX.dbx.xx für Auto Ein) im Instanz DB setzen!!??! Das Bit wird in einem FC ganz normal gesezt bzw. Rückgesetzt!

Grundsätzlich ist es möglich so zu programmieren.

Ein riesen Nachteil besteht darin, später per Referenz nicht alle Verwendungsstellen finden zu können.

Wenn ich mir eine Referenz erstellen lasse (Step7 V5.3), sind darin alle Verwendungen von InstanzDB- Variablen aufgelistet, egal ob es in einem FC, OB oder anderen FB geschieht. Wie kommt ihr darauf, daß sie nicht zu finden sind?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich mir eine Referenz erstellen lasse (Step7 V5.3), sind darin alle Verwendungen von InstanzDB- Variablen aufgelistet, egal ob es in einem FC, OB oder anderen FB geschieht. Wie kommt ihr darauf, daß sie nicht zu finden sind?

Natürlich ist über die Referenzliste das entsprechende Datenbit zu finden. Da es aber nicht in direkter Verbindung zu dem entsprechenden Ausgang steht (war ja OUT-Parameter des FB's, der vermutlich sogar mehrfach aufgerufen wurde) sucht man ja auch gar nicht erst da nach.

Gruß
LL

 

[Grubba]

Wenn man die Werte wirklich "direkt" in die Instanz DBs schreibt, sollte man das meiner Meinung nach aber durch die Bank weg durchziehen, und nicht nur einzelne Bits oder Werte.
Dann hat ein FB halt keine E/A's als sichtbare Schnittstelle nach außen mehr, dann weiß man aber sofort, wo man dran ist und keiner muss mehr nachsehen, welcher E/A denn nun direkt im Instanz-DB geschrieben/gelesen wird und welcher nicht.

 

[Markus]

zur feinen englischen art gehört es nicht auf instanzdatenbausteien direkt zuzugreifen (egal ob lesend oder schreibend).

ich muss aber zugeben das ich das unter bestimmten bdingugnen auch mache, aber nicht so!


auf die normalen schnittstellenvariablen eines FB (IN;OUT;INOUT) sollte man nun wirklich nicht direkt zugreifen.

aber auch mache ich innerhalb von standart fbs wenn ich zb einen SFB4 (IEC SE Timer aufrufe), da kann dann schon mal stehen:

u bed-1
u bed-2
u bed-3
= Instanz_SFB4.IN

aber gleich in der nächsten zeile kommt der aufruf:

call Instanz_SFB4...



ansosnten habe ich zb häufig für jede betriebsart einen eigenen FB, jede betreiebsart muss je nach anlage sehr viele aktoren ansteuern. für jeden aktor ein bit auf die schnitstelle wäre unpraktikabel. deshalb lege ich in jeden bestiebsart fb eine struktur zb mit dem namen "Ausgang"
jeder beteisbartenfb hat in dieser structur den selben udt mit den symbolischen name der ganzen aktoren.

im programm greife ich auf diese instanzdatenbausteine dann auch von extern zu, das sieht zb so aus:

O IDB_Automatik.Ausgang.Motor_1
O IDB_Handbetrieb.Ausgang.Motor_1
O IDB_Einrichten.Ausgang.Motor_1
= aMotor_1

ich finde das auch nicht perfekt, und es gibt programmierer die das schöner lösen. aber ich denke mit einer solchen struktur ist das auch verständlich, nachvollziehbar und vor allem schnell und praktikabel...

so und jetzt steinigt mich!
der böse markus der hier im forum jeden schlampigen programmierer zur schnecke macht hat zugegeben das er auch manchmal direkt auf idbs zugreift...

 

[Grubba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Na ja, ist wohl auch eine Sache der Philosophie. Prinizipiell ist es ja nun kein Unterschied, ob ich einen Eingang am FB von außen beschalte, oder ihn direkt im Instanz-DB schreibe. Dann betrachte ich den Instanz-DB halt als Schnittstelle.
Aber für die meisten ist es wohl übersichtlicher, beim Debuggen von "außen" auf den FB zu sehen und die E/A's im Blick zu haben, als nur den "nackten" Instanz-DB.

 

[Machtnix]

Wenn man die Werte wirklich "direkt" in die Instanz DBs schreibt, sollte man das meiner Meinung nach aber durch die Bank weg durchziehen, und nicht nur einzelne Bits oder Werte.
Dann hat ein FB halt keine E/A's als sichtbare Schnittstelle nach außen mehr, dann weiß man aber sofort, wo man dran ist und keiner muss mehr nachsehen, welcher E/A denn nun direkt im Instanz-DB geschrieben/gelesen wird und welcher nicht.

*ACK*

So seh ich das auch. Gemischte Programmierung halte ich für unsaubere und unübersichtliche Programmierung, unter anderem weil es falsche Erwartungen weckt. Ein Programm sollte leicht erkennbare Prinzipien haben, die dann auch eingehalten werden. Welche Prinzipien sinnvoll sind, hängt aber auch von der Art der Anwendung und vom Gesamtkonzept ab (Größe des Programms, Menge und Art der Daten, Quelltext oder Direktbearbeitung der Bausteine usw). Bei den Datenmengen, mit denen ich zu tun habe würde eine Datenübergabe beim Aufruf zu einem völlig überladenem OB1 mit endlos langen und unüberschaubaren Parameterlisten führen. Außerdem sind bei mir fast alle DBs Instanz-DBs und wenn die Daten von dem einen in andere sollen, bräuchte es ohne "Fremdzugriff" sinnlose Umwege über Merker oder zusätzliche DBs.

 

[Ralle]

@Grubba und Machtnix

Eigentlich wollte ich mich zurückhalten, aber das kann man einfach nicht unkommentiert lassen. Da habe sich ja endlich zwei getroffen. Ihr könnt es so oft wiederholen, wie ihr wollt, Des Reinschmieren in IDB von einer anderen Instanz, als dem eigenem FB, ist absolutes NO-GO, lesen aus einem IDB kann man durchaus mal machen, aber alleine die Tatsache, daß jede Schnittstellenänderung im FB zum absoluten Datengau führen kann, sollte doch auch erwähnt werden. Natürlich passiert das auch, wenn ein Global DB geändert wird, aber das muß man ja bewußt machen und anschließend sein Programm anpassen. Es gibt immer spezielle Fälle, die auch "Sondermaßnahmen" erforderen, sei es aus Zeitgründen, oder der Effektivität wegen (siehe Markus), aber das sollte doch selten und entsprechend dokumentiert sein. Ich glaube auch sicher nicht, daß meinen Programme besser als eure oder die anderer Programmierer sind, dazu gefällt mir daran selbst immer noch zu wenig, aber wenigstens die schlimmsten bekannten Fehler sollte man vermeiden.

 

[Grubba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man stelle sich eine Anlage mit 50 gleichen Betriebsmitteln vor. Für jedes BM gibt es einen FB, der jeweils zu instatieren ist. Jeder Fb benötigt 20 EAs. Das würde 1000 EAs ergeben. Habe ich nur Bits, dann gehts noch. Wäre jeder EA ein DW, würde ich schon bei DW4000 liegen. (Kann das noch eine 300er ?)
Verwende ich zusätzliche DBs, benötige ich zusätzlich zu den Instanz-DBs nochmal die gleiche Datenmenge. Und muß doch wieder sämtliche Werte erst in den Global-DB schreiben und diese dann an meine FB-EAs klemmen. Usw. usf.

Ich habe dieses Vorgehen bisher selber noch nicht verwendet, einigt man sich aber mit den anderen Programmierern auf diese Konvention sollte es keine Probleme geben.

Was ich ja nun gesagt habe, ist das das mischen von teilweise schreiben in Instanz-Dbs und teilweise anlegen an die EAs doch unterlassen werden sollte weil dann keiner mehr durchblickt.

Hätte Siemens bei Einführung von Step7 das Vorgehen des direkten Beschreibens der Instanz-Db vorgegeben, hätte ja auch niemand aufgeschrien.

Nochmal: Ich habs noch nicht so gemacht, aber wenns denn konsequent durchgezogen wird ist es ein gangbarer Weg.

 

[MW]

Nochmal: Ich habs noch nicht so gemacht.

Ich hoffe das bleibt auch so

 

[Grubba]

Ich hoffe das bleibt auch so

.... ruhig, Brauner, ruhig....

Also wenn schon, dann würde ich in meinem FB von vornherein für alle E's, A's und EA's eine Struktur definieren. Nach außen habe ich dann max. 3 Variablen anliegen und alle sind glücklich.

Besser so?

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jeder Fb benötigt 20 EAs.

durchaus möglich, ja, aber sollte da vielleicht noch mal über die struktur nachgedacht werden? ich denke, man kann da noch einiges rausholen

 

[Grubba]

@vl

durchaus möglich, ja, aber sollte da vielleicht noch mal über die struktur nachgedacht werden? ich denke, man kann da noch einiges rausholen

Ist ja auch meine Meinung.

Sieht dann halt so aus:

MyFB

In - Motn_In
Out - Motn_Out
InOut - Motn_InOut

Die Strukturen werden dann halt weiter aufgedröselt:

MotnIn.Start
MotnIn.Geschw
...
...
MotnOut.Laeuft

usw.

 

[Markus]

@vl



Ist ja auch meine Meinung.

Sieht dann halt so aus:

MyFB

In - Motn_In
Out - Motn_Out
InOut - Motn_InOut

Die Strukturen werden dann halt weiter aufgedröselt:

MotnIn.Start
MotnIn.Geschw
...
...
MotnOut.Laeuft

usw.

ich glaube dass ist dann richtig pervers...