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

Zuviel Werbung?
-> Hier kostenlos registrieren
Wollte es testen. Bekomme beim Kompelieren aber immer folgenden Fehler:

Der Typ- oder Namespacename 'DotNetSiemensPLCToolBoxLibrary' konnte nicht gefunden werden. (Fehlt eine Using-Direktive oder ein Assemblyverweis?)

Mit der alten .dll (v1.0.0) funktioniert es.

Hab das Problem gefunden. Du hast das Framework deines Projektes von v4.0 nach v4.52 geändert. Deshalb konnte ich zwar alles programmieren und auch die using hinzufügen, beim compilieren kam dann aber der Fehler.

Framework v4.52 ist zwar für x64 recht schön, wird jedoch von WinXP(Windows XP Embedded) nicht mehr unterstützt. Da ist bei v4.0 ende.
In der Industrie wird XP Embedded noch einige Jahre in Verwendung sein. Deshalb versuche ich solche Programme bis max. .Net4.0 zu programmieren.
 
Die DLL nutzt nun wieder Net 4.0! Hatte nur an einer stelle ein "await" drin, das hab Ich durch Task.Result geändert...

Ja geht den die Kommuniaktion zur NC?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Beim Lesen bekomme ich folgendes Exception

Code:
else if (res != 0 && res != 10)
                            throw new Exception("Error: " + _errorCodeConverter(res));

{"Error: context is not supported. Step7 says:Function not implemented or error in telgram."}
 
 bei DotNetSiemensPLCToolBoxLibrary.Communication.PLCConnection.ReadValues(IEnumerable`1 valueList, Boolean useReadOptimization) in c:\Users\1\Documents\GitHub\_DotNetSiemensPLCToolBoxLibrary\LibNoDaveConnectionLibrary\Communication\PLCConnection.cs:Zeile 2533.
 
Aufruf ist grundsätzlich wie in deinem Beispiel.

Code:
private void test()
        {
            var config = new PLCConnectionConfiguration("Test",
                LibNodaveConnectionConfigurationType.ObjectSavedConfiguration) { CpuIP = "192.168.214.1" };

            //var connection = new PLCConnection(config);
            DotNetSiemensPLCToolBoxLibrary.Communication.PLCConnection _myConn = null;
            string IPAdress = string.Empty;
            try
            {
                if (_myConn != null)
                {
                    if (_myConn.Connected)
                        _myConn.Disconnect();
                    _myConn.Dispose();
                }

                _myConn = new DotNetSiemensPLCToolBoxLibrary.Communication.PLCConnection("ConnectionName");

                _myConn.Configuration.CpuIP = !string.IsNullOrEmpty(IPAdress) ? IPAdress : "192.168.214.1";
                _myConn.Connect();
            }
            catch (Exception ex)
            {
            }

            var tag = new PLCNckTag() { TagDataType = TagDataType.Float, NckArea = 0xa, NckUnit = 0x8, NckColumn = 0x23, NckLine = 0x1, NckModule = 0x1a, NckLinecount = 0x1 };
            //var tag = new PLCTag("M1.0");

            _myConn.ReadValue(tag);

            Console.WriteLine("Tag:" + tag.Value);

            Console.ReadLine();
        }

Hier das wireshark
Anhang anzeigen r35_HMI.rar
Anhang anzeigen r35_LibNoDave.rar
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast du bei Libnodave überhaupt vorher eine Verbindung aufgebaut, oder ist dies nur im logfile nicht vorhanden?

In deinem HMI Logfile liest du:
Area = 5
Unit = 2
Column = 31
Line = 1
Module = 0x82
linecount = 1

Per Libnodave:
Area = 2
Unit = 8
Column = 35
Line = 1
Module = 0x1a
linecount = 1

Eine Area 0xa welche du in deinem Funktionsaufruf übergibst ist überhaupt nicht möglich, da dafür nur 3 Bits zur Verfügung stehen. Das geht dementsprechend maximal von 0 bis 7.
Ich kenne mich mit dem Sinumerik Zeugs Null aus, ich sehe nur was über den Draht geht.
 
An seiner Stelle würde ich darum auch zuerst mit den gleichen Werten testen, die er von seinem HMI erfolgreich gelesen hat.

Wenn er Area 0xa übergibt, fliegt das Bit 4 raus, darum ist auf dem Draht dann nur noch eine Area 2 zu sehen.

In der Bibliothek von Jochen darf bei diesen Bereichen nichts automatisch gepackt werden. Ein Mischbetrieb zwischen "normalem" Variablenzugriff und NCK Daten ist in einem Telegramm nicht möglich. Auch bei den NCK-Datenbereichen die gemeinsam in einem Telegramm gelesen werden dürfen scheint es diverse Einschränkungen zu geben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
An seiner Stelle würde ich darum auch zuerst mit den gleichen Werten testen, die er von seinem HMI erfolgreich gelesen hat.

Wenn er Area 0xa übergibt, fliegt das Bit 4 raus, darum ist auf dem Draht dann nur noch eine Area 2 zu sehen.

In der Bibliothek von Jochen darf bei diesen Bereichen nichts automatisch gepackt werden. Ein Mischbetrieb zwischen "normalem" Variablenzugriff und NCK Daten ist in einem Telegramm nicht möglich. Auch bei den NCK-Datenbereichen die gemeinsam in einem Telegramm gelesen werden dürfen scheint es diverse Einschränkungen zu geben.

Das muß Ich dann noch anpassen, das keine gemischten Zugriffe erfolgen können... Werd Ich aber erst tun wenns überhaupt läuft! Woher weißt du das nichts gemischt werden darf, hast du das schon probiert?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab mir mal die Aufzeichnung genau angeschaut und den Code angepasst.

Code:
var tag = new PLCNckTag() { TagDataType = TagDataType.Float, NckArea = 0x5, NckUnit = 0x1, NckColumn = 0x23, NckLine = 0x1, NckModule = 0x82, NckLinecount = 0x1 };

Im Wireshark ist nur die Anfrage aufgezeichnet.

Den einzigen Unterschied, den ich gerade in meinen zwei neuen Aufzeichnungen sehe ist die "Protocol Data Unit Reference"

Anhang anzeigen r35_LibNoDave2.rar
Anhang anzeigen r35_Work.rar
 
Die PDU Ref dient der Zugehörigkeit von Anfrage zur Antwort. Üblicherweise wird die jedes Telegramm um z.B. 1 erhöht. Eine Null ist theoretisch erlaubt, aber unüblich. Die originale libnodave macht das glaube ich nicht.
Zeig doch mal die funktionierende Aufzeichnunge inklusive Verbindungsaufbau. Vielleicht benötigt man noch einen anderen TSAP beim Verbindungsaufbau, um sich so zu verbinden, dass auch NCK Daten gelesen werden können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht kann die NCU nur eine Verbindung verarbeiten. Wenn du neben libnodave noch mit einem anderen HMI draufhängst, ist das vielleicht zu viel. In deinem "HMI" Logfiles laufen außerdem auch zwei Verbindungen, eine die Datenbausteine liest, und eine andere die NCU Daten liest. Das sieht man in der Wireshark-Aufzeichnungen nicht mehr so auf einen Blick, weil ich die TCP-Ports aus der Statuszeile rauswerfe. Da muss man schon in die Telegramme reinschauen, oder einen passenden Filter setzen.
 
Zurück
Oben