TIA TIA Portal V14..V17 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit wäre lieber, es würden keine impliziten Typumwandlungen stattfinden, so dass ich dafür sorgen muß.
Dann ist einfach alles klar. Ich schreibe so auch i.d.R. meine Programme, aber man kann diese impliziten Typumwandlungen ja nicht unterbinden.
 
  • Danke
Reaktionen: van
Hilfe! Bewahre uns vor "intelligenten" Typwandlungen! Besser wären genau dokumentierte Regeln.
Wie die impliziten Typwandlungen in einem Programmiersystem funktionieren muss man als Programmierer halt lernen - oder konsequent explizit angeben.
Harald

Bei eindeutig Verlustfreien sehe ich da überhaupt keine Probleme. (BYTE to INT, USINT to BYTE, ....)
Verlustbehaftete haben nicht autom. zu Erfolgen. Das sollte klar sein (INT to BYTE, SINT to BYTE, UINT to BYTE, ...)

Auf jeden Fall ist die TIA-Interpretation (mit IEC-Prüfung aus) aus meiner Sicht total gaga. Klar kann Siemens das so machen wenn es ordentlich dokumentiert ist.
[Die könnten auch sagen 15 + 15 = 31 weil vielleicht 2 Nibbels überlaufen. Ob das Praxisgerecht wäre ...]

[COLOR=#333333 schrieb:
..., aber man kann diese impliziten Typumwandlungen ja nicht unterbinden.[/COLOR]Ralle
Dann auf jeden Fall IEC-Prüfung einschalten. Das macht schon einen Unterschied. Habe ich leider jetzt erst gelernt ..
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei eindeutig Verlustfreien sehe ich da überhaupt keine Probleme. (BYTE to INT, USINT to BYTE, ....)
Verlustbehaftete haben nicht autom. zu Erfolgen. Das sollte klar sein (INT to BYTE, SINT to BYTE, UINT to BYTE, ...)

Auf jeden Fall ist die TIA-Interpretation (mit IEC-Prüfung aus) aus meiner Sicht total gaga. Klar kann Siemens das so machen wenn es ordentlich dokumentiert ist.

TIA macht das genau wie die meisten anderen stark typisierten Programmiersprachen. Du hast

INT := BYTE * BYTE;

Erst wird die Multiplikation gerechnet, und da dort beide Typen identisch sind erfolgt dort keine Typkonvertierung. Erst bei der Zuweisung wird automatisch vom kleineren auf den größeren gewandelt.
Diese Reihenfolge ist durch die Operatorrangfolge eindeutig festgelegt.

Ich habe aber eine Vermutung, dass das bei Codesys bei diesem Datentypen mehr oder weniger zufällig auf ein INT konvertiert wird. Du könntest auf einem 32 Bit System mal folgende Berechnung probieren:
LINT := DINT * DINT;

Und dann mit zwei großen 32 Bit Zahlen sodass ein Überlauf stattfindet. Mal sehen ob das dann auch auf 64 Bit gerechnet wird.
 
Da bei TwinCAT 2 keine 64 Bit Datentypen möglich sind, habe ich das Verhalten mal an einem BC9210 mit 16 Bit CPU getestet, da dort der Akku nur 16 Bit breit ist und man so auch an DINT einen Überlauf provizieren kann.

Und wie schon von mir vermutet, funktioniert das mit dem richtigen Ergebnis bei Codesys nur zufälligerweise und nicht weil sich da bei Codesys jemand Gedanken zu einem speziellen Verhalten gemacht hat, weil als Ergebnis einfach das angenommen wird was nach der Berechnung im Akku steht.
Und wenn der Akku nur 16 Bit breit ist, dann gibt es auch hier einen Überlauf. Das Verhalten ist im Gegensatz zum Siemens-Verhalten also auch Zielarchitektur abhängig - mal so, mal so.
 

Anhänge

  • BCoffline.jpg
    BCoffline.jpg
    64,8 KB · Aufrufe: 38
  • BConline.jpg
    BConline.jpg
    67,7 KB · Aufrufe: 52
Nichts ist Zufall in CODESYS! Das ist Absicht und zumindest in der Hilfe zur V3 auch dokumentiert:
CODESYS rechnet Zwischenergebnisse auf der Registerbreite, so rechnet halt auch die CPU und wenn man schnellen Code will, dann sollte man die CPU machen lassen.

CODESYS verhält sich damit unterschiedlich auf verschiedenen Zielarchitekturen, aber das nehmen wir in Kauf, ansonsten müsste man eine bestimmte Hardware
vorschreiben (geht nicht) oder einen Interpreter einsetzen (ist lahm).

Die Hardware spielt auf vielen Ebenen mit: Little Endian vs. Big Endian, Rundungsstrategien, FPU-Unterstützung, 16 / 32 / 64 Bit, es gibt FPUs die eine Exception werfen bei Division durch 0 und welche die #Inf als Ergebnis produzieren.... auf all das hat CODESYS keinen Einfluss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Könnte man bei dieser Dreckssoftware nicht endlich mal eine Funktion "automatisches Speichern" einbauen? Es ist immer noch der gleiche Scheiß, egal ob V14 oder V15. Stürzt immer noch unkontrolliert ab. Manchmal lässt sich nicht mal mehr der Diagnosebericht schicken. Wobei der Sinn davon für mich sowieso fragwürdig ist.

Entschuldigt, aber ich musste jetzt einfach mal meinen Frust loswerden.
 
TIA macht das genau wie die meisten anderen stark typisierten Programmiersprachen.

OK. Ich muss gestehen, dass ich nicht Hochsprachen-Affin bin. Ich nehme also mein Siemens-Bashing (in diesem Fall..) zurück und Verallgemeinere das ganz locker naiv auf alle "stark typisierten Programmiersprachen" ....
Bei meiner romantischen Vorstellung würde ich es ebenso erwarten: Ich weise ein INT zu, also möchte ich wohl die Berechnung in INT haben. Ist eigentlich schon ein eindeutiger Wandlungsauftrag bei Typkonflikten. Und bei Ausdrücken ohne Zuweisung wäre es eben das größte verwendete Format. (Zu Klarstellung: Immer nur wenn ohne Verluste möglich, sonst Fehler). Muss der Compiler eben ein bisschen keulen. >90% aller Ausdrücke macht man ja eigentlich auch Typenrein.
Wenn wirklich so leicht ist (Operatorrangfolge) ein 8-Bit-Overflow hinzukriegen wundere ich mich über Softwarefehler aller Art gar nicht mehr.
Schönes Wochenende (...und immer schön IEC-Prüfung einschalten...)
 
Die Hardware spielt auf vielen Ebenen mit: Little Endian vs. Big Endian, Rundungsstrategien, FPU-Unterstützung, 16 / 32 / 64 Bit, es gibt FPUs die eine Exception werfen bei Division durch 0 und welche die #Inf als Ergebnis produzieren.... auf all das hat CODESYS keinen Einfluss.

In gewisser Weise schon, denn Codesys schreibt den Compiler der Code generieren könnte der das für jede unterstützte Architektur so abfängt, dass sich alle identisch verhalten - wenn man es denn will und nicht nur auf dem Werbeprospekt "schnell" stehen haben will. Aber eigentlich ist der IEC-Standard schuld, der meiner Meinung nach viel zu viele Definitionslücken lässt. Das ist bei C schon nervig genug, die ganzen "undefined behaviour" und "implementation dependant" zu beachten wenn ein Programm auf verschiedenen Architekturen lauffähig sein soll. Wenn ich in ST den gleichen Zauber habe, dann kann ich auch gleich in C programmieren ohne mir die Bremsen von ST einzufangen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kurze Frage:

Wenn ich etwas im SCL-Editor auskommentiere mit

//meineTestVariable =+1

und hernach Enter betätige, dann erzeugt mir der Editor immer

//meineTestVariable =+1
//

Kann man diese automatisch generierte Ergänzung meines Codes deaktiveren? Falls nicht (was ich nicht glauben kann) -> Änderungswunsch/Wunschliste
 
In gewisser Weise schon, denn Codesys schreibt den Compiler der Code generieren könnte der das für jede unterstützte Architektur so abfängt, dass sich alle identisch verhalten - wenn man es denn will und nicht nur auf dem Werbeprospekt "schnell" stehen haben will.

Wir wollen es explizit nicht, wir haben ein compilierendes System und wollen die Vorteile davon auch haben. Aber selbst wenn man wollte bekommt man es nicht zu 100 % hin dass sich ein
16 BIt-C16x mit BigEndian wie ein ARM64 mit Little Endian verhält.
Oder man schreibt eine Emulation auf Basis des schwächsten Systems das man unterstützen will, und schränkt den Sprachumfang auf ein Mass ein, das einem keinen Spass mehr macht.
(Pointer kann man knicken).
 
Warum bitte kann ich eigentlich keinen Array of FB erzeugen? Ich kann doch mittlerweile ne Parameterinstanz erstellen, da wäre es doch nur allzu logisch mittels einer Schleife aus meinem Array unterschiedliche Daten an die jeweils zugehörige Instanz zur Laufzeit zu legen und mir die ganze Programmiererei zu ersparen.

Oder seht ihr keinen Sin für solche eine Funktion?

Und für was verwendet ihr die Parameterinstanzen sonst? Ich sehe sonst noch keine Anwendungsmöglichkeiten.. :confused:
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
V14SP1 mit 1513F als CPU. Beides getestet, beides fehlgeschlagen. Eigentlich geht es mir primär um den FB Program_Alarm, allerdings hatte ich versucht es allgemeiner zu testen und bin gescheitert.

Unbenannt.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gebt bitte die SFC51 RDSYSST auf 12xx / 15 xx zurück

Ich will SFC51 RDSYSST zurück !

Projekte, die etwas Diagnose enthalten, sind nicht migrierbar. Auch wenn man alle SCL Quellen hat und weiß wie was zu tun ist. Diagnose auf den 1xxx CPUs ist eine Katastrophe, man sieht und erhält gar nichts! Ich erhalte keinen Zugriff auf welche auch immer Projektierungsdaten aus der Hardware-Configuration. Außer vielleicht der IP Adresse, die mich aber wirklich einen feuchten Dreck interessiert.

Und nein, es hilft nichts daß ich eine logische Adresse auflösen kann. Das gab es auf der klassischen CPU auch schon. Daneben gab es aber noch Systemzustandslisten, die vom Zustand eines DP-Mastersystems bis hin zur Herstellerkennung einzelner Komponenten und Prozessabbildzuordnung mir zur Laufzeit alles lieferten, was man für die Diagnose brauchen kann. Unabhängig davon, ob das Gerät online oder offline ist.
 
Zuletzt bearbeitet:
WUNSCH: Verbesserte Performance beim zeichnen der Bildbausteine in RT. Oder Trigger einstellen ohne VB-Skript Option!

Problem: Erst werden statische Objekte dann dynamisierte Objekte gezeichnet. Bildbausteine mit "Eigenschaft Verknüpfung" haben keinen einstellbaren Trigger.
Dies führt zu extremen Performance Problemen! Abhilfe war immer nur ein VB-Skript!
Nur mit VB-Skript lässt sich ein Trigger einstellen.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben