DB mit AUF öffnen braucht mann das heute noch?

Zuviel Werbung?
-> Hier kostenlos registrieren
Schwächen von Step7? Jeder murxt drum herum? Diese Schwächen muß man erst einmal finden ;-) . Oh Mann, immer diese Ausflüchte. Step7 ist m.E. eine sehr leistungsfähige Software, mit der man auch sehr effektiv programmieren kann. Dabei einigermaßen sauber zu bleiben, ist allerdings schon eine kleine Kunst.
Das klingt ja grad so, als ob ganz sauber überhaupt nicht geht ;)

Wegen dem "Herumgemurxe": ja, jeder!
Ich murxe in Deinen Augen herum, weil ich die SPS anhalte und über eine Rezeptur in der HMI (behelfsweise einer Runtime auf meinem Erstellsystem) meine Aktualdaten der Instanzen rette und zurückschreibe und in meinen Augen murxt Du herum, weil Du Daten, die zu einer in sich abgeschlossenen Einheit gehören, nicht zusammen in einem m.E. dafür gedachten Instanz-Datenbaustein hältst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Diese Datensicherung in Rezepten halte ich für eine sehr nützliche sache,
das spielt es keine rolle ob es jetzt Global oder Instanzdaten sind.

Im Fall vom Onkel, wo er mehre Tausend Variabeln "nur" in den Globaldaten
sichert, finde ich nicht sehr Glücklich. Wenn mann diese wichtigen Daten,
zusätzlich in eine Rezeptur zieht, kann eigentlich nichts mehr anbrennen.
Diese Rezeptur könnte mann sogar exportieren und der Kunde könnte dann
auch gelegentlich eine Datensicherung der Aktualwerte ohne PG und
Programmierkenntnisse durchführen.
 
Wenn man in wiki beginnt zu "fishen" kann man viele verschiedene antworten fangen.

In computer Sprachen gehört "Instance" zu Objekt Orientierte programmieren.
STEP7 hat nichts mit eine wahre objekt orientierte sprache zu tun.
Wenn man objekt orientierte programmiersprachen anschaut sieht man das sie erlaubt eine strikse "kapselung", aber dazu auch ein verfahren die gekapselte daten per "methoden" zu bearbeiten.
In STEP7 gibt es keine "methoden" oder ähnliches.

STEP7 ist mehr wie Procedural programmieren wie Pascal.
In Procedurale programmieren ist "scope" sehr wichtig, also wie man steuert wovon daten zugänglig sind.
In EN61131-3 hat man versucht scope zu implementieren. In STEP7 fehlt es komplett.

Von diese Diskussion sieht man wieviel STEP7 mehr zu den Steinzeit (= S5) gehört als zu eine moderne computer sprache.
Es wird interessant zu sehen ob etwas passiert in v11.

Schluss von hier.
 
Ich würde an dieser Stelle auf die Signatur von 4l hinweisen.
besonders "hilfreich" ist der Teil, dass ".... etc. nicht extra ausgewiesen" sind. Und Kollege 4L klärt auch nicht mehr nachträglich drüber auf, was er nun wirklich meinte. Schreibt dann nur so einen Blödsinn wie "Du bist mein Held", aus dem man dann auch wieder alles rauslesen kann. Genauso, wie aus Deinem jetzt recht unnützen Beitrag ...

Diese Rezeptur könnte mann sogar exportieren und der Kunde könnte dann
auch gelegentlich eine Datensicherung der Aktualwerte ohne PG und
Programmierkenntnisse durchführen.
manche meiner Kunden nutzen dies. Und die Export/Import-Funktion ist bei mir auch mit drin. Auf die Art und Weise können Maschinendaten wie auch Produktionsdaten von Maschine zu Maschine portiert werden oder auch mal bequem mit Office-Produkt dokumentiert werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Perfektionist:
Es geht darum, dass wer lesen kann ist stets im Vorteil.
Daher der Hinweis einfach zu lesen, dann wäre vieles leichter hier.
Mit einem Helden wird niemand versuchen zu diskutieren, da dieser ja so und so recht hat.


bike
 
STEP7 ist mehr wie Procedural programmieren wie Pascal.
In Procedurale programmieren ist "scope" sehr wichtig, also wie man steuert wovon daten zugänglig sind.
In EN61131-3 hat man versucht scope zu implementieren. In STEP7 fehlt es komplett.
hmmm, wenn auch scope nicht fest in Step verankert ist, kann man sich nicht trotzdem daran halten? Durch Deine für mich sehr wertvollen Stichworte habe ich folgendes gefunden:
http://www.uni-koeln.de/rrzk/kurse/unterlagen/java/javaref/funcs/index.htm#Scopes
Blöcke und Scopes
Der Scope oder Name Space ist der Sichtbarkeits- bzw. Gültigkeitsbereich eines Bezeichners.
Der kleinste Scope ist der Block. Außerhalb des Blocks sind die Bezeichner, die innerhalb des Blocks deklariert sind, nicht sichtbar. Man spricht von z.B. von lokalen Variablen. Bezeichner übergeordneter Scopes sind dagegen in eingebetten oder untergeordneten Scopes sichtbar.
Auch eine for-Schleife mit Variablendeklaration in der for-Initialisierung bildet einen Scope.
Ein Funktionskörper ist auch ein Block und ein Scope. Alle lokalen Variablen einer Funktion sind außerhalb der Funktion, nämlich in anderen Funktionen oder oberhalb der Funktion auf der Klassenebene, nicht sichtbar.
Dieses Konzept dient der Trennung von Generellem einerseits und unterschiedlichen Detailbereichen andererseits (Hiding of Information).
Innerhalb der Funktion main der drawLine-Beispiele ist es nur interessant, daß es eine Funktion drawLine gibt, was sie leistet und wie man sie aufruft, aber in keiner Weise, mittels welcher Details sie ausprogrammiert ist, ...
Leider ist meine Programmierpraxis nur von Pascal geprägt, daher kann ich die Abstraktion der OOP nicht nachvollziehen.

Von diese Diskussion sieht man wieviel STEP7 mehr zu den Steinzeit (= S5) gehört als zu eine moderne computer sprache.
Es wird interessant zu sehen ob etwas passiert in v11.
da bin ich auch sehr gespannt auf V11 und verfluche ebenso wie Du die Steinzeit.

Schluss von hier.
schade eigentlich - aber vielleicht hast Du tatsächlich schon alles gesagt, was zu dem Thema zu sagen war ...
 
Diese Datensicherung in Rezepten halte ich für eine sehr nützliche sache,
das spielt es keine rolle ob es jetzt Global oder Instanzdaten sind.

Im Fall vom Onkel, wo er mehre Tausend Variabeln "nur" in den Globaldaten
sichert, finde ich nicht sehr Glücklich. Wenn mann diese wichtigen Daten,
zusätzlich in eine Rezeptur zieht, kann eigentlich nichts mehr anbrennen.
Diese Rezeptur könnte mann sogar exportieren und der Kunde könnte dann
auch gelegentlich eine Datensicherung der Aktualwerte ohne PG und
Programmierkenntnisse durchführen.

Rezeptvariablen werden bei mir in der Rezeptur über das Panel gesichert!
Notwendige Systemvariablen, die ich in unseren Serviceseiten einstelle sind in Global-Daten-DB's abgelegt (man könnte diese zur Sicherung auch in eine Rezeptur stecken!), aber nicht in Instanzdaten!

Instanzdaten sind nur "interne Speicher". Gut, bei Siemens kommt man an diese Speicher ran, aber da diese Speicherbereiche (I-DB's) automatisch generiert werden läuft man bei Änderungen Gefahr einer falsch Adressierung! Ja es gibt die symbolische Adressierung, aber will ich bei Änderungen immer das gesamte Programm überprüfen, compelieren und übertragen? Ich nicht!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hmmm, wenn auch scope nicht fest in Step verankert ist, kann man sich nicht trotzdem daran halten?
Genau.
Ich habe pro "object" eine "status" bereich (nur lesen) und eine "command" bereich (lesen und schreiben). Dann gibt is im objekt weitere daten bereiche die ich von aussen nicht berühren.
Ich versuche zu programmiere als ob es wirklich scope gibt.

- aber vielleicht hast Du tatsächlich schon alles gesagt, was zu dem Thema zu sagen war ...
Doch. Wenn die Diskussion nicht in das Religiöse tendiert.
Ich will versuchen mich zu einen Eintrag pro Tag in diesen Thema zu rationieren.

Zum "Held": Ich meine nicht das ein Held ist einer der immer recht hat, sondern einer der wagt gegen die Mehrheit zu gehen ;)
 
... wer lesen kann ist stets im Vorteil.
ach ja, wer darüber hinaus auch noch denkt , die Hilfe und SuFu findet ...

OK, da gibt es auch noch das BNA-Prinzip: beobachten, nachdenken, ausprobieren. Was die mir verhassten Global-DB anbetrifft, so habe ich diese zwar zunächst von S5 übernommen (habe also bereits Erfahrung damit), bei S7 aber zunehmend bemerkt, dass ich diese dank IDB nicht wirklich mehr benötige.
 
Rezeptvariablen werden bei mir in der Rezeptur über das Panel gesichert!
Notwendige Systemvariablen, die ich in unseren Serviceseiten einstelle sind in Global-Daten-DB's abgelegt (man könnte diese zur Sicherung auch in eine Rezeptur stecken!), aber nicht in Instanzdaten!

Instanzdaten sind nur "interne Speicher". Gut, bei Siemens kommt man an diese Speicher ran, aber da diese Speicherbereiche (I-DB's) automatisch generiert werden läuft man bei Änderungen Gefahr einer falsch Adressierung! Ja es gibt die symbolische Adressierung, aber will ich bei Änderungen immer das gesamte Programm überprüfen, compelieren und übertragen? Ich nicht!

Hallo Michael,
du hast doch hoffentlich meine Ausage richtig gelesen.
Diese Datensicherung in Rezepten halte ich für eine sehr nützliche sache,
da spielt es keine rolle ob es jetzt Global oder Instanzdaten sind.

Mir ging es darum auszudrücken, das es Sinnvoll ist die Daten ruhig noch
mal in ein Rezept zu speichern, gerade du der Leidvolle erfahrung mit den
Datenverlust in der CPU gemacht hat, sollte den sinn meine Ausage
verstehen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was mir so auffällt ist, dass hier auf BigS so eingedroschen wird.

Der Simatik Manager und die entsprechenden PLC sind gut.
Die Entwickler von Siemens haben sich bestimmt etwas dabei gedacht, als sowohl DB als auch IDB implementiert wurden.
Daher sollte auch das so genutzt werden, wie es die es sich damals gedacht haben.
Es machen manche den Fehler, das Werkzeug so lange zu verbiegen, bis das System nicht mehr passt.
Es ist zu prüfen ob Objekte, die in meinen Augen nur eine Modeerscheinung sind, in einer Steuerung notwendig sind.
Mit Objekten meine ich nicht gekapselte Funktionen, sondern das was Objekte sein wollen.
So etwas habe ich schon gesehen und bin erschrocken wie man Step7 so verunstalten kann :confused:
Das Ergebnis von Objekten sehe wir in den OS die wir leider meist nutzen müssen.

Ja, ich weiß dass WinCC und -flex Mist sind, doch ist es wo anders besser?

Wenn jemand mit Rockwell oder Bosch oder Fanuc programmieren muss, der kann dann erst schätzen was BigS gebaut hat.


bike
 
Der Simatik Manager und die entsprechenden PLC sind gut.
...
Wenn jemand mit Rockwell oder Bosch oder Fanuc programmieren muss, der kann dann erst schätzen was BigS gebaut hat.

bike

Da muß ich dir mal sagen: *ACK* ;)
Es gibt viel mehr schlechtere als bessere Programmiersysteme!
 
Ja es gibt die symbolische Adressierung, aber will ich bei Änderungen immer das gesamte Programm überprüfen, compelieren und übertragen? Ich nicht!
ich arbeite seit langem nur noch mit Operandenvorrang Symbol. Das gesamte Programm zu compilieren und zu übertragen ist im Übrigen nicht notwendig. Es genügt, bei der Bausteinkonsistenzprüfung nur die durch die Änderung betroffenen Bausteine neu übersetzen zu lassen. Und ein online/offline-Vergleich zeigt, welche Bausteine zum AG zu übertragen sind (hoffentlich wird das bei V11 erleichtert und/oder automatisiert).
 
...Notwendige Systemvariablen, die ich in unseren Serviceseiten einstelle sind in Global-Daten-DB's abgelegt (man könnte diese zur Sicherung auch in eine Rezeptur stecken!), aber nicht in Instanzdaten!...

Helmut,
genau das hab ich doch geschrieben, aber das Thema ist ja immernoch DB-Zugriffe ;)

Perfektionist,
genau das mir noch ein Dorn im Auge (aua), von andreren Steuerungen z. B. Omron kenne ich das so, dass immer das Ganze Programm übertragen wird, da ist das dann letztlich egal, aber ich möchte ja auch Änderungen schnell mal einspielen und da ist mir derzeit der Aufwand mit der symbolischen Adressierung beim Kunden vor Ort zu groß. Wenn V11 das besser handhaben kann, das wäre SUPER!
 
Der Simatik Manager und die entsprechenden PLC sind gut.
Die Entwickler von Siemens haben sich bestimmt etwas dabei gedacht, als sowohl DB als auch IDB implementiert wurden.
Daher sollte auch das so genutzt werden, wie es die es sich damals gedacht haben.
Tja, ich bin zwar weitgehen gegen IDB-Zugriffe von außen, einfach aus praktischen Gründen,
vor allem weil ich gelegentlich auch mal auf die quasi Instandhalter Seite wechsle, und weiß,
was passiert, wenn man irgend sowas übersieht bei einer Änderung.

Ob das damals so gedacht war, das man das so strikt trennt, wie es imho Sinn macht weiß ich nicht.
Fakt ist auf jeden Fall das Siemens in den Ausbildungsunterlagen und den anhängigen Beispielen,
auch in IDBs mit HMI und anderen rumfingert.

Wenn jemand mit Rockwell oder Bosch oder Fanuc programmieren muss, der kann dann erst schätzen was BigS gebaut hat.
Speziell Rockwell halte ich diesbezüglich vom Grundgedanken der Tags her für wirklich gut,
auch wenn die HMI's oder vielmehr die Software RSViewME/Factory..ME ... untoll sind.

Mfg
Manuel
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
wo kann ich denn bitte nachlesen, ob und was sie sich dachten? Mutmaßungen über den Willen eines nicht wahrnehmbaren Wesens gehören in den Bereich der Religion.



Ich verweise darauf:
http://www.sps-forum.de/showpost.php?p=314595&postcount=106

Wenn du es nicht verstehst, ist das dein Problem.
Aber anderen abzusprechen sie würden bei der Entwicklung von einem Programm sich etwas dabei gedacht haben, in den Bereich der Religion abzuschieben, ist schwach.
Du tust sowohl der Religion als auch den Entwicklern unrecht.
Ich kenne Leute aus Karlsruhe und Fürth und, sein versichert, die wissen was sie tun.


bike
 
Speziell Rockwell halte ich diesbezüglich vom Grundgedanken der Tags her für wirklich gut,
auch wenn die HMI's oder vielmehr die Software RSViewME/Factory..ME ... untoll sind.l

Es geht nicht um die Theorie, sondern was die Software wirklich kann.
Rockwell hat seine Vorteile, doch noch? überwiegen nach meiner Erfahrung die Nachteile.

Ebenso den Schritt zwischen Codesys 2.3 und 3.0 habe ich nicht verstanden, warum bzw was brauche ich von dem neuen System um eine Maschine zu programmieren?

In Hochsprachen verwende ich Objekte wo es nach meiner Empfindung Sinn macht, aber ich versuche nicht alles in Objekte zu zwingen.


Ich verstehe es immer noch nicht, warum die Trennung zwischen DB und IDB so zwanghaft aufgelöst werden muss :confused:


bike
 
Zurück
Oben