Ordnerstruktur S7 Projekt

Ja die GSD ist nach der automatischen installation komplett und absolut identisch vorhanden.
Ich habe ein Test Projekt erstellt und Archiviert.
Anschließend die GSD aus dem Installationsverzeichnis von Step7 gelöscht.
Dann das Projekt dearchiviert und geladen.
Wenn man dann die HW Konfig öffnet, erscheint die Meldung, dass die GSD Datei xy automatisch instelliert wurde.

Meine GSD Datei ist 23671 Byte groß.
 
Grad mal einen Versuch gemacht. Das steckt definitiv in der h0mSave7\s7hstatx\HATTREME1.DBT.
In der Tabelle existieren mehrere MEMOARRAYM, denke mal das ist ein komprimiertes Bytearray. Die Vergrößerung ist ungefähr so viel, wie wenn ich die GSD mittels zip komprimiere.
 
Du brauchst für die Programmiersprache deiner Wahl einen dBase Treiber. Um das alles einzulesen benötigst du aber noch etliche Daten mehr über die Projektstruktur, da alles über diverse IDs zusammenhängt. Wenn es dir nur um diese Daten geht, würde ich einfach alles in der Tabelle durchgehen und versuchen irgendwie zu entpacken.
 
Du brauchst für die Programmiersprache deiner Wahl einen dBase Treiber. Um das alles einzulesen benötigst du aber noch etliche Daten mehr über die Projektstruktur, da alles über diverse IDs zusammenhängt.
Das weiß ich und habe auch schon einiges zum Aufbau und der Datenstruktur von Step7 Projekten verstanden.

Jetzt geht es zunächst nur um den Export der GSD Dateien aus dem Step7 Projekt.
Ich habe es noch nicht hinbekommen die Daten zu extrahieren.
Hier steht beschrieben wie die Datenstruktur innerhalb der DBT Datei aufgebaut ist:
dbf dbt file format
Ich habe für den Hexeditor 010 Editor ein Binary Template gebaut, doch es scheint noch etwas nicht zu passen.
Die Tabelle welche meiner Meinung nach die Daten enthalten muss, konnte ich noch nicht herauslösen und irgenwie entpacken.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe dafür immer das XBase Modul von Perl verwendet. In C# gibt es auch Unterstützung für dBase, das funktioniert aber nicht mit allen Tabellen wie auch mit dieser hier nicht (eventuell weil mit Index?).
Auf jeden Fall weiß ich auch dann noch nicht, wie die Daten komprimiert wurden. Ich habe die Daten der Tabelle mal in eine Datei gespeichert, und versucht einfach mal mit 7zip zu entpacken. Das funktioniert aber auch nicht, obwohl 7zip viele Formate kennt. Also entweder da ist noch ein Header davor, oder das ist ein anderes Format. Da müsstest du eben mal ein paar Sachen ausprobieren wann sich wo etwas ändert.

Wozu benötigt man das denn so oft, dass sich der ganze Aufwand lohnt?
 
Alle unsere Projekte, welche vor der Auslieferung der Anlage gespeichert werden, sollen geprüft werden, ob die GSD Daten in der richtigen Version verwendet wurden. Wir sind Maschinenbauer und jeder Mitarbeiter der Inbetriebnahme könnte da Fehler machen.
Daher soll das zur Verbesserung der Qualität und Vermeidung von Problemen automatisch geprüft werden.
Ich hatte schon viele Probleme damit und muss ständig für Nachrüstungen GSD Dateien bereitstellen, da der Techniker weder diese noch das Ursprungsprojekt hat. Der Techniker muss das Projekt aus der Maschine herunterladen und die Hardware ändern. Doch wenn die GSD Daten fehlen oder ferhlerhaft sind ist die Anlage nach dem hochladen des Projekts nicht mehr betiebsbereit.

Ich arbeite dazu mit C# und habe auch festgestellt, das dies mit dieser dBase nicht funktioniert.

Habe auch schon viel probiert. Habe auch 7-Zip verwendet und versucht, meien Exporte so zu entpacken.
 
Zuletzt bearbeitet:
Vielleicht reicht es ja, wenn du die gepackten Daten mit einem Referenzprojekt vergleichst.

Ich hatte mir mal notiert, dass ich das Perl-Modul von XBase von Linux verwenden musste, damit es unter Windows funktioniert. Aber keine Ahnung ob das bei einer aktuellen Installation immer noch so ist. Mit Perl kannst du die Daten so dumpen (erzeugt eine Datei je Zeile):

Perl:
#!/usr/bin/perl -w
use strict;
use warnings;
use DBI;
use XBase;

my $s7_project_path = "G:/TestVergl/Proj";
 
my $data_source_name = 'DBI:XBase:' . $s7_project_path . '/hOmSave7/s7hstatx/';
my $dbh = DBI->connect($data_source_name) or die $DBI::errstr;
my $sth = $dbh->prepare('SELECT IDM, ATTRIIDM, ATTFORMATM, MEMOARRAYM FROM HATTRME1');
$sth->execute or die $sth->errstr;

my @row;
my $i = 1;
while(@row = $sth->fetchrow_array) {
    my $filename = 'ROW' . $i .'_IDM'. $row[0] . '_ATTRIIDM' . $row[1] .  '_ATTFORMATM' . $row[2] . '_MEMOARRAYM.dat';
    open my $fh, '>:raw', $filename or die;
    print $fh $row[3];
    close $fh;
    $i = $i + 1;
}
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eigentlich möchte ich einen Crawler bauern der alle Projekte die bei unseren verschiedenen Produktionsstandorten gesichert werden, durchgeht.
Die daraus extrahierten GSD's will ich auch automatisch verteilen und mit den originalen in unsere VersionControl abgleichen.
So das ich auch immer sicher nachvollziehen kann in welchem Projekt welche GSD Dateien für was verwendet wurden.
Am Ende soll dann auch eine Anwendung mit Datenbank dabei herauskommen, welche die GSD's auf den Notebooks all unserer Techniker weltweit installiert.
Schon mal vielen Danke für dein Engagement und Hilfe hier.
 
Ich würde dann weiter so vorgehen, dass ich erst einmal ein paar Daten sammeln würde. Also Minimalprojekt mit einem DP-Slave. Dann an der GSD-Datei immer ein Zeichen tauschen, GSD neu installieren, konfigurieren und übersetzen, und Projekt sichern. Dann die Datenbanktabellen dumpen und vergleichen, um festzustellen ob es da noch einen festen Teil gibt. Perl ist auch nicht mehr die Sprache meiner Wahl, aber nur um zu sehen ob und wie es überhaupt geht, würde ich damit starten, weil man direkt loslegen kann.
 
Der Techniker muss das Projekt aus der Maschine herunterladen und die Hardware ändern. Doch wenn die GSD Daten fehlen oder ferhlerhaft sind ist die Anlage nach dem hochladen des Projekts nicht mehr betiebsbereit.
Wäre es nicht besser, lieber ein vernünftiges Projektdatei-Management aufzubauen, anstatt an dem Gemurkse herumzukontrollieren? Warum haben die Techniker kein Projekt mit der korrekten Hardware Konfig? Bei Eurem Vorgehen hat ja am Ende niemand ein aktuelles Projekt :eek: Sieht da noch jemand durch?
Was hat dieses Vorgehen (Hardware-Konfig ohne Projekt herausladen, ändern und wieder hineinladen) mit "Qualität und Vermeidung von Problemen" zu tun??? Und die Software passt sich automatisch an die geänderte Hardware an?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@PN/DP
Wir haben als Konzern die kritische Größe überschritten um das ändern zu können, was du vorgeschlagen hast.
Wenn das so einfach wäre hätte ich es schon gemacht.
Ich habe Zugriff auf die Projekte der Maschinen. Die Software kann immer alle Funktionen und der Techniker muss nur die Hardwarekonfig anpsssen und die Funktionen in der Software aktivieren. Die Hardware wird aus kostengründen nicht immer maximal in die Maschinen eingebaut.
Aus Konwhow Schutz Gründen und vorallem aus Haftungsgründen zur CE darf nicht Hinz und Kunz an der Software herumdoktern und Änderungen vornehmen die potentiell gefährlich für Mensch und oder Maschine sind. Die Techniker müssen ja keine Softwareexperten sein, das ist bei der Anzahl auch nicht leistbar. Trotzdem danke für deinen Vorschlag und so falsch ist er ja auch nicht, nur leider nicht umsetzbar.

@Thomas_v2.1
Danke für deine Unterstützung ich werde mir das mal anschauen und evtl. wie du vorgeschlagen hast mit Perl weitere Versuche machen.
Ich habe zwar noch nie mit gearbeitet und muss erstmal alles einrichten aber werde dann mal versuchen Ergebnisse zu erzielen.
Schritt für Schritt in kleinen Schritten vorgehen das kenne ich.
Ich berichte wenn ich was neues entdecke.
Wenn jemand noch weitere Erkenntnisse hat sehr gerne.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Würde jetzt noch tippen, das in der HOBJECT1.DBF das Feld "Id" mit dem Feld "IDM" in HATTRME1.DBF verknüpft ist (aber nur vermutung)
Fraglich ist dann noch wofür die Werte in AttrIIDM in HATTRME1.DBF stehen.
 
Ist selbst geschrieben:

bassiert auf einem CodeProject Projekt:

Hab das dann um alles möglich erweitert und Fehler gefixt bis es lief.
Was noch fehlt ist MDX support, zum lesen brauch ich den ja nicht, aber wenn man schreibsupport einbauen möchte müssen auch die MDX Files aktualisert werden, dafür hatte ich schon mal Typen angelegt:
und etwans angefangen:
Das aber nie fertig gebaut
 
Zurück
Oben