Hallo Larry
messen und leiden.
Wie man an vielen meiner Beiträge feststellen kann, versuche ich immer nachzumessen. Die 1500 machen mir zwar das Messen schwer, weil die Ergebnisse stark streuen und von so vielen Unbekannten abhängen, dass man damit alles und nichts beweisen kann, aber es gibt eindeutige Tendenzen. Vor allem bei den teureren 1500.
So wie es sich mir darstellt, hat S. die optimierten Bausteine erfunden um sich besser an die in der PLC verbauten µ-Controller anzupassen.
Wenn man sich die Mühe macht mit Wireshark das Laden auf die PLC zu beobachten, dann stellt man trotz aller Verschlüsselung fest, dass die optimierten DB der 1500 im Little-Endian übertragen und die nicht optimierten im Big-Endian übertragen werden. Bei 300/400 war es immer Big. Bei der 1200 ist auch alles Big. Wie man das rausbekommt? Dazu lege man einen DB mit einem Array aus 1000 DWORD an und setze das 333te Element auf 16#12345678 alles andere lasse man auf 0. Also findet man im Datenstrom viele 0 und irgendwo die 12 34 56 78 oder eben 78 56 34 12. Das kannst du auch mit allen anderen Datentypen machen, du musst dir eben einen "hübschen" Wert raussuchen.
Jetzt vergleiche man die Preise für die verschiedenen Prozessoren und deren Eigenschaften. Die von Intel sind meistens Little. Bei manchen kann man es einstellen, z.B. ARM und MPIS. Bei den Controllern, die Little bevorzugen, ist S. mit ihren bisherigen Big natürlich blöd dran. Lesen von MD7 kostet laufzeit und Assembler-Code, egal welche Controller-Familie nun wirklich drin ist. Je besser die Prozessoren sind desto schlechter können sie MD7 lesen. Auf einer Assembler-Schulung, die ich vor Jahren genossen habe hat man mir den Code gezeigt, der für das Lesen von MD7 bei x86-Intel-Prozessoren nötig ist. Der x86 mag es, wenn die Daten so liegen, wie sie auch breit sind. MD4 lesen geht schnell und MD8 auch. Aber bei allem dazwischen, muss man praktisch jedes Byte einzeln lesen und zum DW zusammen schubsen. Das machte statt einem MOV eine Kette aus MOV, SHL, MOV, OR, SHL, MOV, OR, SHL, MOV, OR. Das ist völlig unabhängig von der Endianness. Und genau das kann man nachmessen. Der Zugriff auf optimierte Daten ist bei der 1516 etwa 4 mal schneller als auf nicht optimierte. S. kocht eben auch nur mit Wasser. Es wird ja spekuliert, dass in den 1500 ein MIPS drin ist und in der 1518 sogar ein Intel.
Jetzt bietet TIA das AT nur noch für Standard-Daten an ... merkste was? Durch die von uns mittels AT festgelegte Platzierung der Daten auf für den µ-Controller ungünstige Adressen, kann der sein Potential nicht entfalten. Das kostet Zeit. Sollte dir die Zykluszeit egal sein, dann ist sie dir eben egal.
Kannst du dein Programm aber umschreiben/anpassen, dass du auf AT und AWL und die ganzen Adressregister/ANY Patina -- ach ich kann ja so toll optimierte Programme schreiben -- verzichten kannst, dann reicht ja vielleicht eine 1513 wo du vorher eine 1516 gebraucht hast. OK, keiner zahlt Liste, aber wenn es eine Serienmaschine ist, dann rechnet sich das ziemlich schnell.
Und dass AT unheimlich Spaß beim Fehlersuchen macht, dass habe ich leider viel zu oft erleben müssen.
'n schön' Tach auch.
HB
