TIA TIA Portal V14 SP1

Zuviel Werbung?
-> Hier kostenlos registrieren
maxder2te schrieb:
Die Idee dahinter ist recht einfach. Wenn man die Dinger als Instruction in der Firmware realisiert, dann muss der Compiler für alles, was intern abläuft, keine Debug-Geschichten mit in den Maschinencode kompilieren und damit wird die Ausführung schlicht schneller. Zudem gehe ich davon aus, dass hier Siemens die Möglichkeit hat, effizientere Programmiersprachen einzusetzen als SCL oder KOP/FUP.

Kein Mensch verbietet dir, die prinzipielle Funktion von SCATTER, GATHER und den PID-Bausteinen in SCL nachzubauen und auf Firmware 1.5 und einer 1200er einzusetzen. Ob du sie so performant hinbringst, wage ich allerdings zu bezweifeln.
Zum Vergrößern anklicken....

Wobei jetzt die Performance bei Industrie-(SPS)-Automatisierung nun nicht unbedingt im Vordergrund steht... Sicherlich im Maschinenbau schon abundzu, aber in der Prozessautomatisierung eher nicht.

Da geht's eher um langjährige problemfreie Kompatibilität oder auch stoßfreie Änderungsfähigkeit im laufenden Betrieb usw. ...

Gruß.
 
so?

Symbolkommentar4.jpgSymbolkommentar3.jpg
Edit: Aber ich gebe dir recht, das mit den Konstanten ist ne gute Sache.
 
Zuletzt bearbeitet:
gute Frage, morgen mal testen
was mir aufgefallen ist, dass wenn ich im UDT den Kommentar ändere, dann ändert dies nicht den Kommentar im DB.
Die Frage ist nur: ist das nun gut oder schlecht...
 
Das mit den Konstanten mache ich so: Beispiel für NC-Motion...

Deklaration als Anwenderkonstanten
NC_Konstanten_1.JPG

Jeder Verfahrbefehl ist ein Arrayelement UDT (Struct mit allen für den Verfahrbefehl benötigten Werten)
NC_Konstanten_2.JPG

Die Positionierung erfolgt dann nur noch durch Positioniertyp und Datensatz (Arraynummer) (Auch für Referenzieren; Synchron;...)
NC_Konstanten_3.JPG

Die Arraynummer verwende ich damit nur noch "Symbolisch".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
maxder2te schrieb:
Ebenfalls von der Idee her von Rockwell abgekupfert. Dort heißen die Dinger "Instructions" (dt. Anweisungen). Die Idee dahinter ist recht einfach. Wenn man die Dinger als Instruction in der Firmware realisiert, dann muss der Compiler für alles, was intern abläuft, keine Debug-Geschichten mit in den Maschinencode kompilieren und damit wird die Ausführung schlicht schneller. Zudem gehe ich davon aus, dass hier Siemens die Möglichkeit hat, effizientere Programmiersprachen einzusetzen als SCL oder KOP/FUP.

Kein Mensch verbietet dir, die prinzipielle Funktion von SCATTER, GATHER und den PID-Bausteinen in SCL nachzubauen und auf Firmware 1.5 und einer 1200er einzusetzen. Ob du sie so performant hinbringst, wage ich allerdings zu bezweifeln.
Zum Vergrößern anklicken....

Bei Step7 Classic konnte ich SCL-Code noch selber ohne Debuginformation übersetzen, das wäre sicher auch bei TIA möglich gewesen.
Wenn der Kompiler gut ist, dann sollte es keinen großen Unterschied beim Kompilat zwischen SCL, KOP/FUP und z.B. C (glaube nicht dass bei Siemens solche Funktionen in Asselmbler geschrieben werden) geben. Lediglich AWL dürfte langsamer sein, da es auf Grund der Unstrukturiertheit so gut wie nicht optimierbar sein dürfte.

Ich habe mir mal den aus einer in ST geschriebenen Funktion generierten Code von Codesys für einen x86 angesehen (glaub hab ich hier im Forum mal beispielhaft gepostet), wenn man die Debuginformationen weglässt, dann ist da nicht so viel Overhead vorhanden. Laut Aussage von jemandem von 3s hier im Forum, ist die Standard-Bibliothek von Codesys größtenteils in ST geschrieben. Die C-Standardbibliothek ist auch (größtenteils) in C geschrieben.
 
Also:

Wenn ich ein UDT mit Kommentar mache und diesen in einem Array benutze kann ich ja jetzt neu die einzelnen Kommentar ändern. Ändert man nun die Arraygrösse bleiben die Kommentare erhalten, welche nicht weggekürzt werden. Sprich: bei Array [1..20] of MeinArray wird der Kommentar bei Array[2] und Array[20] geändert. Kürzt man nun das Array auf [1..5] bleibt der geänderte Kommentar bei [2]. [20] ist weg, da es nicht mehr existiert.... klingt logisch :rolleyes:. Erhöht man das Array wieder auf [1..20], dann ist bei [20] wieder der default Kommentar. [2] ist immer noch der geänderte.
Ändert man nun im UDT den Kommentar, dann muss man das Array zusammenklappen und wieder aufklappen und die Kommentare sind geändert. UND DAS GUTE DARAN: die vorgängige von Hand geänderten bleiben erhalten, es werden nur die geändert, wo noch den default Kommentar hatten!! :cool: (Glücksgriff oder gewollt?!? :rolleyes:)
Wie sieht man nun was default ist und was geändert? Default ist grau geschrieben und geänderte Kommentare sind in schwarzer Schrift geschrieben.
Gar nicht mal sooo schlecht umgesetzt....
 
blimaa schrieb:
Also:

Wenn ich ein UDT mit Kommentar mache und diesen in einem Array benutze kann ich ja jetzt neu die einzelnen Kommentar ändern. Ändert man nun die Arraygrösse bleiben die Kommentare erhalten, welche nicht weggekürzt werden. Sprich: bei Array [1..20] of MeinArray wird der Kommentar bei Array[2] und Array[20] geändert. Kürzt man nun das Array auf [1..5] bleibt der geänderte Kommentar bei [2]. [20] ist weg, da es nicht mehr existiert.... klingt logisch :rolleyes:. Erhöht man das Array wieder auf [1..20], dann ist bei [20] wieder der default Kommentar. [2] ist immer noch der geänderte.
Ändert man nun im UDT den Kommentar, dann muss man das Array zusammenklappen und wieder aufklappen und die Kommentare sind geändert. UND DAS GUTE DARAN: die vorgängige von Hand geänderten bleiben erhalten, es werden nur die geändert, wo noch den default Kommentar hatten!! :cool: (Glücksgriff oder gewollt?!? :rolleyes:)
Wie sieht man nun was default ist und was geändert? Default ist grau geschrieben und geänderte Kommentare sind in schwarzer Schrift geschrieben.
Gar nicht mal sooo schlecht umgesetzt....
Zum Vergrößern anklicken....
1:1 das Verhalten von Rockwell Studio 5000 ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ducati schrieb:
Wobei jetzt die Performance bei Industrie-(SPS)-Automatisierung nun nicht unbedingt im Vordergrund steht... Sicherlich im Maschinenbau schon abundzu, aber in der Prozessautomatisierung eher nicht.
Zum Vergrößern anklicken....
Wenn man Siemens-Hardware einsetzt und halbwegs modern programmiert (und nicht jedes UND und ODER überlegt) hat man auf kleinen Steuerungen immer ein Geschwindigkeitsproblem. Nur leider führt an Siemens nicht immer ein Weg vorbei (noch nicht).

ducati schrieb:
Da geht's eher um langjährige problemfreie Kompatibilität oder auch stoßfreie Änderungsfähigkeit im laufenden Betrieb usw. ...
Zum Vergrößern anklicken....

Du gibst dir eigentlich selbst die Antwort, nur ein kleiner Punkt fehlt:
Wer abwärtskompatibel sein will, muss sich auch damit abfinden, dass nicht jeder neue Klimbim auf dem alten Zeug auch läuft. Die Firmware 2.1 und V14 SP1 können sicher alles, was mit Firmware 1.5 und V12 auf S7-1500 schon ging. Und am Beginn eines Prozessautomatisierungsprojekts legt man sich nun mal auch auf eine Umgebung mit allen Vor- und Nachteilen fest.

Um das Ursprüngliche zurück zu kommen:
Thomas_v2.1 schrieb:
Dann gäbe es auch nicht das Problem, dass sich bei CPU mit FW x.y die Anweisung so verhält, bei x.z aber so, und bei FW a.b. aber noch gar nicht vorhanden ist. Wenn der Ursprungs-Sprachumfang bei TIA mächtig genug gewesen wäre um alle diese Funktionen in einer Anwender-Funktion zu definieren die ebenfalls z.B. in SCL geschrieben worden wäre, dann hätte man sich den ganzen Zauber sparen können. Dann hätte man ganz einfach auch eine der ersten 1200er Steuerungen mit den neuen Funktionen ausstatten können, indem man der eine neue Bausteinbibliothek (meinetwegen S7lib) mit den Funktionen verabreicht. Warum müssen beispielsweise ein PID-Regler im Betriebssystem realisiert werden?
Zum Vergrößern anklicken....

Niemand käme im Traum darauf, wenn ein Kraftwerk S7-400-Hardware automatisiert wurde, dass man plötzlich an dieser Hardware alles in 64 Bit Genauigkeit rechnen muss. Man findet sich mit der bestehenden Rechengenauigkeit ab, und für die 2-3 Fälle wo man es braucht baut man das halt (langsam) nach. Dass die Grenze zwischen "was ist Firmware" und "was ist Bibliothek" nicht immer ganz scharf gezogen werden kann, ist einerseits nachvollziehbar, andererseits natürlich zu hinterfragen.

Ach ja: Ist die Firmware der Steuerung richtig projektiert, verweigert der Compiler des TIA-Portals sogar die Nutzung von Funktionen, die in der Firmwareversion noch nicht gehen - ich kann da nichts verwerfliches finden.
 
Also was mir gleich auf Anhieb bei V14 positiv aufgefallen ist:
Backups können jetzt direkt mit Datum und Urzeit erstellt werden (leider nicht als Standard einstellbar)
Quellenexporte jetzt direkt inklusive Abhängigkeiten möglich.

Und geht es nur mir so oder ist das SP1 spürbar performanter geworden?

mfG René
 
migrationstool ist aber was anderes!
Damit kannst du aus classic projekten bei installierter Classic SW ein file erzeugen welches du dann zur migration im tia nutzt.
Damit kannst du nicht direkt über tia ein classic project migrieren!
 
Hallo,
Ich hab gerade das SP1 installiert nur leider sagt mir Tia dann
"Diese Anweisung konnte nicht gestartet werden,da die Side by Side Konfiguration ungültig ist...."
Was kann ich jetzt noch tun ?
Gruß Dominik
 

Similar threads

D
TIA [SIOS] Produktabkündigung der Version V16
Antworten
0
Aufrufe
779
DCDCDC
D
P
TIA TIA Projekt Upgrade ohne v12 auf v14 möglich
Antworten
4
Aufrufe
498
DeltaMikeAir
DeltaMikeAir
D
TIA [SIOS] Excel Codegenerator für TIA Portal Openness
Antworten
0
Aufrufe
605
DCDCDC
D
D
TIA [SIOS] Package Manager - Globale Bibliotheken und TIA-Add-Ins herunterladen
Antworten
0
Aufrufe
394
DCDCDC
D
D
TIA [SIOS] TIA Portal Add-Ins
Antworten
1
Aufrufe
1K
DCDCDC
D
Zurück
Oben