TIA TIA Portal V14..V17 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie berechnet TIA eigentlich die voraussichtliche Speicherauslastung der CPU? Stimmt die Vorhersage bei TIA V17 oder sollte man sich eine korrekte Berechnung von TIA V18 wünschen?

Ich muß jetzt an einer mit TIA V16 programmierten gelieferten Anlage mit CPU 1512SPF-1PN einiges zurechtbiegen und schaue deshalb alles genauer an.

Offline im Projekt prognostiziert TIA V16 eine Auslastung des Ladespeichers von 18% (ca. 2,2 MB), tatsächlich ist der Ladespeicher online 26% (ca. 3,2 MB) voll. (sagt TIA jedenfalls) :oops: Online/offline Vergleich zeigt aber alles grün (d.h. keine Unterschiede).

(1) Rechnet die Offline-Prognose tatsächlich so falsch? Oder wo könnte die ca. 1 MB höhere tatsächliche Belegung herkommen?
(2) Wie groß sind die 12MB-Speicherkarten wirklich? Tatsächlich 12.593.152 Bytes? Also 12 MB + genau 10 kB? Gibt Siemens da tatsächlich 10 kB mehr Speicher frei?

PS: die nur 3% Auslastung der E/A kommen davon, weil in dem Projekt auf alle 1900 E/A mit PEEK/POKE in Schleifen indirekt zugegriffen wird. :rolleyes:

Harald
 

Anhänge

  • Speicher_Projekt.png
    Speicher_Projekt.png
    35,2 KB · Aufrufe: 20
  • Speicher_online.png
    Speicher_online.png
    48,6 KB · Aufrufe: 21
Zuviel Werbung?
-> Hier kostenlos registrieren
Aha. Mit anderen Worten, das TIA bis V16 kann das überhaupt gar nicht richtig berechnen (kann TIA V17 das?). Nur wenn ich das Programm in eine "simulierte" SMC Memorycard lade, dann erhalte ich einen Wert der ungefähr an den tatsächlichen Ladespeicherbedarf (3.302.912 Bytes) herankommt, allerdings auch nicht ganz genau.
Aber wieso meint Siemens in dem FAQ, daß das SPS-Programm auf der realen SMC gleich viel Platz belegt wie auf meiner HDD (3.313.664 Bytes)? :unsure: :rolleyes:

Gut daß Raketensteuerungen nicht mit TIA programmiert werden, die würden am Mond vorbeifliegen. ;)


1900 E/As an ner 1512SP ???🤔
Tja, da bin ich schon wieder überrascht, was das TIA da "ausgerechnet" hat. Tatsächlich sind es nicht die von TIA als "Konfiguriert" angegebenen 1736 DE+DA, sondern 680 DI/DQ + 52 F-DI/DQ. Dazu kommen noch 18x G120C als Profinet-Drives, wenn ich die wohlwollend als 288 Bool-DQ zähle, komme ich auf 1020 Bool-DI/DQ. Wo TIA die noch fehlenden > 700 DE+DA wohl hernimmt??? Anscheinend sind in dem TIA die Farben der Listenhintergründe wichtiger als die Zahlen die da drin stehen. ;)

Übrigens sind in der Tabelle "Alle PLC-Variablen" gerade mal 88 Einträge. Das sind die Tags, die TIA da zwangsweise einträgt (z.B. 14 Systemmerker) und kein einziger Tag mehr... und die 660 E/A, die kein Tag haben, haben auch keine Querverweise, weil auf die per PEEK & POKE zugegriffen wird. 🤮
Beobachtungstabellen hat der gute Programmierer auch nicht gebraucht, jedenfalls ist in dem TIA-Projekt keine einzige drin.

Harald
 
Übrigens sind in der Tabelle "Alle PLC-Variablen" gerade mal 88 Einträge. Das sind die Tags, die TIA da zwangsweise einträgt (z.B. 14 Systemmerker) und kein einziger Tag mehr... und die 660 E/A, die kein Tag haben, haben auch keine Querverweise, weil auf die per PEEK & POKE zugegriffen wird. 🤮
Beobachtungstabellen hat der gute Programmierer auch nicht gebraucht, jedenfalls ist in dem TIA-Projekt keine einzige drin.

Harald
Das hört sich ehrlich gesagt nicht wirklich gut an. Wer schreibt solche Programme und wer nimmt die ab?
Auf die Zykluszeit wäre ich mal direkt gespannt, bitte um ein Update, wenn du mal real an der Anlage nachschaust. Anfassen würde ich mir wirklich gut überlegen und zumindest mit Gewährleitungsausschluß gut bezahlen lassen.
 
Ich würde mir wünschen, dass TIA endlich mal arbeiten würde, wie das Rockwell Pendant.
Das bedeutet meinem konkreten Wunsch nach, dass es nur noch eine bzw. zwei Dateien gibt, je geöffnetes Projekt.
Eine Datei ist dein Projekt und eine Datei ist eine Art Temp-Datei, die existiert, solange du das Projekt offen hast.
Der ganze, gestattet, Bloed$1nn, mit 19 Ordnern und 127 Dateien je Projekt hat damit ein Ende.
Man könnte das ja öffnebar behalten wie z.B. durch Änderung der Dateiendung von zap0815 zu zip.
 
Ich würde mir wünschen, dass TIA endlich mal arbeiten würde, wie das Rockwell Pendant.
Das bedeutet meinem konkreten Wunsch nach, dass es nur noch eine bzw. zwei Dateien gibt, je geöffnetes Projekt.
Eine Datei ist dein Projekt und eine Datei ist eine Art Temp-Datei, die existiert, solange du das Projekt offen hast.
Der ganze, gestattet, Bloed$1nn, mit 19 Ordnern und 127 Dateien je Projekt hat damit ein Ende.
Man könnte das ja öffnebar behalten wie z.B. durch Änderung der Dateiendung von zap0815 zu zip.
Ich würde mir das Gegenteil wünschen: Für jede Kleinigkeit eine eigene Datei in einem lesbaren Textformat und keine Binärdatei. Dadurch würde sich eine Versionierbarkeit über git o. ä. deutlich vereinfachen.

Diese konträren Wünsche nicht nur unter uns sondern bestimmt auch bei Siemens intern sorgen wahrscheinlich für einen wesentlichen Anteil am aktuellen Chaos.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde mir wünschen, dass TIA endlich mal arbeiten würde, wie das Rockwell Pendant.
Das bedeutet meinem konkreten Wunsch nach, dass es nur noch eine bzw. zwei Dateien gibt, je geöffnetes Projekt.
Eine Datei ist dein Projekt und eine Datei ist eine Art Temp-Datei, die existiert, solange du das Projekt offen hast.
Der ganze, gestattet, Bloed$1nn, mit 19 Ordnern und 127 Dateien je Projekt hat damit ein Ende.
Man könnte das ja öffnebar behalten wie z.B. durch Änderung der Dateiendung von zap0815 zu zip.
Warum eigentlich ? Was its das Problem damit ?
 
Warum eigentlich ? Was its das Problem damit ?

Kopiere mal fragmentierte Daten, also sagen wir ein solches Projekt mit 12MB von A nach B. Zum Beispiel auf einen alten USB 2.0 USB Stick der langsam arbeitet. Dass das Dateisystem jede einzelne Datei indizieren muss, braucht exponentiell länger, als wenn es eine Datei ist. Eine Datei ist handlich, viele kleine Dateien einfach nicht Zeitgemäß. Nennt man übrigens Container: Wird bei allen möglichen Projekten, Datein und vor allem bei Mediendateien gemacht.

Und der B.... mit dearchivieren, archivieren entfällt auch. Das macht man ja, damit die Projekte handlicher sind.
Schon mal mit Rockwell gearbeitet? Wenn ich heute was suche, das ich genau am 19.09. 2022 rausgeschmissen habe, mache ich einfach einen Doppelklick auf EINE sofort öffnebare Projektdatei von (vor) dem Datum, es geht auf, ich kopiere was ich brauche und mach wieder zu. Bei TIA muss ich entweder alles Dearchiviert da liegen haben oder das dearchivieren. Das klaut einfach Zeit und ist nervig, wenn man weiß, dass das auch anders geht. Eine sofort öffnebare Datei Pro Tag, Versionsstand oder sonstwas ist halt besser als je 107 Dateien und 23 Ordner pro Stand.

Ich würde mir das Gegenteil wünschen: Für jede Kleinigkeit eine eigene Datei in einem lesbaren Textformat und keine Binärdatei. Dadurch würde sich eine Versionierbarkeit über git o. ä. deutlich vereinfachen.

Diese konträren Wünsche nicht nur unter uns sondern bestimmt auch bei Siemens intern sorgen wahrscheinlich für einen wesentlichen Anteil am aktuellen Chaos.
Das wird nicht kommen. Wenn das lesbar wäre, könntest du auch ohne das TIA Portal programmieren. Das wird Siemens nicht machen. Sonst könnten wir alle direkt in xml (TIA Openess) oder C programmieren.
 
Das wird nicht kommen. Wenn das lesbar wäre, könntest du auch ohne das TIA Portal programmieren. Das wird Siemens nicht machen. Sonst könnten wir alle direkt in xml (TIA Openess) oder C programmieren.
Mit dem Begriff "lesbar" muss man ein wenig vorsichtig umgehen. Ich meine mit Lesbarkeit nur, dass die Datei nicht binär abgespeichert ist. Den XML-Bausteinexport von einem KOP-Baustein kann man ja so gesehen als Mensch auch nicht unbedingt lesen. Für Versionierungssysteme reicht das (als erster Schritt) aber aus. Um Änderungen besser zu verstehen, bräuchte man dann "nur" noch ein Tool zum Vergleich von Versionsständen, welches die XML Änderungen bspw. grafisch aufbereitet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kopiere mal fragmentierte Daten, also sagen wir ein solches Projekt mit 12MB von A nach B. Zum Beispiel auf einen alten USB 2.0 USB Stick der langsam arbeitet. Dass das Dateisystem jede einzelne Datei indizieren muss, braucht exponentiell länger, als wenn es eine Datei ist. Eine Datei ist handlich, viele kleine Dateien einfach nicht Zeitgemäß.
Dafür gibts doch die Archive???
Ich würd übrigens niemals ein Projekt als Ordner kopieren... weder in TIA noch in Classic. Da wird nicht nur gezippt...
 
Ich kopiere nur mittels archivieren/dearchiveren, und sehe das Problem nicht. Es stimmt, wenn man schnell ein Projekt öffnen will, dann gibt es einige Schritte die man sparen konnte. Aber ist kleinigkeiten. Nur meiner Meinung ;)
Es sollte für Siemens machbhar sein dass wenn man auf die .zapxx Datei klickt, dann wird es automatisch entpackt und in TIA geöffnet.
 
Nur eine letzte Kommentar. Wenn man die Trennung zwischen Projekt den man arbeitet mit und die Sicherungskopie entfernt, dann ist es komfortabler aber es gibt auch den Gefahr dass man ungewollt eine kleine Änderung macht, und die Sicherungskopie ist nicht mehr aktuell.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Zwischenschritte über dearchivieren/archivieren ist einfach überflüssig.
Wer mal, wie ich, zwei Jahre mit Siemens und Rockwell stereo arbeiten musste, versteht meinen Punkt.
Es ist einfach viel sauberer und vor allem schneller und zeitgemäßer.
Sowas wie mit anderen Plattformen Arbeiten empfehle ich sowieso gerne. Es hilft über den Tellerand hinaus zu gucken.
 
Nur eine letzte Kommentar. Wenn man die Trennung zwischen Projekt den man arbeitet mit und die Sicherungskopie entfernt, dann ist es komfortabler aber es gibt auch den Gefahr dass man ungewollt eine kleine Änderung macht, und die Sicherungskopie ist nicht mehr aktuell.
Das stimmt zwar, aber dafür gibts ein Ämderungsdatum und die Sicherrungskopie auf dem Server die jeder haben sollte.
 
Dafür gibts doch die Archive???
Ich würd übrigens niemals ein Projekt als Ordner kopieren... weder in TIA noch in Classic. Da wird nicht nur gezippt...
Technisch gesehen ist und bleibt das so eine Art zip. Es gibt auch in der Medienwelt viele Container, wie mp4, mkv, aac, m4a und wie sie alle heißen. Am Ende ist eine mkv (Filmdatei) wo Zip-Ähnlich, die Audiospur in AAC oder Dolby Dikital zusammen mit dem h264 encodierten Film drin liegt. Am Ende ist egal wie das Kind heißt, es ist ein Zusammenschluss von Daten, damit es weniger Dateien zu verwalten gibt.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben