TIA TIA Portal V18 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Die sollen doch erst mal V16 fertigmachen. MOM habe ich 4 Versionen nur Tia laufen. Dann gibst ja aber auch noch andere Hersteller. MOM Frust pur
 
Die sollen doch erst mal V16 fertigmachen. MOM habe ich 4 Versionen nur Tia laufen. Dann gibst ja aber auch noch andere Hersteller. MOM Frust pur
Hab mittlerweile mehr als 30 VMs für alles mögliche... So ist halt die schöne neue Zeit. Da wird nix fertig gemacht. Mittlerweile wird abgekündigt bevor Bugs behoben werden. Und wenn dann mal zufällig was funktionierendes da ist, wird erstrecht abgekündigt...
Früher hast nen neues Automodell erst nach 2 Jahren gekauft, da waren dann Kinderkrankheiten ausgemerzt. Heut gibts das Modell nach 2 Jahren schon nicht mehr.
Ich weiss nicht, es geht vieles in die falsche Richtung, nur wie will man sich wehren?
Das einzige was Du tun kannst, mit Deiner eigenen Arbeit dieses Spiel nicht mitzuspielen, und allen Widrigkeiten zum trotz hochwertige und langlebige Arbeit abzuliefern.
 
Das wäre mit den Updates auch nicht das große Problem, wenn sich die neue TIA Version so wie ein Step7 Update verhalten würde. D.h. eine Version reicht mit der ich alles machen kann. Für die neuesten Baugruppen wird eben die aktuelle Version benötigt.

Aber es funktioniert ja nicht einmal ein Copy&Paste einfachster Elemente zwischen den TIA Versionen, wenn man z.B. einen kleinen Codeschnippsel aus einem anderen Projekt kopieren will, muss man das ganze Projekt hochrüsten. Und etwas aus neueren Versionen in ein älteres TIA Projekt zu übernehmen, ist überhaupt nicht möglich. Da ist schon von Vorteil wenn in SCL programmiert wurde, dann lässt sich wenigstens etwas über Textdateien austauschen, zumindest der reine Code.
 
Es geht nicht darum, eine Beobachtungstabelle zu öffnen oder neu anzulegen (wobei das aber schon das Fremd-Projekt verändern würde). Das TIA läßt Dich gar nicht %EB100 oder %E137.4 eintippen, wenn es dafür noch kein Symbol gibt. (hab' ich jedenfalls so in Erinnerung)

Harald
Natürlich kannst du das! Der Tag hat dann nur standartmäßig den Namen "Tag_1" etc. Den kannst du aber ohne in die Symboltabelle gehen zu müssen sofort umbennenen.
Du kannst sogar eine Adresse verwenden, welche in der Hardware noch nichtmal parametriert wurde ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
V16 war für Unified gedacht, funktionierte damit allerdings
nicht und auf V17 sollte dann Unified nutzbar sein, ist es
aber in Wirklichkeit auch noch nicht, wer es nutzt ist eigentlich
leichtsinnig.
V17 zum PLC programmieren funktioniert einwandfrei, läuft stabil aber etwas langsamer als die V15.1 (V16 hab ich übersprungen). Hab mittlerweile etliche V17 Projekte bei Kunden in Betrieb, ohne Probleme.

V17 Unified ist nach wie vor eine einzige Katastrophe, hab kurz reingeschnuppert und sofort wieder verworfen, da fehlt zuviel essentielles. Da wäre es ja einfacher, man bastelt sich mit Java oder unter .net seine eigene Visu..

V17 Startdrive ist eigentlich mein größter Kritikpunkt: Völlig unübersichtlich, wenn man den alten Starter gewöhnt ist. Und immer noch fehlen wichtige Funktionen für Serieninbetriebnahmen von gleichen Antrieben, wie z.B. Parameterlistenimport etc. Meine persönliche Meinung: Wer sich sowas wie diese Software freiwillig antut, steht entweder auf repetitive Arbeiten oder ist zumindest Hobbymasochist :D
 
Hm, ich weiß nicht ob schonmal wer die Idee hatte bzw. oder ob ich mich mit der Idee hier unbeliebt mache ... aber weil ich gerade bei einem Fremdprojekt ein wenig darüber kotze:
Könnten wir es einrichten, dass die SPS und die HMIs Arrays - allgemein, aber auch speziell in Mulitplexvariablen - gleich behandeln? HMI fängt immer bei 0 an, SPS bei ... wasauchimmer mal angelegt hat. Ich bin hoffentlich nicht der Einzige, der da hin und wieder darüber stolpert!
Bin offen, welche Seite sich da ändert/anpasst! Hab kein Problem damit, dass ich nen Fehler in der SPS bekomme wenn ich einen Array[5..8] anlege und ich einen Array[8] beschreiben möchte!
 
ja, SPS-Arrays halt auch immer bei 0 beginnen lassen... Kostet ja jetzt nicht Unsummen...
Es gibt aber auch sinnvolle Situationen, in denen ein Array nicht bei 0 anfängt.
Trotzdem stimme ich grundsätzlich zu, ein Array immer bei 0 beginnen zu lassen.

Speziell für das HMI fällt mir gerade nicht ein, wann es hilfreich ist, ein Array nicht bei 0 beginnen zu lassen.
@Geisterkarle könntest Du ein Beispiel nennen?

VG

MFreiberger
 
Es geht nicht um hilfreich, sondern ein wenig "Verwirrung".

Nehmen wir mal ein etwas dummes Beispiel an:
ich hab ein Array [1..8] of REAL in der SPS und ich speichere 8 Temperaturen da rein.
Habe diesen Array als Mulitplexvariable im HMI angelegt. Und nun möchte ich das jemand im HMI mit einem Eingabefeld eine Temperatur zum Anzeigen auswählen kann. Ich kann hier nicht einfach den Eingabewert nehmen, denn wenn jemand die Temperatur 3 sehen möchte, dann muss ich in meine Multiplexvariable 2 schreiben!
Aber auf SPS Seite sieht das natürlich schöner aus, wenn man Temperatur_1 in Array[1] schreibt. Aber eigentlich ist das ja für das HMI Array[0].
Klar, man könnte das Array in der SPS [0..8] machen. Aber das das überhaupt geht ist ja im Prinzip der Punkt!
Das
Array[1] bei array[0..8]
und
Array[1] bei array[1..8]
etwas an eine andere Stelle schiebt ist eigentlich Programmiertechnisch bescheuert!

Gebe ja zu, das nutze ich ja auch selbst. Vor der Einführung von optimierten Bausteinen (oder wenn ich einen Offset benötige) habe ich gerne Reservebereiche in DBs gerne mal als "Reserve_80 - Array[80..99]" oder sowas gemacht. Gibt besseren Überblick. Das könnte ich dann nicht mehr.

Ansonsten gilt ja:
Es gibt zwei Arten von Programmieren:
1. die ihre Arrays mit 1 anfangen
und
1. die ihre Arrays mit 0 anfange

;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das
Array[1] bei array[0..8]
und
Array[1] bei array[1..8]
etwas an eine andere Stelle schiebt ist eigentlich Programmiertechnisch bescheuert!
Da schiebt doch nichts. Wenn man einen anderen Datentypen deklariert (Array[0..8] statt Array[1..8] (wobei sich ja da sogar noch die Größe ändert)), ist das wie DWORD <> REAL. Auch da haben die Bits andere Bedeutungen.
Du hast doch die Freiheit, ein Array[1..8] anzulegen, um mit Temperatur_1 in Index 1 zu schreiben. Dass das nicht das gleiche, wie bei Array[0..8] (wobei sich hier gehörte Array[0..7] zu schreiben!!!) sein kann, ist doch logisch!

Aber das eigentliche "Problem" von Dir ist ja, dass das HMI JEDES Array bei Index 0 startet. Egal, wie der Startindex in der SPS lautet. Das kann man zwar diskutieren. Aber ich halte die Lösung, einfach ein größeres Array ([0..8]) zu nehmen, für einen gangbaren Weg.


VG

MFreiberger
 
Zuletzt bearbeitet:
Ansonsten gilt ja:
Gilt das wirklich?
Es gibt zwei Arten von Programmierern:
1. die ihre Arrays mit 1 anfangen
na, hoffentlich nicht.
und
12. die ihre Arrays mit 0 anfangen
So sollte es sein.

Ein Array, das mit ungleich 0 anfängt sollte die Ausnahme bleiben und nur bei speziellen Themen (Deine vorgeschlagenen Platzhalter, um die Offsetadresse kenntlich zu machen) eingesetzt werden.

VG

MFreiberger
 
Ein Problem ist es nicht, also ... mal ganz einfach:
Ich möchte das Siemens diese Array-Deklarierung, die wir aktuell haben, komplett wegschmeißt und wir "Array[5] of INT" usw. machen. Array mit 5 Integern. Fertig.
Und im Prinzip wäre _das_ die Frage, ob ich mir mit dieser Idee Feinde hier mache!

Im übrigen akzeptiere ich das fehlende r und n; die 2. bedeutet aber, dass du den "Scherz" nicht verstanden hast ;)
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben