TIA TIA Portal V18 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn der Vergleichseditor auf ist und man was reinladen möchte wäre es schön wenn man direkt benachrichtigt würde bzw. man aus dem Laden Dialog den Vergleicheditor schließen könnte. Und nicht nochmal "alles" von vorne machen müsste.
 
Für Schaltflächen des HMI wäre es IMHO mal ganz nett, wenn Siemens denen noch ein Ereignis "Halten" (o.ä.) spendieren würde.
Dazu eine einstellbare Zeit, wie lange das Halten der Schaltfläche sein muss, um dieses Ereignis auszulösen.

So könnte man einfacher (und vor allem ohne Code in der SPS) zwischen kurzen und langen Tastendrücken unterscheiden, um z.B. bei Reset-Tastern zwischen versehentlichem und bewussten Drücken unterscheiden zu können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für Schaltflächen des HMI wäre es IMHO mal ganz nett, wenn Siemens denen noch ein Ereignis "Halten" (o.ä.) spendieren würde.
Dazu eine einstellbare Zeit, wie lange das Halten der Schaltfläche sein muss, um dieses Ereignis auszulösen.

So könnte man einfacher (und vor allem ohne Code in der SPS) zwischen kurzen und langen Tastendrücken unterscheiden, um z.B. bei Reset-Tastern zwischen versehentlichem und bewussten Drücken unterscheiden zu können.
Wobei ich es schon oft gesehen habe, dass dafür das Ereignis "Drücken" verwendet wird. "Klicken" ist hier vermutlich angebrachtet, zumindest bei anderen Windows Programmen ist es so, dass wenn ich auf einen Button mit der Maus drücke, und dann bei gedrücktem Maustaster den Zeiger zur Seite ziehe, ein "Klick" nicht ausgelöst wird. Ich denke auf den Panels ist das ebenso ausgeführt, damit dann ein "aus Versehen Wisch" nicht zum "Klick" führt.
 
Wobei ich es schon oft gesehen habe, dass dafür das Ereignis "Drücken" verwendet wird. "Klicken" ist hier vermutlich angebrachtet, zumindest bei anderen Windows Programmen ist es so, dass wenn ich auf einen Button mit der Maus drücke, und dann bei gedrücktem Maustaster den Zeiger zur Seite ziehe, ein "Klick" nicht ausgelöst wird. Ich denke auf den Panels ist das ebenso ausgeführt, damit dann ein "aus Versehen Wisch" nicht zum "Klick" führt.
Ja, das mache ich auch so.

Aber gegen versehentliches kurzes Drücken hilft das auch nicht, da dann trotzdem beide Ereignisse ausgelöst werden, wenn der Benutzer nicht daran denkt, von der Schaltfläche runter zu schieben. Und bei Versehen geht die Wahrscheinlichkeit dafür doch eher gegen Null.

Daher nehme ich bei solch für mich relevanten Sachen momentan entweder einen Timer in der SPS, damit die Taste min. soundso lange betätigt werden muss, oder ein extra PopUp als Nachfrage "Willst Du das wirklich?".
Beides ist für ein bißchen Sicherheit doch relativ aufwendig. Ersteres ist manchmal auch noch Einiges an Hin und Her zwischen SPS und HMI.
😔
 
Zuletzt bearbeitet:
Ich weiß nicht, ob es schon erwähnt wurde, aber ich würde mir wünschen, dass die Funktionen UPPER_BOUND und LOWER_BOUND auch statische Arrays verarbeiten können. Aktuell kommt da die Fehlermeldung, dass das Array nur variable Grenzen haben darf.
Natürlich kann man die Ober und Untergrenzen durch Konstanten festlegen.

Ärgerlich ist es halt trotzdem dann, wenn die Kundenanforderung darin besteht, statisch definierte Arrays zu verwenden. Hatte heute den Fall, dass sich die Array Größe aufgrund nachträglicher Änderungen um 50 Elemente reduziert hat. Hatte somit ca 4-5 Stellen zu kontrollieren, um nicht die Array Grenzen zu verletzen und die PLC im laufenden Betrieb in den Stop zu bringen.

Würden die Funktionen auch feste Array Grenzen akzeptieren, könnte man einige Flüchtigkeitsfehler wieder automatisiert ausschließen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Natürlich kann man die Ober und Untergrenzen durch Konstanten festlegen.

Ärgerlich ist es halt trotzdem dann, wenn die Kundenanforderung darin besteht, statisch definierte Arrays zu verwenden.
:unsure:
Konstanten sind doch statisch?!


Trotzdem sinnvoller Wunsch.
 
:unsure:
Konstanten sind doch statisch?!


Trotzdem sinnvoller Wunsch.
Sorry, hab mich da etwas unverständlich ausgedrückt^^ Der Kunde hat eine Schnittstellensoftware die eine externe Quelle generiert, in der eben die Array Grenzen mit Zahlenwerten angegeben sind. Da ich den Datentyp der Quelle nicht verändern darf, kann ich da leider auch keine Konstante einsetzen und muss die Grenzen in meinem Programm händisch an die Vorgabe anpassen.
 
Sorry, hab mich da etwas unverständlich ausgedrückt^^ Der Kunde hat eine Schnittstellensoftware die eine externe Quelle generiert, in der eben die Array Grenzen mit Zahlenwerten angegeben sind. Da ich den Datentyp der Quelle nicht verändern darf, kann ich da leider auch keine Konstante einsetzen und muss die Grenzen in meinem Programm händisch an die Vorgabe anpassen.
Ich kann dein Problem nicht nachvollziehen. Upper Lowerbound ist doch nur für die übergabe unbekannter Arrays an einer Bausteinschnittstelle mit array[*] zu verwenden. Das übergebene Array selber ist doch trotzdem statisch ob mit zahlen oder Konstanten definiert ist doch irrelevant.
Dynamische Arrays gibts soweit ich weiß, sowieso keine.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich kann dein Problem nicht nachvollziehen. Upper Lowerbound ist doch nur für die übergabe unbekannter Arrays an einer Bausteinschnittstelle mit array[*] zu verwenden. Das übergebene Array selber ist doch trotzdem statisch ob mit zahlen oder Konstanten definiert ist doch irrelevant.
Dynamische Arrays gibts soweit ich weiß, sowieso keine.
Er bekommt das Array über einen PLC-Datentyp vom Kunden vorgegeben und bearbeitet es in seinem Code über Schleifen.
Ändert der Kunde seinen udt, muss er den Code momentan per Hand nach Verwendung der Array-Grenzen durchsuchen.
Mit L/U-Bound würde sich das automatisch anpassen.


Ich würde in seinem Code trotzdem Konstanten für die Verwendung der Arraygrenzen einsetzen, auch wenn sie nicht für die Arraydeklaration selbst verwendet werden können. So muss bei Änderung des udt durch den Kunden der eigene Code auch nur an einer Stelle angepasst werden.
 
Kann der Kunde nicht auch mitteilen/mitgeben, wieviele Einträge sein Array hat? Und den Wert übergibst Du Deinem Auswerte-Code? Oder noch ein Ende-Kennzeichen vereinbaren und mitgegeben, dann kann der Empfänger das Ende selber feststellen.
 
Man könnte dafür eine FC spendieren. Innerhalb ein Array[*] of xyz (ich hoffe der Datentyp ändert sich nicht?). Darin UPPPER- und LOWER_BOUND verwenden und die Ober- und Untergrenze dann ausgeben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man könnte dafür eine FC spendieren. Innerhalb ein Array[*] of xyz (ich hoffe der Datentyp ändert sich nicht?). Darin UPPPER- und LOWER_BOUND verwenden und die Ober- und Untergrenze dann ausgeben.
Man könnte auch einfach die Funktion UPPER_BOUND und LOWER_BOUND für Arrays freigeben die nicht über Variablen definiert werden. Dann kann man sich als Programmierer angewöhnen die Grenzen eines Arrays grundsätzlich über diese Funktionen zu ermitteln um niemals das Problem einer Grenzüberschreitung zu haben.
Das man das ganze über Umwege lösen kann oder über Konstanten nur an einer Stelle gesammelt ändern muss ist mir klar. Würde man aber die Funktionen für oben genannte Arrays ebenfalls freigeben und nicht statt dessen einen Fehler generieren, würde man sich wieder einiges an "Handarbeit" sparen.
 
Kann der Kunde nicht auch mitteilen/mitgeben, wieviele Einträge sein Array hat? Und den Wert übergibst Du Deinem Auswerte-Code? Oder noch ein Ende-Kennzeichen vereinbaren und mitgegeben, dann kann der Empfänger das Ende selber feststellen.
Das kann ich direkt im DB sehen der mir aus der Quelle generiert wird. Aber als Automatisierer habe ich irgendwie den Drang händische Anpassungen automatisieren zu wollen^^ -> Funktion liest mir Array Grenze aus und begrenzt mir meine Pointer oder FOR-Schleifen oder was auch immer.
 
Man könnte auch einfach die Funktion UPPER_BOUND und LOWER_BOUND für Arrays freigeben die nicht über Variablen definiert werden. Dann kann man sich als Programmierer angewöhnen die Grenzen eines Arrays grundsätzlich über diese Funktionen zu ermitteln um niemals das Problem einer Grenzüberschreitung zu haben.
Das man das ganze über Umwege lösen kann oder über Konstanten nur an einer Stelle gesammelt ändern muss ist mir klar. Würde man aber die Funktionen für oben genannte Arrays ebenfalls freigeben und nicht statt dessen einen Fehler generieren, würde man sich wieder einiges an "Handarbeit" sparen.
Klar hast Du da Recht.

Aber die Frage ist ja, ob man die Zeit hat, um auf eine Lösung von SIEMENS zu warten oder ob man einfach mit den gegebenen Mitteln einen Workaround findet.

Aber, wo wir schon dabei sind: Die Anzahl an ArrayElementen kann ich ja ermitteln. Aber wie kann ich die Größe in Byte herausfinden?

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man könnte auch einfach die Funktion UPPER_BOUND und LOWER_BOUND für Arrays freigeben die nicht über Variablen definiert werden.
Das finde ich auch. Warum nicht diese beiden Funktionen für alle Arrays freigeben? Sind diese Funktionen denn sooo Ressourcen- und Performance-fressend, dass man einen Horror vor einem Gebrauch der Funktionen haben muss?
 
Das kann ich direkt im DB sehen der mir aus der Quelle generiert wird. Aber als Automatisierer habe ich irgendwie den Drang händische Anpassungen automatisieren zu wollen^^ -> Funktion liest mir Array Grenze aus und begrenzt mir meine Pointer oder FOR-Schleifen oder was auch immer.
Wenn Du die vom Kunde verwendete Arraygröße "sehen" kannst, wieso muß Dein Programm da noch manuell angepasst werden? Du brauchst doch dem Programm nur als variabler Parameter mitgeben was Du "siehst". Um mit zur Laufzeit unterschiedlich großen Arrays zu arbeiten braucht man UPPER_BOUND und LOWER_BOUND nicht, die Werte können auch als Parameter mitgegeben werden. Hmm, wie haben wir früher nur sowas programmiert, als UPPER_BOUND/LOWER_BOUND noch gar nicht erfunden waren... :unsure: ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn Du die vom Kunde verwendete Arraygröße "sehen" kannst, wieso muß Dein Programm da noch manuell angepasst werden? Du brauchst doch dem Programm nur als variabler Parameter mitgeben was Du "siehst". Um mit zur Laufzeit unterschiedlich großen Arrays zu arbeiten braucht man UPPER_BOUND und LOWER_BOUND nicht, die Werte können auch als Parameter mitgegeben werden. Hmm, wie haben wir früher nur sowas programmiert, als UPPER_BOUND/LOWER_BOUND noch gar nicht erfunden waren... :unsure: ;)
Wie genau soll ich dem Programm denn mitgeben, was ich "sehe"? Sofern ich dafür irgendwas an Code zurechtschreiben muss hab ich doch nur wieder eine redundante Lösung zur eh schon vorhandenen Funktion LOWER_BOUND und UPPER_BOUND.
 
Das kann ich direkt im DB sehen der mir aus der Quelle generiert wird. Aber als Automatisierer habe ich irgendwie den Drang händische Anpassungen automatisieren zu wollen^^ -> Funktion liest mir Array Grenze aus und begrenzt mir meine Pointer oder FOR-Schleifen oder was auch immer.
Der "Drang" lässt zum Glück mit dem Alter nach ;)
Wenn man mal n bissl was erlebt hat, regt man sich über solche Kleinigkeiten icht mehr auf, sondern machst einfach so, dass es funktioniert und gut ;)
 
Aber, wo wir schon dabei sind: Die Anzahl an ArrayElementen kann ich ja ermitteln. Aber wie kann ich die Größe in Byte herausfinden?
Ja, DU kannst das! Aber Siemens hat anscheinend Schwierigkeiten damit.
Habe gestern mal in der von Harald verlinkten 127.795 KB pdf gestöbert.
ScalarProduct_FC.jpg
Da kräuseln sich mir die NackenHaare.
1.) Zeile 4 ist identisch mit Zeile 3.
Da werden also nur die unteren Array-Grenzen von Vektor1 und Vektor2 und die obere Grenze nur von Vektor 1 - dafür aber doppeltgemoppelt - abgefragt.
Nun gut, ein TippFehler bzw. ein erfolgreich-"gecopied"-und-"gepasted"-aber-dann-nicht-zuende-bearbeitet-Fehler. Schwamm drüber.
2.) Wenn der Sinn der Mimik ist, zu prüfen, ob die Anzahl der "Koordinaten" der beiden Vektoren gleich ist, warum prüft man das denn dann nicht?
Warum prüft man stattdessen nur den Sonderfall, dass die Nummern der AnfangsKoordinaten und auch die Nummern der End-Koordinaten beider Vektoren gleich sind?
Wenn wirklich nur die Anzahl der Koordinaten gleich sein muss, warum programmiert man die Mulitiplikations- und SummenBildungsSchleife dann nicht gleich richtig, statt sie auf den Sonderfall zu beschränken?
3.) Warum wird als Kennzeichen dafür, dass die Vektoren nicht zueinander passen, der Wert -1 als Ergebnis geliefert? Das wäre einfach und sinnvoll, wenn die "richtigen" Ergebnisse nur positiv sein könnten. Aber das sehe ich in dem gegebenen Beispiel nicht als gegeben.

Hmm, wie haben wir früher nur sowas programmiert, als UPPER_BOUND/LOWER_BOUND noch gar nicht erfunden waren... :unsure: ;)
Wir waren früher nicht so verwöhnt. ;) Erfunden sind UPPER_BOUND und LOWER_BOUND schon länger. Siemens hat sie recht spät erst in einer stark eingeschränkten Version neu erfunden, statt sie einfach zu übernehmen, nämlich für alle Arrays anwendbar.

Wie genau soll ich dem Programm denn mitgeben, was ich "sehe"? Sofern ich dafür irgendwas an Code zurechtschreiben muss ...
Du könntest, wie schon mehrfach beschrieben, an zentraler Stelle Deines Programms, die/den Parameter ändern, auf die/den Dein darauf ausgelegter ProgrammCode an zig Stellen zugreifen kann.
... hab ich doch nur wieder eine redundante Lösung zur eh schon vorhandenen Funktion LOWER_BOUND und UPPER_BOUND.
"Eh schon vorhanden" ist ja noch nicht gegeben, darum hast Du ja hier Deinen Wunsch geäussert.
Ich habe keine Ahnung, wie und wo Siemens die Dimensionierung der Arrays hinterlegt. Dass diese Informationen nach dem Compilieren in der Steuerung zur Laufzeit des Programms nicht mehr vorhanden sind, sondern erst mühsam/aufwändig rekonstruiert werden müssten, mag ich nicht wirklich annehmen/glauben.
Was spräche also dagegen die beiden Funktionen auf alle Arrays anwenden zu lassen? Aus meiner Sicht nichts.
Selbst wenn man die Anwendung auf nicht-A(*)-Arrays für unnötig oder "unnötig verführerisch" halten sollte.
Absolut unnötig finde ich aber, diesen Weg - aus welchen Gründen auch immer - zu verbieten, wenn dadurch nur eine (weitere) Ausnahme einer Regel künstlich und unnötig erzeugt wird. Die ProgrammierSprache wird dadurch nur unnötig komplex und schwerer zu erlernen.

Der "Drang" lässt zum Glück mit dem Alter nach ;)
Wenn man mal n bissl was erlebt hat, regt man sich über solche Kleinigkeiten icht mehr auf, sondern machst einfach so, dass es funktioniert und gut ;)
Oh Du Glücklicher, oh Du Seelicher! :LOL:
Mich regt es durchaus auf, wenn ich beobachte, wie sich solche Kleinigkeiten im Laufe der Zeit wider besseren Wissens zu Grossigkeiten weiterentwickeln, statt einfach ausgeräumt zu werden.
Ich beneide niemanden, der in der heutigen Zeit das Programmieren lernen muss oder will. Die Bäume und das Gestrüpp, die einem den Blick auf den Wald versperren, haben ja sowas von zugenommen, dass kaum noch ein "schonender" Einstieg möglich zu sein scheint.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben