- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Genauso kann ich in meinen Instanz-DBs 50% Reserven lassen, und nun?
Vermeiden von Globaldaten
- Ersteller miasma
- Erstellt am
-> Hier kostenlos registrieren
Genauso kann ich in meinen Instanz-DBs 50% Reserven lassen, und nun?
MSB
Level-3
- Beiträge
- 7.191
- Reaktionspunkte
- 1.651
Müsstest du dann halt bei IN / OUT / IN/OUT und last but not least STAT-Parametern lassen.
Schlussendlich ist die Diskussion doch ohnehin wie üblich fürn Arsch, weil rein Philosophisch.
Erstens machts eh jeder wies ihm in den Kram passt, zweitens gibts eh für alles und jedes für und wider,
also weiß ich gar nicht warum der TE überhaupt nach "anderen" Meinungen fragt, soll er halt machen wie er denkt, wobei ich diese künstlerische Freiheit auch für mich beanspruche.
Die Frage wird sogar noch Philosophischer, weil sich die Frage in dem Maße von Haus aus nur bei Siemens und einer Handvoll anderen Steuerungen überhaupt stellt.
Bei Codesys, PCWorx etc. stellt sich die Frage in dem Maß dann eigentlich gar nicht mehr, weils schlicht und einfach nicht funktioniert, das man in Instanzen rumpfuscht.
Bei der S7-1200 mit den "komprimierten" Datenbausteinen, weiß man noch nicht mal mehr, welche Adresse der jeweilige Datenpunkt überhaupt hat,
Blockmove ist hier dann ohnehin kaum mehr sinnvoll nutzbar, bzw. in der 1200er ja im Sinne der 300/400er auch gar nicht implementiert.
Mfg
Manuel
Zuletzt bearbeitet:
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
-> Hier kostenlos registrieren
Reserven sind für mich unakzeptabel. Ich will nur real existierende Daten im Programm.
Ich will schlanke Strukturen die einfach zu beobachten sind.
Spätestens hier wird das ganze aber zu einer Philosophie Frage und ist kein technisches Problem mehr.
Da beides funktioniert.
Hallo Kollegen,
darf ich auch ein wenig mitschwätzen?
Ich verfolge den Ansatz dass für jedes Verfahrenstechnische Objekt zB. Ventil, Motor, Messung mit Z+,A+,A-Z-, etc. ein entsprechender FB mit seinem IDB angelegt wird. Der IDB ist im Prinzip nichts anderes als eine UDT die automatisch angelegt wird. In den FB´s verwende ich die SFC´s 107/108 die aus dem FB heraus CPU Alarme mit Zeitstempel auslösen. Das bedeutet wenn ein Motor eine Störung hat sorgt der Motor-FB dass diese auch entsprechend alarmiert wird.
Im IN oder IN/OUT Bereich des FB´s gibt es Parameter die nicht verschaltet werden sondern für die Bedienung über OP bzw. WinCC reserviert sind. Im OUT Bereich gibt es eine oder mehrere Statusvariablen die für die Steuerung von Zustandsanzeigen verwendet wird.
Auf den Zugriff direkt auf statische Variablen habe ich nach einiger Zeit verzichtet. Der Grund ist der dass, bei Versionsänderungen der FB´s meistens auch eine Verschiebung im STAT Bereich erfolgt.
Habe durchaus gute Erfahrungen mit standardisierten Symbolen und Faceplates gemacht denen man nur noch die Nummer des IDB übergeben muss.
Gruß
Johannes
darf ich auch ein wenig mitschwätzen?
Ich verfolge den Ansatz dass für jedes Verfahrenstechnische Objekt zB. Ventil, Motor, Messung mit Z+,A+,A-Z-, etc. ein entsprechender FB mit seinem IDB angelegt wird. Der IDB ist im Prinzip nichts anderes als eine UDT die automatisch angelegt wird. In den FB´s verwende ich die SFC´s 107/108 die aus dem FB heraus CPU Alarme mit Zeitstempel auslösen. Das bedeutet wenn ein Motor eine Störung hat sorgt der Motor-FB dass diese auch entsprechend alarmiert wird.
Im IN oder IN/OUT Bereich des FB´s gibt es Parameter die nicht verschaltet werden sondern für die Bedienung über OP bzw. WinCC reserviert sind. Im OUT Bereich gibt es eine oder mehrere Statusvariablen die für die Steuerung von Zustandsanzeigen verwendet wird.
Auf den Zugriff direkt auf statische Variablen habe ich nach einiger Zeit verzichtet. Der Grund ist der dass, bei Versionsänderungen der FB´s meistens auch eine Verschiebung im STAT Bereich erfolgt.
Habe durchaus gute Erfahrungen mit standardisierten Symbolen und Faceplates gemacht denen man nur noch die Nummer des IDB übergeben muss.
Gruß
Johannes
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Nur werden hier alle von der Global-DB abweichenden Varianten als Verbrechen hingestellt (Zitat LL: "Jage ich vom Hof" - er selber macht es aber in bestimmten Fällen wo es einfacher ist dann doch).
Ich mache das mit den Instanz-DB Zugriffen aus historisch gewachsenen Gründen nur so wenn ich Intouch-Leitsysteme habe, da ich dort a) eine Excel Tabelle habe die mir automatisch die Adressen generiert, und b) habe ich im Leitsystem eine Speicherfunktion für alle eingestellten Sollwerte. In der Verwendung hat das schon Vorteile: wenn ein Antrieb hinzukommt rufe ich den Antriebs-FB auf, IDB generieren, hochladen, Visu Variablen generieren, fertig. Warum soll ich nochmal was in einem Global-DB dazu anlegen? Ein überflüssiger Arbeitsschritt.
- Beiträge
- 15.414
- Reaktionspunkte
- 4.043
-> Hier kostenlos registrieren
Danke, das geht, ist aber vollkommen schwachsinnig, wirklich.
IDB gehören nur dem FB, Alles andere ist Pfusch, auch wenn es gehen mag, schick ist und dem Anschein nach weniger Arbeit macht.
Lege eine vernünftige Schnittstelle nach außen fest und bediene damit das HMI, aber schreibe nicht vom HMI im IDB herum. Fang damit besser gar nicht erst an.
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
Ich verstehe nicht was an meiner Art Schnittstelle nicht vernünftig ist ?
Sie ist eindeutig, strukturiert und einfach zu beobachten.
Im Gegensatz zu einem Global-DB der viele Antriebe enthält und wohl möglich auch noch verschiedene, die dann auch noch alle zu 50% aus Reserve bestehen.
Ist die Idee von vollständiger Kapselung so exotisch ?
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
Nein, denn ich verwende keine Instanz-DBs für Visu-Aufgaben.
-> Hier kostenlos registrieren
Eigentlich ja.
Wenn du jemals richtig programmiert hast und verschiedene Programmen schon ändern und dort ggF Fehler gesucht hättest, wäre deine Fragen hinfällig.
Bei uns gibt es komplett gekapselte Funktionen, aber nur in der Serie und wenn diese ausreichend ausgetestet sind.
Im Sondermaschinen- und Anlagenbau wird dir das nie gelingen.
Und bis jetzt habe ich immer noch nicht verstanden, was du willst.
Zu lesen deine Ansicht ist richtig?
Versuche solch ein Prgramm in der Autoindustrie zu verkaufen und du wärst für immer kuriert.
Aber wenn man frisch von der UNI kommt, dann hat man solche Ideen, das ist eben so.
bike
MSB
Level-3
- Beiträge
- 7.191
- Reaktionspunkte
- 1.651
Ist dir doch ohnehin egal, das ist eine Frage die man in allerletzter Konsequenz nur Digital sprich mit Ja oder Nein beantworten kann,
so gesehen, mach das doch einfach ... du wirst dich sowieso nicht aufhalten lassen.
Ich finds Siemens-Spezifisch, HMI-Abhängig und alleine deshalb ist es abzulehnen.
Mfg
Manuel
sps-concept
Level-1
- Beiträge
- 2.240
- Reaktionspunkte
- 251
Es gibt Kundenstandards wo das genauso realisiert wird. Die Visuanbindung erfolgt da ausschliesslich per IDB. Im STAT-Bereich gibt es einen bereich für Visuwerte. Alles eine Sache der Bausteinbeschreibung bzw der des ganzen Standards. Einen guten Programmierer macht auch aus, dass er sich anpassen kann und nicht nur stur nach gleichem Schema programmiert.
André
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
-> Hier kostenlos registrieren
Mein persönliches Fazit:
Die Ideen des TE sind alle machbar und auch umsetzbar. Die Ansätze gehen in Richtung Objektorientierung.
Das Problem an der Sache ist nur, dass keine aktuelle SPS-Entwicklungsumgebung hierfür die notwendige Funktionalität liefert um:
a) die Daten konsistent in SPS und HMI zu halten und einen Online-Change zu ermöglichen
b) vernüntige Querverweise / Referenzen zur Fehlersuche zu liefern
Und deshalb gilt einfach - meines Erachtens - auch hier der alte Spruch:
Das Werkzeug muß zur Aufgabe passen.
Gruß
Dieter
Die Ideen des TE sind alle machbar und auch umsetzbar. Die Ansätze gehen in Richtung Objektorientierung.
Das Problem an der Sache ist nur, dass keine aktuelle SPS-Entwicklungsumgebung hierfür die notwendige Funktionalität liefert um:
a) die Daten konsistent in SPS und HMI zu halten und einen Online-Change zu ermöglichen
b) vernüntige Querverweise / Referenzen zur Fehlersuche zu liefern
Und deshalb gilt einfach - meines Erachtens - auch hier der alte Spruch:
Das Werkzeug muß zur Aufgabe passen.
Gruß
Dieter
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Wie, jetzt macht ihr das doch, das ist doch Pfusch?
Bei mir sind immer alle Funktionen in Standardbausteinen ausreichend getestet. Bei euch nicht?
Wenn der Kunde spezifische Vorstellungen hat soll er diese vorher kundtun. Außer wenn eine Visualisierung besondere Anforderungen stellt, lässt sich technisch gesehen kaum ein Grund finden der gegen Zugriff auf Instanz-DBs spricht.
Außer Pauschalaussagen wie "macht man nicht" kommt von euch bisher ja nicht viel, das Killer-Argument lässt noch auf sich warten.
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
Zu erfahren ob es leute gibt die so arbeiten oder so gearbeitet haben.
Wo die evtl. Vor und Nachteile liegen.
Im Grunde genommen genau das was jetzt passiert.
Mich wundert nur das dieses Thema anscheinend sehr emotional diskutiert wird.
Ich habe so ein wenig das Gefühl das jeder für sich beansprucht die perfekte Methode zu haben ein Programm zu erstellen.
sps-concept
Level-1
- Beiträge
- 2.240
- Reaktionspunkte
- 251
-> Hier kostenlos registrieren
Hallo bike,
ich weiss ja nicht aus welchem Jahr(tausend) deine diesbezügliche Erkenntnis stammt.. In diesem Thread hast du so getan als wenn du dich da auskennst:
http://www.sps-forum.de/showthread.php/52941
Mir fallen 3 Automobilisten ein wo das so ist.
André
- Beiträge
- 16.448
- Reaktionspunkte
- 6.047
Meistens wird dieses Thema sehr hochgekocht, erst wird diskutiert, etwas später virtuell angeschrien,
ein bisschen später angespuckt und dann schiebt ein moderator es in den SV.
Aber es ist immer wieder schön
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Also bei Twincat 2 kann ich über ADS auf die Instanzdaten zugreifen.
Bei der 1200er kann ich symbolisch auf die Daten zugreifen, also fällt hier wie auch bei Twincat mit ADS das ganze Adressproblem bei Verschiebungen komplett weg. Bei Twincat gibt es auch kein Problem mit dem Behalten von Variablenwerten bei Änderungen (im Normalfall ;-) ).
-> Hier kostenlos registrieren
Es ging um komplett gekapselte Funktionen, nicht um Zugriff von aussen auf IDB.
Du kannst jede Funktion so austesten, dass du dafür garantieren kannst, dass es keinerlei Quereinflüsse gibt?
Respekt, die Zeit haben wir nicht immer.
Es gibt keine Visualisierung die es unumgänglich macht, auf IDB zu zugreifen.
Es geht auch bei Intouch oder WInCC ohne IDB Zugriffe.
Die einzige Ausnahme kann sein, wenn PCS7 verwendet wird, da kommt es beim Kompilieren, wenn man den Code genauer anschaut, zu Zugriffen auf IDB.
Aber auch das sit meiner Meinung nach falsch. Aber eben BigS eben.
Warum muss das kommen?
Pauschal? Vielleicht solltest du noch einmal genauer lesen.
Es wurden einige Hinweise gegeben, warum es Mist ist eine IDB zu vergewaltigen.
Aber jeder soll das machen was er oder sie für richtig hält.
bike
@sps-concept. ich verstehe nicht was dein Hinweis soll. Ich kann dort keinen Hinweis auf IDB oder erkennen.
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
Was es "a)" angeht muss ich dir recht geben. Aber auf Seiten SPS und HMI sollen Faceplates mit Strukturen arbeiten. Somit muss ich "nur" die Startvariable im Auge behalten und dies im Grunde genommen auch nur auf Seite der Visu.
Was es "b)" angeht kann ich nur sagen einen Querverweis in einem FB der nur Lokaldaten enthält brauche ich nicht. Es gibt ja nur Verwendungsstellen.
Ich bestimmt nicht.
Doch wir haben jedes Jahr mehrere Studis, die ihre Master- oder Diplomarbeit bei uns machen und diese Diskussion kommt bei fast jedem neu auf.
Deine Ansicht hat aber leider mit PLC Programmierung nicht so echt viel zu tun, denn C, mit den entsprechenden Zusatzzeichen, ist ein völlig andere Welt.
bike
Similar threads
WinCC Unified
Rezepturverwaltung
