[1500er] so sieht Sie aus

Zuviel Werbung?
-> Hier kostenlos registrieren
Aber mit den Symbolen immer schön aufpassen
wenn du bei einer 1200er den Typ eines Symbol änderst ist dein HMI Stand dazu nicht mehr kompatibel - AUCH wenn du den alten Typ wieder einstellst :(
gibts ein Automatisierungssystem, das sogar das beherrscht? Denkbar wäre natürlich schon, die Datenhaltung in der SPS komplett zusammen mit Typkennung zu machen. Hätte mich positiv überrascht, aber nicht erwartet.
 
Wie meinst du?

gibts ein Automatisierungssystem, das sogar das beherrscht?

Ich glaube du hast mich falsch verstanden:

1. du legst in einem symbolischen DB eine Variable an z.B. TEST1 als Int
2. jetzt mal Übertragung auf SPS und HMI
3. jetzt änderst du den Typ von TEST1 auf Word - Upps falsch - schnell wieder zurück auf Int
4. du überträgst mal neu auf die SPS (nicht HMI)

jetzt ist deine SPS und HMI nicht mehr kompatibel

Siemens könnte es problemlos: Alle Informationen sind da, nur der Schlüssel den die für die Eindeutigkeit eines Symbols bauen muss irgendwie blöd sein
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Video auf der Siemens Homepage sieht ja schön aus. "Dat Teil" ist auch sicherlich nicht schlecht (vor allen das Adressieren der Ethernetports sowie deren Anzahl). Die Hutschienenfunktion der der Profilschiene finde ich total überflüssig. Performancen ist immer gut und der schräge Anschlussstecker auch nicht schlecht. Fazit die Hardware finde ich gut, wenn da nicht die Software wäre.
 
... nur der Schlüssel den die für die Eindeutigkeit eines Symbols bauen muss irgendwie blöd sein
Also ich verstehe das von Dir geschilderte Verhalten so: durch die Typänderung wird der Variablen eine neue, fortlaufende Nummer vergeben. Die Rückänderung ist nicht vorgesehen, es wird wieder eine weitere Nummer vergeben. Resultat: bereits bei der ersten Typänderung ist die Variable nicht mehr die gleiche und wurde durch die Speicherverwaltung möglicherweise an einen anderen Ort verlegt.

Die einzige Abhilfe, die ich sehe, dieses Verhalten zu ändern, ist, online neben dem Inhalt der Variablen auch deren Datentyp abzulegen, dann könnte sie an der Stelle (Adresse) belassen werden, wo sie auch ursprünglich im Arbeitsspeicher vor der Typänderung abgelegt war. Dann müsste das Laufzeitsystem die Typumwandlung beim Einketten der geänderten Bausteine vornehmen, was allerdings fehlerhaft ablaufen kann (Überlauf z.B. bei Änderung DINT --> INT).

Da ist für mich das kleinere Übel, die HMI entsprechend der Typänderung zu aktualisieren. Und die Typänderung als ein Neuanlegen der Variablen zu betrachten.
 
... wenn da nicht die Software wäre.
Das, denke ich mal, ist ein Vorurteil, das sich zu Unrecht auf Erfahrungen aus 2004 stützt. Wenn die 1200er funktioniert, warum soll dann die 1500er dem nachstehen? Wenn überhaupt, so ist an V11/12 wahrscheinlich eher mit weiterbestehenden Lücken beim Thema Antriebstechnik zu rechnen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube du hast mich falsch verstanden:

1. du legst in einem symbolischen DB eine Variable an z.B. TEST1 als Int
2. jetzt mal Übertragung auf SPS und HMI
3. jetzt änderst du den Typ von TEST1 auf Word - Upps falsch - schnell wieder zurück auf Int
4. du überträgst mal neu auf die SPS (nicht HMI)

jetzt ist deine SPS und HMI nicht mehr kompatibel

Siemens könnte es problemlos: Alle Informationen sind da, nur der Schlüssel den die für die Eindeutigkeit eines Symbols bauen muss irgendwie blöd sein

Soll das heißen der Schlüssel wird bei der Generierung der HMI erzeugt? Kann ich mir ja fast nicht vorstellen, denn dann gibt es ja überhaupt keinen Vorteil gegenüber der bisherigen Variante mit absoluten Adressen - im Gegenteil sogar ein Nachteil weil es noch schneller inkonsistent sein kann.

Bei der heutigen Rechenleistung könnte man doch sicher die komplette Symbolik in der SPS ablegen. Das HMI stellt dann als erstes eine Anfrage mit den Symbolen und bekommt irgendwelche Hashwerte zurück über die die Symbole referenziert werden. Das Prinzip gab es schon im AS-511 Protokoll, dort musste für eine DB-Nummer auch erst die 'echte' Speicheradresse abgefragt werden. Wurde ein DB erneut übertragen hat sich diese u.U. geändert, darum muss das HMI öfters mal nachfragen ob sich da was geändert hat.

Aber so scheint es wohl nicht zu funktionieren.
 
nenee, das läuft anders: eine einmal festgelegte Variable bleibt auf der einmal vom System festgelegten Adresse für immer liegen. Vergangenheit ist, dass der DB als Block mit einer variablen Anfangsadresse im Arbeitsspeicher liegt, Gegenwart ist, dass der DB auf Festadressen verteilt liegt, und zwar nicht mehr als Block.
 
Also symbolischer Zugriff heißt für mich zumindest, ich kann jemandem anderen sagen "Die Temperatur kannst du dir in der SPS aus der Variable #Behaelter_1.Temp_oben abholen". D.h. der Name reicht aus.
So wie sich das anhört geht das nicht, sondern es gibt eine magische Zahl die dazugehört. Dann brauche ich aber auch kein Symbol sondern nur magische Zahlen. Da hätte man auch gleich bei DB Nummern bleiben können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
so läufts bei mir

Also symbolischer Zugriff heißt für mich zumindest, ich kann jemandem anderen sagen "Die Temperatur kannst du dir in der SPS aus der Variable #Behaelter_1.Temp_oben abholen". D.h. der Name reicht aus.

das stimmt - die Zuordnung läuft primär über den Namen, es gibt keine Absoluten-Zuordnungen mehr (ausser DB-Nr) - also irgendwie nicht so 100% symbolisch :(
- soweit ich das getestet habe wird der komplette Pfad der Variable als Schlüssel verwendet

d.h. wenn du einen VariableX.VariableY in SPS und HMI hochlädst
dann den Variablennamen auf VariableX.VariableZ änderst und nur auf die SPS überträgst ist dein HMI jetzt inkompatibel
wenn du jetzt deinen Namen wieder auf VariableX.VariableY änderst und auf die SPS übeträgst läufts auch wieder mit dem HMI
(meine ersten Erfahrungen aus Tests mit TIA V11 SP 3, S7-1200 V2.x und KTP400)

blöd ist nur wenn du mal den Typ geändert hast - da hilft auch kein zurückstellen auf den alten Typ (was beim Namen problemlos klappt) - jetzt musst du SPS und HMI updaten

ich weiss nicht ob Siemens das wieder geändert hat - oder ob es da wichtig Gründe gibt warum es so ist - warum keine 100%igen symbolische Adresse erlaubt sind ist technisch nicht begründbar
 
... Gegenwart ist, dass der DB auf Festadressen verteilt liegt, und zwar nicht mehr als Block.
wobei ich mir inzwischen Gedanken mache, wie das dann mit Pointeradressierung zusammengehen soll.
...
d.h. wenn du einen VariableX.VariableY in SPS und HMI hochlädst
dann den Variablennamen auf VariableX.VariableZ änderst und nur auf die SPS überträgst ist dein HMI jetzt inkompatibel
wenn du jetzt deinen Namen wieder auf VariableX.VariableY änderst und auf die SPS übeträgst läufts auch wieder mit dem HMI
...
ich weiss nicht ob Siemens das wieder geändert hat - oder ob es da wichtig Gründe gibt warum es so ist - warum keine 100%igen symbolische Adresse erlaubt sind ist technisch nicht begründbar
technisch begründbar ist alles, wenn es dann letztlich um Ausführungszeit geht.

Technisch denkbar wäre auch, mehrere OB1 in einem SPS-Programm zuzulassen und über öffentliche Merker die Programme untereinander kommunizieren zu lassen. Oder eben auch die komplette Symbolik vollständig auf der SPS zu halten, statt im Erstellsystem. Aber Siemens ist den Weg gegangen, dass das Erstellsystem die Hauptarbeit übernimmt und die Laufzeitsysteme einfach nur schnellstmöglich das tun sollen, was das Erstellsystem ihnen vorgibt.
 
Ist da etwa geheimes Detailwissen vorhanden?

technisch begründbar ist alles, wenn es dann letztlich um Ausführungszeit geht.

Technisch denkbar wäre auch, mehrere OB1 in einem SPS-Programm zuzulassen und über öffentliche Merker die Programme untereinander kommunizieren zu lassen. Oder eben auch die komplette Symbolik vollständig auf der SPS zu halten, statt im Erstellsystem. Aber Siemens ist den Weg gegangen, dass das Erstellsystem die Hauptarbeit übernimmt und die Laufzeitsysteme einfach nur schnellstmöglich das tun sollen, was das Erstellsystem ihnen vorgibt.

laut meiner Tests ist die Symbolik komplett auf der SPS - wie kommst du darauf das es nicht so ist? Wireshark zeigt auch klar auf das die Symbolnamen über die Leitung gehen

und mit Geschwindigkeit hat das alles eh nichts zu tun - jedes Symbolsystem lässt sich immer auf die "Minimal"-Zugriffszeit bringen solange das Erstellsystem und Laufzeitsystem die "gleiche" Sprache sprechen - da es bei der Symbolik eh keine Start-Offset,Anzahl Elemente-Zugriffe mehr gibt (jedes Bit,Byte,etc. ist ja ein "Symbol") könnte auch jedes Symbol nur eine Id oder sowas sein

aber du scheinst ja genauer zu wissen wie die Symbolik bei der S7-1200 und S7-1500 realisiert wurde - also kannst du mir vielleicht die Gründe erklären warum:

-die Symbole nicht DB-Übergreifend funktionieren (d.h. ein verschieben meines Symbols in einen anderen DB erzwingt wieder ein Neu-Upload am HMI)
-ein Typänderung (also nur in Selektbox rein und aus Int->Word->Int) im TIA eine Neu-Upload auf SPS und HMI erzwingen (du hast nur die Selektbox kurz falsch eingestellt), Namens Rückänderungen aber komischerweise nicht

und komm mir nicht mit Geschwindigkeit - es wird nicht Super-Schneller wenn die DB + Symbol mit angegeben werden muessen - eher langsamer

was soll der tiefere Sinn der Symbolik sein wenn solche Sachen nicht funktionieren? Oder besser gefragt - Was sind genau die Vorteile der Symbolik so wie realisiert

wobei ich mir inzwischen Gedanken mache, wie das dann mit Pointeradressierung zusammengehen soll.

Wer sagt das sowas noch geht - Pointeradressierung und Symbolik ist wie Feuer und Wasser - das passt doch überhaupt nicht zusammen

Ich versteh einfach deinen Das-ist-genau-richtig-wie-es-ist Tenor in der Stimme nicht - benutzt du die Symbolik?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
OK, dann muss ich anscheinend meine Vorstellung davon, wie es funktionieren könnte, revidieren. Wird Zeit, dass ich endlich mal konkret was aus der TIA-Welt auf den Tisch bekomme und nicht nur Classic mit TIA mache.

und ja, ich programmiere seit V5.2 vollsymbolisch.

Wegen Pointer: ich lese in einer im IDB abgelegten Tabelle per Pointer und frage mich, ob dieser Code dann unter TIA mit optimiertem Bausteinzugriff überhaupt noch so funktionieren kann. Abhilfe wird wohl ein Array und SCL sein.
 
ist ja auch nur ein kleiner Unterschied ob wir von symbolischer programmierung oder symbolischen Zugriffen auf die SPS sprechen :)

Vielleicht ist es so ähnlich wie bei AB RS5000, da wird selbst der Austausch von Variableninhalten über Symbolik (und wirklich NUR über Symbolik) gemacht.
Das nennt sich dort Consumed/Produced Tags. Da kann man - ohne das Fremdprojekt der Partner-CPU zu haben - im freigegebenen (procuded) Tags Bereich browsen und die
Variablenverbindungen zur Laufzeit herstellen. Ich fürchte aber eher, das da SIEMENS was spezielles erfunden hat.

Frank
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@IBFS

Das nennt sich dort Consumed/Produced Tags

also so einen Art Alias - wenn du X abfragst geht es in wirklichkeit auf Y - sehr nett -> hast du da eine kleine Doku/PDF oder sonstiges?

@ALLE anderen

kann jemand der eine 1500er auf dem Tisch stehen hat mal ein Wireshark-Log von einem Upload,Benutzung oder sowas einstellen - oder mir als PN schicken - würde da gern mal reinschauen :)
 
richtig! Die Features sehen wirklich nichts schlecht aus (ist ja merketingtechnisch entsprechend aufgemacht ;) )

Die Frage ist halt wie immer: wann ist das TIA-Portal bereit, bzw. brauchbar.....

gruss, o.s.t.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
TIA ist ein anderes Thema, hier wollten wir uns mal der neuen 1500er Baureihe zuwenden ;)


aber dieses wird mein Lieblingsbefehl für AWL
Code:
[FONT=Arial][SIZE=4][COLOR=#0070c1][FONT=Arial][SIZE=4][COLOR=#0070c1][FONT=Arial][SIZE=4][COLOR=#0070c1]L "Data".my_array[#index]
[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT]
 
Zuletzt bearbeitet:
TIA ist ein anderes Thema, hier wollten wir uns mal der neuen 1500er Baureihe zuwenden ;)
richtig! - nur ist die 1500er ohne TIA nichts mehr als teurer Edelschrott...

jetzt aber fertig gelästert ;)

zur Hardware - im Moment würden uns noch die Compact-CPU's a la CPU314C-2 fehlen.... - scheint aber wohl (verständlicherweise) nicht mehr ins Konzept zu passen

o.s.t.
 
zur Hardware - im Moment würden uns noch die Compact-CPU's a la CPU314C-2 fehlen.... - scheint aber wohl (verständlicherweise) nicht mehr ins Konzept zu passen

o.s.t.

Auf der SPS wurde mir versichert das es auch (zu einen späteren Zeitpunkt) wieder Compact CPUs geben wird....nun ist halt nur die frage wie viele Dekaden das dauern wird ;)
 
Zurück
Oben