TIA TIA Portal V19 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Zuviel Werbung?
-> Hier kostenlos registrieren
:unsure:
Aber doch nur beim Übersetzen und nicht zur Laufzeit.
Beim Übersetzen des Bausteins kann er nicht wissen, wie er außen beschaltet sein wird. Und zur Laufzeit muß geprüft werden, ob der übergebene Parameter (z.B. Array) zu der übergebenen "Konstante" passt.
:unsure:
Beim Übersetzen des aufrufenden Bausteins ist doch bekannt, was dranhängt.
Muss ja bei Variablen auch geprüft werden, ob außen und innen zusammen passen.
Dann muss halt ggf. der aufgerufene Baustein noch einmal mit übersetzt werden (und es werden doch eh immer alle Änderungen im gesamten Programm übersetzt).

Und es sind immer noch Konstanten, die dann zwar von außen am Baustein hängen aber beim Übersetzen trotzdem bereits bekannt sind.
Warum muss dann erst zur Laufzeit geprüft werden, ob der übergebene Parameter (z.B. Array-Größe) zu der übergebenen "Konstante" passt?
Das Thema sollte dann doch IMHO beim Übersetzen und spätestens vor dem Laden abgehakt werden können?!
 
:unsure:
Beim Übersetzen des aufrufenden Bausteins ist doch bekannt, was dranhängt.
Muss ja bei Variablen auch geprüft werden, ob außen und innen zusammen passen.
Dann muss halt ggf. der aufgerufene Baustein noch einmal mit übersetzt werden (und es werden doch eh immer alle Änderungen im gesamten Programm übersetzt).

Und es sind immer noch Konstanten, die dann zwar von außen am Baustein hängen aber beim Übersetzen trotzdem bereits bekannt sind.
Warum muss dann erst zur Laufzeit geprüft werden, ob der übergebene Parameter (z.B. Array-Größe) zu der übergebenen "Konstante" passt?
Das Thema sollte dann doch IMHO beim Übersetzen und spätestens vor dem Laden abgehakt werden können?!

Hier muss aber noch geprüft werden ob das was außen am Baustein hängt verändert werden kann , sprich keine Konstante ist.
Man könnte hier nur globale Konstanten zulassen . (was aber 3 Wochen später hier wieder auftaucht, von wegen was soll das )

Ich könnte das Requirement an die Pinwand hängen aber dafür reicht die Begründung
Überhaupt einem FB eine Konstante von außen übergeben zu können, wäre wunderbar. So könnte man den gleichen FB auch mit einer variablen Anzahl von Ein- & Ausgängen aufrufen. Das wären dann zwar "Array_of_irgendwas" EAs, aber mit der Konstante kann man ja auch gleichzeitig ein Datentyp skalieren, der darauf passt. Da Konstanten gerade die einzige Möglichkeit sind, den Speicherbedarf wenigstens "Halbdynamisch" anzupassen.
nicht aus.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...aber dafür reicht die Begründung nicht aus.
Für mich wäre es das Kappseln von Bausteinen insbesondere im Hinblick auf Bibliotheken:
Sprich, man hat eine rein lokale Konstante mit deren Symbol im Baustein gearbeitet wird, und der Wert dieser Konstante wird von außen durch einen Festwert bzw. globale Konstante bestimmt, um z.B. bei verschiedenen gekappselten Bausteinen trotzdem die gleiche globale Konstante vorgeben zu können.

Man könnte hier nur globale Konstanten zulassen. (was aber 3 Wochen später hier wieder auftaucht, von wegen was soll das )
Sollen ja immer noch Konstanten bleiben.
 
Wie würde das dann mit den Instanz-DBs aussehen ? Wenn ich eine Konstante über die Schnittstelle übergebe, und mit dieser zum Beispiel die Größe eines Arrays in Static festlege, dann bräuchte ich ja für jede vorkommende Größe einen eigenen Prototyp für den DB. Vielleicht ist das doch gar nicht so schnell gemacht für die Entwickler ?

Eine schöne Funktion wäre es auf jeden Fall.
 
Ja, Ausschneiden in allen Editoren wäre schön.
Gleiches Handling von strukturierten Variablen in Graph wie in den anderen Editoren vermisse ich auch: Wenn ich in Graph eine übergeordnete Bezeichnung im Variablennamen ändere und Enter drücke wird die Variable nur bis dahin übernommen und der Rest ist weg. In den anderen Editoren bekomme ich wieder eine vollständige Variable.
In der Projektbibliothek eine funktionierende Verweisliste, wo welche Version eines Typs noch verwendet wird. Bei mir ist die fast immer leer.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Beim Übersetzen des Bausteins kann er nicht wissen, wie er außen beschaltet sein wird. Und zur Laufzeit muß geprüft werden, ob der übergebene Parameter (z.B. Array) zu der übergebenen "Konstante" passt.
Einen Baustein nur für sich zu übersetzen ist dann tatsächlich nicht mehr möglich. Es sollte aber alles beim Übersetzen zu lösen sein. Wüsste nicht was dann noch für Probleme zur Laufzeit auftreten könnten. Der Datentyp wurde ja schon vor dem Übersetzen festgelegt.

Wie würde das dann mit den Instanz-DBs aussehen ? Wenn ich eine Konstante über die Schnittstelle übergebe, und mit dieser zum Beispiel die Größe eines Arrays in Static festlege, dann bräuchte ich ja für jede vorkommende Größe einen eigenen Prototyp für den DB. Vielleicht ist das doch gar nicht so schnell gemacht für die Entwickler ?
Genau, jeder Instanz-DB/Multiinstanz könnte in der größe variieren. Er hätte jedoch immer die gleichen Grundelemente nur mit unterschiednlichen Arraygrößen.

Hier muss aber noch geprüft werden ob das was außen am Baustein hängt verändert werden kann , sprich keine Konstante ist.
Man könnte hier nur globale Konstanten zulassen . (was aber 3 Wochen später hier wieder auftaucht, von wegen was soll das )
Es Muss einfach eine Konstate sein, ob Global, Lokal oder einfach nur ein geschriebener wert sollte egal sein.

Ob das für Siemens einfach oder schwer umzusetzen ist, mit ihrer Architektur im Hintergrund, weiß ich nicht. Aber es sollte von der Logik her möglich sein.
 
bevor das hier abschweift:
- SPS: Änderung von HW-Konfig ohne CPU-Stop
- SPS: einfacher Online/Offline Vergleich über wirklich alles
- HMI: Online/Offline Vergleich
- HMI: funktionierendes Änderungsübersetzen bzw. schnelleres Gesamtübersetzen
- HMI: Anzeige einer eindeutigen VersionsID mit Vergleichsmöglichkeit im Projekt und im HMI
- SPS: kein Reinitialisieren von DBs
- weniger Versionswirrwar
- längere Produktlebenszyklen

Wie willst du denn ein HMI sinnvoll Online/Offline vergleichen? Bestenfalls kann man auf Gleichheit prüfen, aber was hilft das?
 
Ich würde sagen, dann muss
Ja, natürlich. Mit "dann könnte man" meinte ich eigentlich "dann könnte man einfacher"...

Aktuell geht das nur händisch durch Vergleichen der Bilder.
Das ist mühsam und sicher kann man sich dann auch nie sein, ob die Variablen passen. Skripte kann man auch nicht prüfen...

Und durch Plausibilisieren des Zeitstempels der pdata.fwc
Nur, falls der Zeitstempel nicht passt, dann hat Mal halt ein Problem. Und leider wird eine saubere Datenablage noch von zu vielen vernachlässigt.
 
Zuletzt bearbeitet:
Ich hätte gern ein Versionshändling. Startprogramm speichern als Version 0, dann Änderungen speichern als Version 1, Änderungen speichern als Version 2 usw. Am Ende dann die Möglichkeit für einen Vergleich der Versionen und diesen dann als pdf in Listenform ausgeben.
 
Offline und Online Datenhaltung wird mit Unterschieden angezeigt, weil der Zeitstempel unterschiedlich ist. Die Daten sind aber identisch. Der Leuchtmelder in der Projektnavigation bei lokale Module ist dann nicht mehr grün. Man kann den Leuchtmelder aber nicht in grün umändern, indem man z.B. versucht die Hardware zu übertragen. Dieses wird mit dem Hinweis abgelehnt, das die Daten offline und online identisch sind.

Also ich finde, entweder der Leuchtmelder in der Projektnavigation bleibt grün, auch wenn der Zeitstempel unterschiedlich ist, oder aber man kann durch das Übertragen identischer Daten den Zeitstempel offline und online anpassen und dadurch den Leuchtmelder in grün umändern. Bestenfalls ohne CPU stopp.
 
Mit TIA V19 alle alten TIA Versionen öffnen können,
und dann auch mit einer CPU online gehen
die mit einer älteren Version vom TIA Portal programmiert wurde.
Habe mittlerweile 9 TIA Versionen auf meinem Rechner weil nix zusammenpaßt. :confused:

Das ist wirklich das schlimmste. Kommst auf die Baustelle (als Nothelfer) und das Projekt ist V10.5
Herzlichen Glückwunsch
 
Ich würde mir wünschen dass man beim OPC UA Server nicht jede Variable einzeln anklicken muss um mit einer Dropdown Auswahl read/write einzustellen. Wenn man dann in einem DB eine Variable hinzufügt muss man den kompletten DB neu ins OPC Interface ziehen, was alle read/write Berechtigungen wieder zurücksetzt. Das Sahnehäubchen ist aber dass die Zugriffsstufe in Tabellarischer Form angezeigt wird, aber nicht bearbeitet werden kann. Bei einem DB mit 100 Variablen kommt jedes mal Freude auf jede einzelne anzuklicken und einzustellen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt Programmiersprachen wo man sich überhaupt nicht mehr um die Speicherhaltung kümmern muss. Da wird zur Laufzeit so viel angelegt wie das Programm fordert.
Ah, die Systeme bei denen Anwendungen irgendwann langsamer werden und manchmal in einem Absturz enden? Ich kann mir nicht vorstellen, dass damit jemand eine Software entwickeln will, die unbedingt 10 Jahre ohne einen Neustart laufen muss.
 
Ah, die Systeme bei denen Anwendungen irgendwann langsamer werden und manchmal in einem Absturz enden? Ich kann mir nicht vorstellen, dass damit jemand eine Software entwickeln will, die unbedingt 10 Jahre ohne einen Neustart laufen muss.
Welcher Programmiersprache soll der Seitenhieb gelten? Gibt es dafür Evidenz? Ich denke nicht, dass das ein generelles Problem solcher Programmiersprachen ist.
Python wäre ein prominentes Beispiel. Wenn es ein Langzeit-Problem gäbe, würden die Entwickler es sicherlich beheben, wenn es bekannt wird. Man kann sich natürlich aus Unwissenheit beim programmieren irgendwelche Überläufe einfangen, aber dafür kann die Sprache nichts.
Was man der Programmierweise vorwerfen kann, ist, dass sie nicht sehr effizient ist. Aber das sollte bei der heutigen Rechenleistung einfach keine Rolle mehr spielen.

Nicht ohne Grund wird der Ruf nach Hochsprachen in der Automatisierung immer lauter und Python ist die beliebteste Programmiersprache.
Deshalb sehe ich den Weg bereits vorgezeichnet. Die Zeiten, in denen ein Entwickler noch jedes Bit auswendig kennen muss, sind einfach vorbei.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben