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

Zuviel Werbung?
-> Hier kostenlos registrieren
Und wie wird dieses ACX-Archiv bei Bedarf wiederhergestellt? Wird es als eine Datei auf die Steuerung geladen und dort entpackt, oder extern entpackt und dann alles wieder in Einzelteilen hochgeladen?
 
Zuletzt bearbeitet:
Thomas_v2.1 schrieb:
Und wie wird dieses ACX-Archiv bei Bedarf wiederhergestellt? Wird es als eine Datei auf die Steuerung geladen und dort entpackt, oder extern entpackt und dann alles wieder in Einzelteilen hochgeladen?
Zum Vergrößern anklicken....

Das Archiv wird vom HMI erstellt und auf der CF-Karte (Linux) oder Festplatte (Windows) abgelegt und kann bei bedarf von selbigen wieder eingespielt werden.

Es ist auch möglich das Archiv offline per Siemens Tool (Create MyConfig) zu öffnen und Dateien auszutauschen. Das Archiv besteht immer aus einem Packet. Dieses kann nur die NC, PLC, Antriebe (DP) enthalten oder auch alles zusammen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gibt es schon eine Format-Beschreibung zu den ACX-Dateien, es scheint ja verschiedene Varianten zu geben - die GUD ACX die ich so angeschaue haben alle einen 0x56 byte header aber es gibt auch andere ACX-Dateien, in Operate-Temp-Ordnern die auch die "Acx" Signatur haben aber einen großeren Header haben und glaube ich einen anderen Aufbau, gibt es eine möglichkeit zu erkennen ob es eine GUD-ACX ist?

Code: 
Beispiel: CH1_GD2.ACX


00000000  41 63 58 00 00 02 00 00 C3 00 00 02 00 00 00 BC  AcX.....Ã......¼
00000010  0C 05 02 00 00 00 3D 65 05 17 64 05 14 63 05 02  ......=e..d..c..
00000020  47 25 00 00 02 48 25 A8 00 02 49 25 11 00 02 4A  G%...H%¨..I%...J
00000030  25 7F 00 20 66 65 62 64 30 38 63 38 34 39 39 38  %.. febd08c84998
00000040  66 39 35 35 38 38 61 33 63 64 63 31 64 39 33 34  f95588a3cdc1d934
00000050  35 62 30 38 37 37 A2 0D 04 00 00 00 00 0A 9B 60  5b0877¢.......›`
00000060  58 5F 42 41 43 4B 4C 41 53 48 02 88 20 01 00 01  X_BACKLASH.ˆ ...
00000070  89 20 0A 01 19 24 02 01 07 24 07 01 08 24 04 A4  ‰ ...$...$...$.¤
00000080  0D 04 00 00 00 00 0C 9B 60 58 5F 32 5F 42 41 43  .......›`X_2_BAC
00000090  4B 4C 41 53 48 02 88 20 02 00 01 89 20 0A 01 19  KLASH.ˆ ...‰ ...
000000A0  24 02 01 07 24 07 01 08 24 04 A2 0D 04 00 00 00  $...$...$.¢.....
000000B0  00 0A 9B 60 59 5F 42 41 43 4B 4C 41 53 48 02 88  ..›`Y_BACKLASH.ˆ
000000C0  20 03 00 01 89 20 0A 01 19 24 02 01 07 24 07 01   ...‰ ...$...$..
000000D0  08 24 04 A4 0D 04 00 00 00 00 0C 9B 60 59 5F 32  .$.¤.......›`Y_2
000000E0  5F 42 41 43 4B 4C 41 53 48 02 88 20 04 00 01 89  _BACKLASH.ˆ ...‰
000000F0  20 0A 01 19 24 02 01 07 24 07 01 08 24 04 A2 0D   ...$...$...$.¢.
00000100  04 00 00 00 00 0A 9B 60 5A 5F 42 41 43 4B 4C 41  ......›`Z_BACKLA
00000110  53 48 02 88 20 05 00 01 89 20 0A 01 19 24 02 01  SH.ˆ ...‰ ...$..
00000120  07 24 07 01 08 24 04 A4 0D 04 00 00 00 00 0C 9B  .$...$.¤.......›
00000130  60 5A 5F 32 5F 42 41 43 4B 4C 41 53 48 02 88 20  `Z_2_BACKLASH.ˆ 
00000140  06 00 01 89 20 0A 01 19 24 02 01 07 24 07 01 08  ...‰ ...$...$...
00000150  24 04                                            $.


davon ist der header: size = 0x56


Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F


00000000  41 63 58 00 00 02 00 00 C3 00 00 02 00 00 00 BC  AcX.....Ã......¼
00000010  0C 05 02 00 00 00 3D 65 05 17 64 05 14 63 05 02  ......=e..d..c..
00000020  47 25 00 00 02 48 25 A8 00 02 49 25 11 00 02 4A  G%...H%¨..I%...J
00000030  25 7F 00 20 66 65 62 64 30 38 63 38 34 39 39 38  %.. febd08c84998 <-- "febd08c84998f95588a3cdc1d934" sieht ein bisschen nach MD5 aus
00000040  66 39 35 35 38 38 61 33 63 64 63 31 64 39 33 34  f95588a3cdc1d934
00000050  35 62 30 38 37 37                                5b0877


und die variablen sind:


                     strlen   (str                                 )         nr
A2 0D 04 00 00 00 00 0A 9B 60  58 5F 42 41 43 4B 4C 41 53 48        02 88 20 01 00 01 89 20 0A 01 19 24 02 01 07 24 07 01 08 24 04
A4 0D 04 00 00 00 00 0C 9B 60  58 5F 32 5F 42 41 43 4B 4C 41 53 48  02 88 20 02 00 01 89 20 0A 01 19 24 02 01 07 24 07 01 08 24 04
A2 0D 04 00 00 00 00 0A 9B 60  59 5F 42 41 43 4B 4C 41 53 48        02 88 20 03 00 01 89 20 0A 01 19 24 02 01 07 24 07 01 08 24 04
A4 0D 04 00 00 00 00 0C 9B 60  59 5F 32 5F 42 41 43 4B 4C 41 53 48  02 88 20 04 00 01 89 20 0A 01 19 24 02 01 07 24 07 01 08 24 04
A2 0D 04 00 00 00 00 0A 9B 60  5A 5F 42 41 43 4B 4C 41 53 48        02 88 20 05 00 01 89 20 0A 01 19 24 02 01 07 24 07 01 08 24 04
A4 0D 04 00 00 00 00 0C 9B 60  5A 5F 32 5F 42 41 43 4B 4C 41 53 48  02 88 20 06 00 01 89 20 0A 01 19 24 02 01 07 24 07 01 08 24 04


aber auch eine bi000005.acx (aus einem Operate temp ordern)


00000000  41 63 58 00 00 02 00 00 74 00 00(23)01 60 76 65  AcX.....t..#.`ve  <--- 0x23 Zeichen fuer ["version="1.0" encoding="ISO-8859-1"]
00000010  72 73 69 6F 6E 3D 22 31 2E 30 22 20 65 6E 63 6F  rsion="1.0" enco
00000020  64 69 6E 67 3D 22 49 53 4F 2D 38 38 35 39 2D 31  ding="ISO-8859-1
00000030  22 28 7A 08 25 92 00 04 11 20 24 2A 43 00(16)8E  "(z.%’... $*C..Ž  <--- 0x16 Zeichen fuer [SINAMICS Postprocessor]
00000040  60 53 49 4E 41 4D 49 43 53 20 50 6F 73 74 70 72  `SINAMICS Postpr
00000050  6F 63 65 73 73 6F 72 02 38 48 05 00(20)06 60 61  ocessor.8H.. .`a  <--- 0x20 Zeichen fuer [a838ce45e66e63dc54c24d8d59752b1f] MD5?
00000060  38 33 38 63 65 34 35 65 36 36 65 36 33 64 63 35  838ce45e66e63dc5
00000070  34 63 32 34 64 38 64 35 39 37 35 32 62 31 66     4c24d8d59752b1f
--> keine weiteren Daten

gibt es schon mehr Infos?
 
Zuletzt bearbeitet:
Ich versuche gerade das ganze mit .Net Core auf Linux (Ubuntu 18.04.3 LTS x64) zum laufen zu bringen. Compilieren hat noch funktioniert, jedoch crasht die Anwendung beim Verbindungsaufbau.

Speicherzugriffsfehler (Speicherabzug geschrieben)

Package: dotnet-host 3.0.0-1
Title: dotnet crashed with SIGSEGV in daveNewInterface()


testISO_TCP scheint sich zu verbinden, jedoch bricht der NC Programm Upload oder bereits der PI-Service ab und bringt nen Fehler.

Update: Lesen eines DB Bytes hat mit der testISO_TCP funktioniert.
Kompilieren scheint nicht das Problem zu sein.
 
Zuletzt bearbeitet:
ja hast du denn libnodave für linux compiliert?
ich hatte libnodave in verbindung mit meiner bibliothek vor jahren auf einem iphone benutzt, also es sollte zumindest theoretisch funktionieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jochen Kühner schrieb:
ja hast du denn libnodave für linux compiliert?
ich hatte libnodave in verbindung mit meiner bibliothek vor jahren auf einem iphone benutzt, also es sollte zumindest theoretisch funktionieren.
Zum Vergrößern anklicken....

Hab ja geschrieben, dass ich die testISO_TCP zusammen mit der lib erfolgreich kompiliert habe und das Testprogram auch funktioniert.

Hab die Lib auch schon auf Linux für Raspi und yocto linux kompiliert und erfolgreich ausgeführt. Jedoch bis jetzt mit Mono.

Nach dem alle von .Net Core reden wollt ich das jetzt auch mal angehen.

.Net Standard + Core ist aber der letzte Dreck.
Gedanke top, Umsetzung mangelhaft. Reine Bastelsoftware.
 
Hab auf der vm extra kein Mono installiert um nur den dotnet Part zu testen. Ist aber mein nächster Schritt, jedoch erst Dienstag.
Ubuntu ist x64, dotnet ruft auch die x64 dll auf und ein kompiliertes Hallo Welt in c sagt auch x64.
Mit falscher IP kommt kein Crash, sondern lediglich der timeout.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast du die Aufrufe mal aus einem C-Programm heraus getestet?

Wenn die Aufrufe aus einem C-Programm heraus funktionieren, muss es ja am Glue-Code zu Mono liegen.
Die PI-Funktionen oder die NC-Upload verwendet ja strings, könnte evtl. eine Unicode Geschichte sein.
Oder da ist was bei der Umsetzung der const Parameter nicht korrekt. Bei davePIstart_nc z.B. habe ich einige Zeiger-Parameter als const deklariert die in den Funktionen ausschließlich gelesen werden.
 
Hab den Crash noch weiter eingekränzt.

Problem ist die Struktur mit den beiden Pointern.

Code: 
public struct daveOSserialType        {
            public volatile IntPtr rfd;
            public volatile IntPtr wfd;
        }

nodave.h

Code: 
#ifdef LINUX
#define DECL2
#define EXPORTSPEC
    typedef struct dost {
        int rfd;
        int wfd;
        //    int connectionType;
    } _daveOSserialType;
#include <stdlib.h>
#define tmotype int
#define OS_KNOWN    // get rid of nested ifdefs.
#endif    


#ifdef BCCWIN
#define WIN32_LEAN_AND_MEAN
#include <winsock2.h>
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#define DECL2 __stdcall
#define tmotype int


#ifdef DOEXPORT
#define EXPORTSPEC __declspec (dllexport) 
#else
#define EXPORTSPEC __declspec (dllimport) 
#endif


    typedef struct dost {
        HANDLE rfd;
        HANDLE wfd;
        //    int connectionType;
    } _daveOSserialType;


#define OS_KNOWN
#endif
 
sizeof(int) => 4
sizeof(IntPtr) => 8

Wird für Windows wirklich der HANDLE benötigt oder funktioniert hier auch int? In der "libnodave.net.cs" von "libnodave-0.8.5" wird int verwendet, obwohl nodave.h gleich ist.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hans54216 schrieb:
Hab den Crash noch weiter eingekränzt.

Problem ist die Struktur mit den beiden Pointern.

Code: 
public struct daveOSserialType        {
            public volatile IntPtr rfd;
            public volatile IntPtr wfd;
        }
Zum Vergrößern anklicken....
Schade, daß Du nun einige Beiträge von Dir gelöscht hast... stand da nicht was von 64 Bit?

Ich hatte mit Exel64 VBA das Problem, daß daveNewInterface(..) crasht. Das Problem habe ich so gelöst bekommen, daß ich davePascalNewInterface(..) verwendet habe.

Harald
 
PN/DP schrieb:
Schade, daß Du nun einige Beiträge von Dir gelöscht hast... stand da nicht was von 64 Bit?

Ich hatte mit Exel64 VBA das Problem, daß daveNewInterface(..) crasht. Das Problem habe ich so gelöst bekommen, daß ich davePascalNewInterface(..) verwendet habe.

Harald
Zum Vergrößern anklicken....
Hallo PN/DP ich hab nur die unnötigen Beiträge gelöscht. Die wichtigen z.B. #453 hab ich so gelassen.
Dort siehst du den Header (nodave.h welcher unterschiedlich ist zwischen Linux (int) und Windows (pointer) ist) und den Aufruf in C#
 
Bei manchen Windows funktion wird in der WInapi auch Handle verwendet, das ist dann 64Bit, das würde dann probleme machen wenn du das auf 32 bit änderst.
Es läuft ja auch unter windoes mit 64 bit.

Man muss nun rausfinden ob unter 64bit linux die Übergabeparameter 64 oder 32 bit sind für die Handles und das dann anpassen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hans54216 schrieb:
sizeof(int) => 4
sizeof(IntPtr) => 8

Wird für Windows wirklich der HANDLE benötigt oder funktioniert hier auch int? In der "libnodave.net.cs" von "libnodave-0.8.5" wird int verwendet, obwohl nodave.h gleich ist.
Zum Vergrößern anklicken....

glaube ich hab das mal im zuge von 64bit angepasst...
aber vtl reicht ja unter 64 bit linux trotzdem 32bit. dann kannst du ja die dll imports für linux anpassen.
 
Jochen Kühner schrieb:
glaube ich hab das mal im zuge von 64bit angepasst...
aber vtl reicht ja unter 64 bit linux trotzdem 32bit. dann kannst du ja die dll imports für linux anpassen.
Zum Vergrößern anklicken....
Ich hab jetzt mal in der NoDave.h auch für BCCWIN int anstelle von HANDLE geschrieben und dann in C# von IntPtr zu int.

Funktioniert mit Win32, Win64, Linux64.
(ISO over TCP IP)

"int" ist in C# und C Int32.
IntPtr (void*) ist entweder 32 oder 64 Bit
 
Thomas_v2.1 schrieb:
Im Prinzip ja, da gibt es aber mindestens 3 Möglichkeiten und Formate. Einmal für alle 1200er vor v3, dann für alles danach und 1500, und du kannst auch alles in einem Rutsch im xml-Format lesen.
Zum Vergrößern anklicken....
Hallo Thomas,
du hast geschrieben, dass du einen S7CommPlus Treiber für Wireshark geschrieben hast.
Nach dem die neue 840d Evoline auch mit ner 1500 SPS kommt wird das langsam interessant. Wie schätzt du den Aufwand ein das ganze in NoDave einzubauen?
 

Similar threads

E
Snap7 Zugriff auf Dual-Port RAM / FB15 / SINUMERIK
Antworten
1
Aufrufe
5K
Jochen Kühner
Jochen Kühner
Zurück
Oben