TIA TIA Portal V18 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Zuviel Werbung?
-> Hier kostenlos registrieren
Leistungsgrenzen dieses Systems sind. Da fehlen denen tatsächlich die Erfahrungswerte und intern scheinen sie solche Tests wohl nicht zu machen oder scheuen sie sich, daraus belastbare Aussagen abzuleiten.


Bei einer einfachen Steuerung kann man das eventuell mal ausprobieren und wenn's nicht klappt, geht man zurück auf eine alte Steuerung.
Wenn man Maschinen mit über 50 Achsen hat, spielt man da ungerne herum.

Wir würden übrigens sehr gerne endlich die 1500er CPUs nutzen, denn erst dann gibt das TIA-Portal richtig Sinn, da viele neue Funktionen für 300er CPUs nicht nutzbar sind. Daher wäre die Weiterverwendung von irgendwelchem Uralt-Code kein Thema für uns. Genau von dem wollen wir uns ja trennen.
Wenn ihr mit NCU link arbeitet kommt ihr bei der ONE an Grenzen.
Aber der Maximal Ausbau der mit der 730 möglich ist kann die 1760 auch leisten , das sind dann 50 Achsen.
Die habe ich getestet mit und ohne Safety die Performens einer 730 mit 319 geht locker.
Ich habe aber auch noch keine Anforderung Einens Leistungstest auf dem Tisch gehabt > 50 Achsen .


auch mit der 300er macht TIA Sinn schon alleine aus dem Grund das der Programmierer zum Konsistenzcheck gezwungen wird.
 
Das ist ein Problem:
Anhang anzeigen 54955
Die Bausteine waren in dem Fall identisch, nur der compilierte Baustein nicht.

Aus irgendeinem Grund erzeugt der Siemens Compiler unterschiedliche Prüfsummen, auch wenn der Quellcode definitiv identisch ist.
In dem nächsten Beispiel unten sind sogar die Kommentare, Einrückungen und Leerzeichen identisch:
Anhang anzeigen 54952

Beim Vergleich des verwendeten Ladespeichers fällt auf, das die eine Funktion 7 Byte mehr braucht, warum auch immer.
Anhang anzeigen 54953
Das Problem beim Bausteinvergleich scheint also zu sein, dass Siemens dafür anscheinend keinen echten Quelcodevergleich macht, sondern irgendwie Prüfsummen generiert, die unterschiedlich sein können.
Dafür waren dann die Zieldaten identisch.
Hm, also ich haette jetzt eher gedacht, das bei gleichem Code die "Code ohne Kommentare"-Pruefsumme gleich ist. Und die "Uebersetzungs"-Pruefsumme irgendwie vom Zeitpunkt der Uebersetzung abhaengt oder sowas und daher immer unterschiedlich ist.

Nichtsdestotrotz kannst du zumindest das erste Problem rausfiltern, indem du die Vergleichskriterien abschaltest.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das ist ein Problem:
Anhang anzeigen 54955
Die Bausteine waren in dem Fall identisch, nur der compilierte Baustein nicht.

Aus irgendeinem Grund erzeugt der Siemens Compiler unterschiedliche Prüfsummen, auch wenn der Quellcode definitiv identisch ist.
In dem nächsten Beispiel unten sind sogar die Kommentare, Einrückungen und Leerzeichen identisch:
Anhang anzeigen 54952

Beim Vergleich des verwendeten Ladespeichers fällt auf, das die eine Funktion 7 Byte mehr braucht, warum auch immer.
Anhang anzeigen 54953
Das Problem beim Bausteinvergleich scheint also zu sein, dass Siemens dafür anscheinend keinen echten Quelcodevergleich macht, sondern irgendwie Prüfsummen generiert, die unterschiedlich sein können.
Dafür waren dann die Zieldaten identisch.
Vermutlich kann man Prüfsummen schneller aus der PLC laden als die kompletten Quelldaten. So eine PLC soll ja eigentlich auch ein Programm abarbeiten und IO-Daten und HMI-Daten verarbeiten. Wieviel da wohl für ein TIA-Portal übrig bleibt? (klar kommt das auf den Awendungsfall an, aber man wird hier vermutlich den Worst-Case betrachtet haben).
Und im TIA-Portal wird ja ein Baum dargestellt. D.h. der Knoten Programm-Bausteine muss die Vergleichswerte aller Bausteine kennen, bevor der einen eigenen Vergleichswert errechnen und anzeigen kann (wenn jetzt nur auf Grund der Quelldaten entschieden würde). Je nach Projekt kömmt da einiges zusammen.
 
Und im TIA-Portal wird ja ein Baum dargestellt.
Mit TwinCat 3.XX (XAE) ist der Vergleich nahezu perfekt. Man kann wunderbar vergleichen und die Änderungen von Quelle nach Ziel übernehmen. Warum SIEMENS hier einen umständlichen Zinober macht, ist mir unverständlich.
 
Irgendwie muß Siemens immer etwas neues eigenes erfinden für Probleme, für die es eigentlich schon seit Jahrzehnten bewährte Lösungen gibt. In die selbe Kategorie fällt vermutlich auch das immer noch nicht immer funktionierende nur-Änderungen-Übersetzen von WinCC flexible/TIA.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen, mal meine Wünsche für die Probleme die mich am meisten stören (Arbeite seit ca. 1 Monat mit V17, ist also aktuell):

1. Startdrive: Das Exportieren und Importieren von vorgefertigten Wertelisten (z.B. Kommunikation, Mechanik, Regelparameter) soll möglich sein, so wie im Starter auch. Serieninbetriebnahmen / Parameteränderungen von gleichen Antrieben dauern mittlerweile katastrophal lange :(

2. WinCC Advanced: Verbesserung der Performance beim Export/Import von Bitmeldungen in größerer Anzahl. Performanceverbesserung beim Scrollen durch Bitmeldungen - Nutzen vorhandener Grafik- und Prozessorressourcen am PG! Gerade in einem Multiuserprojekt dauert der Import von ca. 17k Bitmeldungen bis zu 30min. Außerdem nervt es gewaltig, dass sich eine Runtime-Simulation beim Umschalten/Einchecken ins Serverprojekt im Multiuser (oder umgekehrt) jedes mal schließt. Verlängerung der Inbetriebnahmezeit, da danach jedes Mal die Runtime übersetzt wird, auch wenn nichts geändert wurde.

PCT: Volle Integration ins TIA-Portal - Wo bleibt hier das „Totally-Integrated“ Konzept? Warum muss für das Online-Beobachten in PCT die TIA-Instanz blockiert werden? Kein einfaches Vergleichen möglich, katastrophal bei der Inbetriebnahme von schlecht dokumentierten IO-Link Geräten. Steht ja auch schon in #18.

TIA-Multiuser: Performanceverbesserung beim Einchecken - Bei größeren Änderungen sind die langen Wartezeiten absolut inakzeptabel. Diese verringern sich auch nicht beim Arbeiten im Serverprojekt. Außerdem sollte Wert darauf gelegt werden, dass alles auch in der lokalen Session bearbeitet und geändert werden kann - wo dies nicht möglich ist sollte entsprechend auch ordentlich visualisiert werden und dokumentiert sein. Die Anleitungen hierzu sind wirklich unvollständig, was erst recht wieder doppelte Arbeit nötig macht wenn vergessen wurde die Änderung im Serverprojekt zu machen. Generell ist die Performance im Multiuser gerade zur Softwareentwicklung bei größeren Projekten ziemlich mies. Ca. 80% programmieren, 20% Wartezeiten beim Einchecken und aktualisieren.

TIA allgemein: Seit V15.1 hatte ich nie mehr die Warnung „Verbrauch von Applikationsressourcen“. Seit V17 ist sie wieder da - SPITZE!!!

PS: Wenn wir Anwender des TIA Portals genauso unfertige Software auf den Markt werfen würden wie die Entwickler, wären wir wohl längst alle arbeitslos.. Einfach traurig sowas. Will keine Werbung für Rockwell machen, deren Software hat auch ihre Macken - aber zumindest arbeitet sie hoch performant und bremst mich nicht andauernd aus..
 
Zuletzt bearbeitet:
würde mir sowas wünschen für die nächsten Versionen


1.) Möglichkeit den durch das Lineal eingestellten Tabellenwert abzuspeichern

Ich hab eine Kurve realisiert mit einer Variablen (gespeicherte Werte über Zeitraum x) aus dem Variablen-Archiv,
unter der Kurvenanzeige imTP1200 Display habe ich eine Tabelle stehen.
kurve.jpg


Auf der Kurve kann ich mit dem Lineal hin und her schieben und kann bestimmte Werte auf denen das Lineal gerade steht unten in der Tabelle anzeigen / ablesen.


Es wäre ideal, wenn es zukünftig eine Möglichkeit gibt den aktuell mit dem Lineal eingestellten / angezeigten Wert aus der unten stehenden. Tabelle in der SPS zu speichern.

Grund / Ziel:
der Mitarbeiter soll am Display bei einer Archivkurve einen bestimmten Druckwert aus dem Druckverlauf mit Hilfe des Lineals ermitteln und dieser Wert auf dem das Lineal steht (im angehängten Beispielbild oben wären das 0,245bar) soll dann in einem DB gespeichert werden können. (z.b. nach klicken einer Schaltfläche)

2.) Nachommastellen der Tabelle:

Die Möglichkeit Nachkommastellen z.B. drei stellen der unter der Kurve stehenden Variablen Tabelle begrenzen zu können per Einstellung in der Tabelle in der WinCC Projektdatei. (hier im Bild wäre es dann 0,245)
 
würde mir sowas wünschen für die nächsten Versionen


1.) Möglichkeit den durch das Lineal eingestellten Tabellenwert abzuspeichern
Ob das "klassische" TIA HMI noch weiterentwickelt wird? Ich dachte der Weg soll hin zu WinCC Unified gehen, und da würde ich sagen da alles über HTML umgesetzt wird, wird der Wert auch irgendwo im DOM vorhanden sein, auf den man über Javascript zugreifen können sollte.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Interessant, was man alles noch lernen soll an Programmiersprachen, Umgebungen und gravierenden Änderungen, alles beherrschen soll und erwartet wird, dann aber mit zb 2500€ brutto bezahlt wird.
 
du vergisst die alten Produktions Anlagen die man ja bis runter zur S5 auch noch beherrschen soll... wegfallen wird da nichts
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo DennisBerger,

meiner Meinung nach ist deine Frage in diesem Zusammenhang falsch gestellt:

Wann geht es endlich in die Köpfe der Firmenchefs/Abteilungsleiter (aber auch die der Hersteller like Siemens etc.), dass die einzelnen Themengebiete der Automatisierung (SPS, HMI, Sicherheit, Antriebstechnik) immer umfangreicher werden und nicht von EINEM Programmierer vollumfänglich(!) beackert werden können?
Warum nicht Spezialisten an die jeweiligen Aufgaben heranlassen (z.B. bei HMIs: Webdesigner + Datenbankprogrammierer)?
Rechnet sich spätestens dann, wenn in den genannten Bereichen die Nachlaufkosten minimiert werden können, weil endlich mal richtige Entwicklungsarbeit geleistet werden könnte (und nicht EIN Mann jedesmal verheizt wird)!


Gruß, Fred
 
Nicht lustig 😁 .😊🙈

Era gebunden und Konzern.
Keine Chance.

Woanders anfangen möchte man auch nicht mehr ab bestimmten Alter, Haus und Familie.
In der jetzigen Zeit sowieso.
Spatz in der Hand und Taube auf dem Dach und so
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben