Hi all
ja ich geb zu, dass das vielleicht etwas knapp geschrieben war.
GET und PUT hantieren mit drei "Adressen". Die erste ist die Verbindungsadresse. Die zweite ist die lokale Adresse. Die dritte ist die auf der anderen CPU - REMOTE.
Die remote Adresse muss wie schon in Step7 V5 und früher etwas in der Form P#DBa.DBXb.0 type c sein. Warum? Weil man eben einer 300 oder 400 in den Speicher greift und die können nix anderes :-(
Die lokale Adresse kann mit irgendwas versorgt sein. Also auch mit was optimierten. Ja, optimierte DB können nur symbolisch angegeben werden. Ist doch gut so -- warum sollte ich mich unnötigerweise mit P#DBa.DBXb.0 quälen wenn ich "derDB".mitderstrukturiertenVariablen schreiben kann. Und jetzt schaffen es 1200 und 1500 sogar die Daten so auf das Netz zu legen, dass eine 300/400 damit zu recht kommt. Hey, was wollt ihr mehr
Da PUT/GET immer standard Speicher auf der REMOTE Seite annehmen muss auch immer nach standard sortiert werden.
Nutzt man statt PUT/GET die symmetrischen TSEND/TRECV dann kann man zwischen 1200/1500 und 1200/1500 Daten hin und her schicken. Wenn sich zwei 1200 miteinander unterhalten, könnte es ja sein, dass die ohne umsortieren arbeiten, weil auf beiden Seiten optimierte Daten angesprochen werden, geschickter weise der gleiche -- was sage ich -- der selbe Datentyp. Aber die Hoffnung trügt. Wireshark zeigt, dass die Daten im Netz genauso unterwegs sind wie zu einer 300/400. D.h. sie werden zwei mal umsortiert; einmal beim TSEND und nochmal beim TRCV. Kleine Enttäuschung meinerseits.
@Ralle:
Ja auf der 1200/1500 ist eine Art Datenbank. Nimm mal die SD aus der 1500 und stecke sie in einen Kartenleser. Da sind hunderte Dateien drauf. Kopier sie dir auf deinen PC. Steck die Karte wieder in die CPU. Ändere einen Baustein. Z.B. füge in einen FC einen Kontakt ein. Verwende aber ein Tag das es schon gibt. Übersetzen und auf die CPU laden, konsistent natürlich
. Nun nimm das Kärtchen wieder aus der CPU und steck sie zurück in den Kartenleser. Vergleiche welche Datei sich geändert hat. Siehe da, es sind nur sehr wenige. Wenn man da mit einem Hex Editor rein schaut, dann findet man sogar welche zum FC gehört.
Nun ändere einen Startwert eines DB. Es ändert sich ein paar mehr, aber nicht alles. Im File zum DB man findet sogar die Stelle des Werte wenn man ein auffälliges Bitmuster verwendet hat. Und es ändert sich wieder reichlich Verwaltungsinformation. Das macht die Suche gerne zu einer nach der Nadel im Heuhaufen.
Nun ändere einen UDT. Jetzt ändern sich viele Files. Wenn ich das richtig zähle, dann gibt es zu jedem Typ, sei es ein richtiger UDT oder nur eine Struktur innerhalb einer anderen ein zusätzliches File. Was da genau drin ist, verstehe ich zwar nicht, aber ich vermute das ist sowas wie eine Datenbank für die Namen, die Typen und die Offsets.
Siemens und Microsoft kochen doch auch nur mit Wasser. Was soll S denn auch anderes tun. Unsere Programme müssen irgendwie auf die CPU und die kann bestimmt nicht mit den Symbolen arbeiten. Also müssen die Symbole schließlich zu profanen Adressen des Controllers werden. Weder Intel noch AMD, noch ARM, noch MIPS, noch IBM, noch Qualcomm bauen symbolische Controller.
'n schönen Tach auch
HB