Libnodave und schreibgeschützte Bausteine?

C

Cliff

Level-1
Beiträge
162
Reaktionspunkte
15
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wieder einmal eine LibNoDave- Frage;-)
Habe schon ein wenig gesucht, bin aber nicht so recht fündig geworden...

Folgendes Problem:
Ich möchte mit LibNoDave einen Wert in einen DB schreiben. Soweit kein Problem.
Nun hatte mein Kollege aber den DB als 'schreibgeschützt in der AS' vermerkt (DB- Eigenschaften).
Effekt: LibNodave schreibt lustig 'rein und die CPU stürzt ab. DB anschliessend in der Steuerung nicht mehr vorhanden (Nach Reboot).

Eigentlich soll so etwas ja nicht vorkommen. Es würde mich aber trotzdem interessieren ob die Möglichkeit besteht diesen Schreibschutz mit LibNoDave auszulesen um einen solchen Absturz zu verhindern...

Ich verwende LibNodave unter Delphi mit der Komponente. Steuerung ist eine 416F...

Gruss Cliff
 
Hmm...

Ich hab bei mir in meiner Biblithek welche auf libnodave aufsetzt (siemensplctoolboxlib.codeplex.com) zumindest das senden des Passworts an die CPU implementiert, dann kannst du dir das schreiben freischalten:

Code: 
public void PLCSendPassword(string pwd)
        {
            libnodave.PDU myPDU = new libnodave.PDU();

            //PDU Header
            byte[] para;
            //PDU Data
            byte[] data;

            para = new byte[] { 0x00, 0x01, 0x12, 0x04, 0x11, 0x45, 0x01, 0x00 };            
            data = Helper.EncodePassword(pwd);
            _dc.daveBuildAndSendPDU(myPDU, para, data);

            byte[] rdata, rparam;
            int res = _dc.daveGetPDUData(myPDU, out rdata, out rparam);

            if (rparam[10] == 0xd6 && rparam[11] == 0x02)
                throw new Exception("Wrong Password");
        }


 static public byte[] EncodePassword(string pwd)
        {
            byte[] ASCIIByteArray = System.Text.ASCIIEncoding.ASCII.GetBytes(pwd);

            byte[] retByteArray = new byte[] { 0x75, 0x75, 0x75, 0x75, 0x75, 0x75, 0x75, 0x75 };

            int i = 0;
            foreach (byte b in ASCIIByteArray)
            {
                retByteArray[i++] = (byte)((b ^ 0x55));
            }
            retByteArray[2] = (byte)(retByteArray[2] ^ retByteArray[0]);
            retByteArray[3] = (byte)(retByteArray[3] ^ retByteArray[1]);
            retByteArray[4] = (byte)(retByteArray[4] ^ retByteArray[2]);
            retByteArray[5] = (byte)(retByteArray[5] ^ retByteArray[3]);
            retByteArray[6] = (byte)(retByteArray[6] ^ retByteArray[4]);
            retByteArray[7] = (byte)(retByteArray[7] ^ retByteArray[5]);

            return retByteArray;
        }
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Cliff schrieb:
Nun hatte mein Kollege aber den DB als 'schreibgeschützt in der AS' vermerkt (DB- Eigenschaften).
Effekt: LibNodave schreibt lustig 'rein und die CPU stürzt ab. DB anschliessend in der Steuerung nicht mehr vorhanden (Nach Reboot).
[...]
Steuerung ist eine 416F...
Zum Vergrößern anklicken....
Sowas muß eigentlich die CPU-Firmware zuverlässig verhindern bzw. den Schreibauftrag einfach nicht ausführen.
Wie äußert sich der "Absturz"? Die CPU geht sauber in STOP mit Diagnosepuffer-Eintrag oder was?
Kannst Du uns die genaue CPU-Bestellnummer und die Firmware-Version verraten?
Ist auf der CPU ein Safety-Programm drauf?
Hat Libnodave irgendeine Fehlernummer gemeldet?

@Jochen Kühner
Wenn ein DB die Bausteineigenschaft 'schreibgeschützt in der AS' hat, dann kann man nicht mit einem CPU-Passwort das Beschreiben von DB-Werten erzwingen - falls die CPU überhaupt ein Passwort hat. Einen 'schreibgeschützt in der AS'-DB kann man von außen nur komplett überschreiben, man muß den gesamten DB neu in die CPU laden.

Harald
 
PN/DP schrieb:
@Jochen Kühner
Wenn ein DB die Bausteineigenschaft 'schreibgeschützt in der AS' hat, dann kann man nicht mit einem CPU-Passwort das Beschreiben von DB-Werten erzwingen - falls die CPU überhaupt ein Passwort hat. Einen 'schreibgeschützt in der AS'-DB kann man von außen nur komplett überschreiben, man muß den gesamten DB neu in die CPU laden.

Harald
Zum Vergrößern anklicken....

Ahhh, da hab Ich mich verlesen. Dachte es ging ums CPU Passwort...
 
Moin,
so länger nicht geschaut:

Die CPU ist eine 416F-3 PN/DP, aktuellste Firmware (6.0.2).
Die CPU stürzt unter Einschaltung sämtlicher Blinkleuchten ab.
Die Kommunikation zur CPU (Ethernet) geht verloren. Sie reagiert nicht auf den 'Start/Stop'- Schalter.
Nach Power Down/Up ist der beschriebene DB aus dem Speicher verschwunden.

Fehlerstack kann ich im Moment leider nicht auslesen...

LibNoDave gibt keinerlei Fehlermeldung heraus. Man merkt lediglich das der Schreibzugriff länger dauert.

Habe mir im Moment damit beholfen das ich den Haken 'Schreibgeschützt in der AS' entfernt habe. Macht sowieso keinen Sinn da der Baustein ja beschrieben werden soll.

Gruss Cliff
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ob ein DB schreibgeschützt ist oder nicht steht im Bausteinheader des OBs, auf Offset 33: 0=normaler DB, 1=schreibgeschützt in AS.

Um diesen "Schreibschutz" im PC zu prüfen, ist es notwendig den Bausteinheader in den PC zu lesen. Dazu gigbt es in libnodave evtl. eine Funktion. In der Lib von J.Kühner wird es sehr warscheinlich solch eine Funktion geben.

Es ist natürlich ein Hammer das eine Siemens 416F-CPU alle viere von sich streckt, wenn jemand ein Schreibkommando auf einen geschützten DB losläßt.
Dass die gleich komplett abstürzt dürfte wohl nicht sein.

mfG. klaly
 
Moin klaly,

muss mir die andee Lib wohl noch einmal anschauen, obwohl - Eigentlich soll es nur ein Tool werden um bei der Inbetriebnahme einmalig grosse Datenmengen in die SPS zu schreiben...

Habe übrigens eben den Fehler noch einmal nachgestellt:
Fehlermeldung SPS:
Ereignis ID: 16# 4520
DEFEKT: Stop nicht erreichbar

Das beste:
In der Hilfe folgender Text: Angeforderter Betriebszustand: DEFKT :D

Gruss Cliff
 
Ich bin auch klaly's Meinung. Egal welcher Blödsinn von außen kommt, der Christbaum geht zu Weihnachten an, aber nicht in wegen einem solchen Zugriff.

@Cliff:
Mich würde ein wireshark-Log der Christbaumverursachung interessieren. Eventuell kommt ja eine seltsame Fehlermeldung und die Gute wartet auf eine seltsame Quittierung. Wäre so etwas machbar?
Wie reagiert eigentlich ein Siemens-Tool (WCF, ..) beim Schreiben in einen schreibgeschützten DB? Auch hier wäre ein Log interessant.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Meinung bin ich eigentlich auch. Hätte erwartet das die S7 den Zugriff abweist und LibNoDave mit einer Fehlermeldung zurück kommt...

Habe einmal einen Wireshark Abzug beigelegt.

Gruss Cliff
 

Anhänge

  • S7-Crash.zip
    4,3 KB · Aufrufe: 27
Cliff schrieb:
Habe einmal einen Wireshark Abzug beigelegt.

Gruss Cliff
Zum Vergrößern anklicken....
Im Log ist nur die Anfrage zum Variablenschreiben drin und keinerlei Reaktion von der SPS.
Wenn die wirklich nicht mehr zum Antworten kommt und gleich Weihnachten feiert, dann ist
dies ein gnadenloser Bug in der Firmware.
Ich vermisse auch den Verbindungsaufbau im Log, damit ich sehen kann wie mit dem Teilchen geredet
bzw. dass alles Wichtige protokolliert wird.
 
Moin Rainer,

ich hatte lediglich den Zeitpunkt des Crashes dokumentiert. Musste etwas mit den Haltepunkten (Delphi) tricksen damit der Dump nicht zu lang wird.

Die CPU verliert auf Schlag ihre Kommunikationsfähigkeit (Auch für den S7- Manager). Daher benötigt LibNodave wohl auch etwas länger für die Ausführung.

Kann evtl. nächste Woche noch einmal ein ausführlicheres Protokoll hochladen.

Gruss Cliff
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Habe das jetzt einmal
- an einer 414-3 PN/DP FW 5.2 getestet => Christbaum und tot
- und an einer 417-4 FW 4.1 getestet => Fehlerrückgabe Objektzugriff nicht erlaubt
Tja, da ist Siemens wohl ab FW 5.x etwas reingerutscht, was da nicht hingehört.
 
Cliff schrieb:
Kann evtl. nächste Woche noch einmal ein ausführlicheres Protokoll hochladen.

Gruss Cliff
Zum Vergrößern anklicken....

Nicht mehr notwendig. Wende Dich am Besten vertrauensvoll an Deinen Freundlichen bei Siemens :ROFLMAO::ROFLMAO:

Dazu ist es aber am Besten, das Problem mit original Siemens-Tools nachzuvollziehen. Hierzu kommt ja nur prodave V6 oder Softnet in Frage.
Wenn nicht, dann wird erst einmal alles auf libnodave geschoben. Hatte auch schon einmal das "Glück" mit ACCON-AGLink einen FW-Bug
zu entdecken. Und die Jungs dann dazu zu bewegen, dass sie vor der eigenen Türe kehren, ist nicht ganz einfach. Habe dies wie gesagt
mit einem kurzen Programm mit prodave geschafft. Hat allerdings sehr lange gedauert, bis das dann durch war. Ging auch über einen
großen Kunden von uns (der das Problem entdeckt hatte).
 
Zuletzt bearbeitet:
Moin Rainer,

danke für dein Engagement!
Für meinen Einsatzfall ist es nicht soooooo wichtig, da lediglich wir Programmierer mit dem Tool arbeiten. Von daher macht es keinen Sinn einen solchen DB mit einem Schreibschutz zu versehen. Da dies wohl auch ein sehr seltener Fall ist, ist er wohl auch beim Debugging der Firmware durch die Maschen gerutscht.

Man müsste jetzt einmal testweise diese Art von Zugriff über die Variablentabelle machen ;-)

Gruss Cliff
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Cliff schrieb:
Man müsste jetzt einmal testweise diese Art von Zugriff über die Variablentabelle machen ;-)
Zum Vergrößern anklicken....

Ist bereits erledigt. Auch bei der 414-3 PN/DP kommt hier eine Fehlermeldung "Steuern nicht erlaubt" und unter Hilfe findet man dann unter anderem als Ursache "Baustein schreibgeschützt". Die 417-4 habe ich dann nicht mehr getestet.
Man muss allerdings sagen, dass die Zugriffe über VAT auf Protokollebene komplett anders ablaufen als die mittels Variablen schreiben.
 

Similar threads

C
LibNoDave und Delphi XE (Problem?)
Antworten
7
Aufrufe
6K
marcengbarth
M
Zurück
Oben