-> Hier kostenlos registrieren
Wie wird im TIA-Portal eine Umwandlung von Word => Int oder Int => Word erstellt? Wir das mit dem MOVE gemacht? Gruss TMaroni
TIA Umwandlung Word => Int / Int => Word
- Ersteller TMaroni
- Erstellt am
-> Hier kostenlos registrieren
- Beiträge
- 5.436
- Reaktionspunkte
- 1.410
Ein Wort ist kein Zahlenformat sondern nur die Grösse des Speichers.
Da muss also nix gewandelt werden wenn der Inhalt schon ein Int ist.
In AWL gehts dann einfach mit Lade Tranfer und in Fup müsste das der Move problemlos machen.
Da muss also nix gewandelt werden wenn der Inhalt schon ein Int ist.
In AWL gehts dann einfach mit Lade Tranfer und in Fup müsste das der Move problemlos machen.
HelleBarde
Level-1
- Beiträge
- 309
- Reaktionspunkte
- 175
-> Hier kostenlos registrieren
Hallo miteinand
Das folgende gilt für 1200 und 1500. Für die 300 oder 400 Serie ändert sich nichts.
TIA hat einen Schalter, bei dem man zwischen ein laschen oder einer strengen Prüfung wechseln kann.
Mit IEC-Check (findet man bei den Baustein Eigenschaften) an, wird streng geprüft.
Bei strenger Prüfung unterscheidet TIA zwischen WORD, INT und UINT. Alle drei sind 16 Bit breit. Aber bei der Zuweisung wird rum gemeckert. Bei der laschen Prüfung geht da viel mehr durch.
Für TIA ist WORD mehr als nur die Breite welche die Variable im Speicher belegt. Das zieht aber auch ganz schreckliche Stilblüten nach sich.
Eigentlich kann man WORD nicht addieren oder auf größer vergleichen. WORD ist nur ein Bitmuster. In KOP/FUP sieht man nun an der ADD-Box welche Operation tatsächlich ausgeführt wird. Wenn man ein WORD mit einem INT addiert, dann wird das WORD als INT betrachtet. Wenn man ein WORD mit einem UINT addiert, dann wird das WORD als UINT betrachtet. Soweit eigentlich ganz vernünftig. Aber bei der Übertragung von Programmen aus Step7 V5 nach Portal 1500, habe ich schon des öfteren in KOP-Fehler bekommen, weil ein Vergleich jetzt stur rumgemault hat, das ich das INT nicht mit dem BYTE vergleichen darf.
Irgendwie haben sie ja recht, aber lästig ist das trotzdem :-(
Normalerweise sind diese Spitzfindigkeiten egal. Außer du schaust das ENO der Box an. INT läuft bei 32768 und UINT bei 65535 über. Das ENO wird also in ganz anderen Fällen false. Das wird dann zum Problem, wenn man in KOP die Boxen verkettet. Ein Überlauf in einer Box weiter links, legt die Boxen weiter rechts lahm.
In SCL hat man solche ENO-Probleme nicht. In SCL sieht man nicht wie es rechnet, aber das macht es genauso wie KOP/FUP. Nur die Überläufe verschluckt es. Man kann aber in SCL automatische ENO Generierung einschalten. Dann kümmet sich auch SCL um das ENO eines unscheinbaren +. Das schlägt sich aber auf die Performance :-( und zwar nicht schlecht. Ein Testbaustein, der nur aus Rechnungen bestand läuft mit ENO etwa drei mal solange wie ohne
Wie so oft, kann ich jetzt gar nicht sagen was mir besser gefällt. Meistens sind die Überläufe egal, bzw sie kommen eigentlich in der Praxis gar nicht vor. Wenn aus der Richtung Gefahr droht, dann weiche ich lieber auf einen breiteren Datentyp aus. Von INT nach DINT umzusteigen hat scheinbar keinen Performanceeinfluss auf Bausteine mit optimierter Datenablage. Eher in Gegenteil bei einigen Programmen die ich aus der alten Welt übernommen habe konnte ich so manche lästige Konvertierung einsparen. Der Baustein wird kleiner und läuft schneller
In der Praxis besteht aber kein Baustein nur aus Rechnungen und damit geht der Effekt bisher bei meinen Programmen im Rauschen unter. Damit sind wir wieder bei einer meiner Lieblingsforderungen. Bausteine die SCL und FUP enthalten. Dann könnte ich in einem Netz ohne ENO rechnen und in anderen Netz die Logik mit FUP machen. Das würde maximale Performance liefern.
Oder es wäre schön, wenn man das ENO in FUP abschalten könnte. Hallo Siemens, bekomme ich das zu Weihnachten?
Das folgende gilt für 1200 und 1500. Für die 300 oder 400 Serie ändert sich nichts.
TIA hat einen Schalter, bei dem man zwischen ein laschen oder einer strengen Prüfung wechseln kann.
Mit IEC-Check (findet man bei den Baustein Eigenschaften) an, wird streng geprüft.
Bei strenger Prüfung unterscheidet TIA zwischen WORD, INT und UINT. Alle drei sind 16 Bit breit. Aber bei der Zuweisung wird rum gemeckert. Bei der laschen Prüfung geht da viel mehr durch.
Für TIA ist WORD mehr als nur die Breite welche die Variable im Speicher belegt. Das zieht aber auch ganz schreckliche Stilblüten nach sich.
Eigentlich kann man WORD nicht addieren oder auf größer vergleichen. WORD ist nur ein Bitmuster. In KOP/FUP sieht man nun an der ADD-Box welche Operation tatsächlich ausgeführt wird. Wenn man ein WORD mit einem INT addiert, dann wird das WORD als INT betrachtet. Wenn man ein WORD mit einem UINT addiert, dann wird das WORD als UINT betrachtet. Soweit eigentlich ganz vernünftig. Aber bei der Übertragung von Programmen aus Step7 V5 nach Portal 1500, habe ich schon des öfteren in KOP-Fehler bekommen, weil ein Vergleich jetzt stur rumgemault hat, das ich das INT nicht mit dem BYTE vergleichen darf.
Irgendwie haben sie ja recht, aber lästig ist das trotzdem :-(
Normalerweise sind diese Spitzfindigkeiten egal. Außer du schaust das ENO der Box an. INT läuft bei 32768 und UINT bei 65535 über. Das ENO wird also in ganz anderen Fällen false. Das wird dann zum Problem, wenn man in KOP die Boxen verkettet. Ein Überlauf in einer Box weiter links, legt die Boxen weiter rechts lahm.
In SCL hat man solche ENO-Probleme nicht. In SCL sieht man nicht wie es rechnet, aber das macht es genauso wie KOP/FUP. Nur die Überläufe verschluckt es. Man kann aber in SCL automatische ENO Generierung einschalten. Dann kümmet sich auch SCL um das ENO eines unscheinbaren +. Das schlägt sich aber auf die Performance :-( und zwar nicht schlecht. Ein Testbaustein, der nur aus Rechnungen bestand läuft mit ENO etwa drei mal solange wie ohne
Wie so oft, kann ich jetzt gar nicht sagen was mir besser gefällt. Meistens sind die Überläufe egal, bzw sie kommen eigentlich in der Praxis gar nicht vor. Wenn aus der Richtung Gefahr droht, dann weiche ich lieber auf einen breiteren Datentyp aus. Von INT nach DINT umzusteigen hat scheinbar keinen Performanceeinfluss auf Bausteine mit optimierter Datenablage
. Eher in Gegenteil bei einigen Programmen die ich aus der alten Welt übernommen habe konnte ich so manche lästige Konvertierung einsparen. Der Baustein wird kleiner und läuft schneller In der Praxis besteht aber kein Baustein nur aus Rechnungen und damit geht der Effekt bisher bei meinen Programmen im Rauschen unter. Damit sind wir wieder bei einer meiner Lieblingsforderungen. Bausteine die SCL und FUP enthalten. Dann könnte ich in einem Netz ohne ENO rechnen und in anderen Netz die Logik mit FUP machen. Das würde maximale Performance liefern.
Oder es wäre schön, wenn man das ENO in FUP abschalten könnte. Hallo Siemens, bekomme ich das zu Weihnachten?
Zuletzt bearbeitet:
- Beiträge
- 6.626
- Reaktionspunkte
- 2.332
Das ist doch aber der Sinn von Datentypen und damit dem Verhalten von ENO?!
Wenn man die Typüberprüfung abschaltet, sollte man sich doch bewußt sein, dass u.U. ein anderes Verhalten als gewohnt heraus kommt.
Und wenn das Auswerten der Überläufe nicht erwünscht ist, kann man doch auch in FUP/KOP genau wie in SCL die Berechnungen auch ohne ENO (auch innerhalb eines Netzwerkes) nacheinander durchführen lassen. Dafür gibt es doch Verzweigungen.
HelleBarde
Level-1
- Beiträge
- 309
- Reaktionspunkte
- 175
Das ist doch aber der Sinn von Datentypen und damit dem Verhalten von ENO?!
Wenn man die Typüberprüfung abschaltet, sollte man sich doch bewußt sein, dass u.U. ein anderes Verhalten als gewohnt heraus kommt.
Klar. Aber in gefühlten 99% aller Anwendungen kümmert sich keiner um das ENO.
Womit in gefühlten 5% der Anwendung ein Teil des Netzes nicht ausgeführt wird,
was wiederum in gefühlten 90% der Fälle unbemerkt bleibt.
Und wenn das Auswerten der Überläufe nicht erwünscht ist, kann man doch auch in FUP/KOP genau wie in SCL die Berechnungen auch ohne ENO (auch innerhalb eines Netzwerkes) nacheinander durchführen lassen. Dafür gibt es doch Verzweigungen.
Die aber seltenst einer verwendet.
Dir scheint das alles bewusst zu sein
Ich kenne nur soviele wo dem nicht so ist. Und einige davon wundern sich immer warum ich wenn ich "zufällige" ihre Baustein ansehe, weil es auf der Anlage nicht klappt, "Schreikrämpfe" kriege. Antwort "ich hab das doch getestet -- das ist nie aufgetreten"
