DotNetSiemensPLCToolBoxLibrary (LibNoDave) Zugriff auf Dual-Port RAM / FB15

Zuviel Werbung?
-> Hier kostenlos registrieren
Das Lesen an sich funktioniert.
Aber in libnodave fehlt die Erkennung diverser möglicher Transportgrößen, in diesem Fall 0x07. Das hat bisher nicht gestört, weil libnodave die Anfragen immer so gestellt hat, dass eine bekannte Transportgröße zurückkommt.

Ich kopiere mal alle die mir bekannten Größen aus dem Wireshark plugin die in libnodave ergänzt werden müssten, denn zumindest "OCTET STRING" kommt bei manchen Daten einer NCK auch noch vor:
Code:
/**************************************************************************
 * Transport sizes in data
 */
#define S7COMM_DATA_TRANSPORT_SIZE_NULL     0
#define S7COMM_DATA_TRANSPORT_SIZE_BBIT     3           /* bit access, len is in bits */
#define S7COMM_DATA_TRANSPORT_SIZE_BBYTE    4           /* byte/word/dword access, len is in bits */
#define S7COMM_DATA_TRANSPORT_SIZE_BINT     5           /* integer access, len is in bits */
#define S7COMM_DATA_TRANSPORT_SIZE_BDINT    6           /* integer access, len is in bytes */
#define S7COMM_DATA_TRANSPORT_SIZE_BREAL    7           /* real access, len is in bytes */
#define S7COMM_DATA_TRANSPORT_SIZE_BSTR     9           /* octet string, len is in bytes */

static const value_string data_transportsizenames[] = {
    { S7COMM_DATA_TRANSPORT_SIZE_NULL,      "NULL" },
    { S7COMM_DATA_TRANSPORT_SIZE_BBIT,      "BIT" },
    { S7COMM_DATA_TRANSPORT_SIZE_BBYTE,     "BYTE/WORD/DWORD" },
    { S7COMM_DATA_TRANSPORT_SIZE_BINT,      "INTEGER" },
    { S7COMM_DATA_TRANSPORT_SIZE_BDINT,     "DINTEGER" },
    { S7COMM_DATA_TRANSPORT_SIZE_BREAL,     "REAL" },
    { S7COMM_DATA_TRANSPORT_SIZE_BSTR,      "OCTET STRING" },
    { 0,                                    NULL }
};
 
Nur mal rein aus Interesse: Woher weißt du dass du Slot 4 verwenden musst? Ich habe ein Logfile von jemand anderen, da wird Slot 3 verwendet. Gibt es so etwas wie eine Hardwarekonfiguration in Step7, aus der ersichtlich ist auf welchem Slot die Baugruppe sitzt? Und lässt sich diese frei verschieben?
 
Da lass ich erst mal lieber die Finger weg. Normales C ist nicht gerade mein Freund.
Mach jetzt sowieso Feierabend.

@Jochen: Kannst du das bitte in die libnodave einbauen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Irgendwie ist libnodave mittlerweile auch ziemlich verfrickelt. Wenn man da genau hinguckt, keine Überprüfungen ob die Längenangaben mit dem reservierten Speicher zusammenpassen usw.. Es funktioniert zwar, aber Stand der Technik ist der Code nicht wirklich.
 
Ich wollte das ja schon lange full managed in meine library implementieren... aber dazu fehlt die zeit...
(Hauptsächlich ging mir's ja um die push Telegramme von der CPU!)

P.S. wie siehts den mit der TIA B&B Kommunikation aus? Hast du denn da jetzt schon einiges entschlüsselt?
 
Ich würde da eher auf Snap7 setzen, das hat eine vernünftige Codequalität. Bei TIA hab ich schon lange nicht weitergemacht. Hauptsächlich muss jemand die Authentifizierung entschlüsseln, denn auch die neuen 1200er kommunizieren nur noch mit. Ich habe da zwar schonmal ein paar Sachen rumprobiert, aber mir fehlt da etwas die Erfahrung mit den diversen kryptografischen Funktionen, und wie man sowas angeht das zu knacken (möglichst beweisbar ohne Disassemblieren).
Außerdem schraubt Siemens gerne mal am Protokoll rum, da würde ich erstmal abwarten bis sich das stabilisiert hat. Denn auch ohne die Authentifizierung ist das ordentlich Arbeit.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab gerade eine Erfolgreiche Antwort der "ReadValue()" Methode bekommen.

In der Methode ist noch ein Fehler.
Hab die beiden Zeilen mit *.Add(false) hinzugefügt.

Code:
PLCConnection.cs Zeile 2497

if (nckT != null)
{
        usedShortRequest.Add(false);
        tagWasSplitted.Add(false);
        myPDU.addNCKToReadRequest(nckT.NckArea, nckT.NckUnit, nckT.NckColumn, nckT.NckLine, nckT.NckModule, nckT.NckLinecount);
}
 
Ist das soweit nun nutzbar, oder muß ich danoch arbeit reinstecken? Gabs nicht irgendwelche beschränkungen mit anzahl der gleichzeitig lesbaren Tags je bereich?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da muss schon noch arbeit reingesteckt werden.

Hab gerade das rotieren der Bytes eingebaut, wenn es keine Variable aus dem Antrieb ist.

Bei den Bereichen müssen mehrere Faktoren berücksichtigt werden. Bin noch am Testen.

Wenn ich genaueres weiß schreib ich dir oder mach nen pull request.
 
Hallo Jochen,

Ich versuche gerade einen String von der NC zu lesen.

Wenn ich im PLCNckTag zusätzlich zum Typ String noch die "ArraySize = 20" mitgebe, kommt im Buffer der Text auch an.

Beim Umwandeln des Strings kommt es aber zu einem Exception:

{"Der Index und die Anzahl müssen sich auf eine Position im Puffer beziehen.\r\nParametername: bytes"}
 

Anhänge

  • string ByteBuffer.png
    string ByteBuffer.png
    19,4 KB · Aufrufe: 23
  • _readValueFromBuffer string Exception.png
    _readValueFromBuffer string Exception.png
    50,8 KB · Aufrufe: 22
@Jochen
Hier die Infos zu den Beschränkungen:

Zu den Achsen: Ich habe herausgefunden, dass man über den Bereich FeedDrive sowohl aus Block M wie auch aus Block 0x82 die Antriebsdaten lesen kann.
In diesen beiden Blöcken befinden sich die gleichen Daten, jedoch ist die Unit-zu-Achsen-Zuordnung unterschiedlich. Im Block M entspricht die Unit des Antriebs den Achs-MD (AreaAxis / BlockM), d.h. wenn bei den Achs-MD Unit 3 die Z-Achse ist, ist bei den Antriebs-MD (im Block M) Unit 3 der Antrieb der Z-Achse.
Im Block 0x82 sind die Achsen wie ihr ja bereits geschrieben hattet nach der Topologie im Antriebsstrang sortiert.. wie genau habe ich noch nicht herausgefunden.
Bislang hab ich auch keinen Weg gefunden das "automatisiert" auszulesen, sondern hab Werte gelesen und die dann manuell mit dem HMI verglichen um die Zuordnung rauszubekommen... Ich verwende für die Antriebe jetzt einfach BlockM, da ist es klar.

Soweit ich es verstanden habe sind die Limitierungen wie folgt:
  • Die Bereiche FeedDrive und MainDrive dürfen jeweils immer nur einzeln, nicht in Kombination mit anderen Bereichen gelesen werden. Bei anderen Bereichen ist das egal
  • Das gleichzeitige Lesen von Variablen aus mehreren Units in einem Auftrag ist NIE erlaubt, egal aus welchem Bereich
  • In den Bereichen FeedDrive und MainDrive dürfen max. 19 Variablen auf einmal gelesen werden, egal welcher Datentyp
  • Die Endian-Verdrehung betrifft (glaube ich) alles in den Bereichen MainDrive und FeedDrive, nicht nur die 0x8Y Blöcke
 
Zuletzt bearbeitet:
Zurück
Oben