Step 7 840D sl NCU Variablen und Antriebsparameter lesen/schreiben

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wobei ich mir hier nicht sicher bin, wie ich korrekter weise eine Float-Zahl aus dem Hex-Wert im Byte-Puffer bekommen kann

in Buff steht (bis auf manchmal Endian-Verdreht exakt die Daten die man im Wireshark-Log sehen kann)

also kommst du an einen 32bit-float mit

float value = *(float*)[COLOR=#3E3E3E][FONT=Courier]pRWNCK->Buff;

die 2 Fehler mit mehreren Variablen lesen oder mit dem vorher was anderes lesen sind echt komisch - leider habe ich keine NC hier um das mal zu probieren
ich probier mal uebers Wochenende Testcode von mir einzustellen damit kannst du dann mal ein Vergleichstest machen


[/FONT][/COLOR]

 

[Thomas_v2.1]

Ist es vielleicht nicht erlaubt, in einer Anfrage Daten aus unterschiedlichen Areas zu lesen?

 

[gravieren]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist es vielleicht nicht erlaubt, in einer Anfrage Daten aus unterschiedlichen Areas zu lesen?

In einem Auftrag (z.b. von einer PLC-Steuerung) dürfen in einem Auftrag nur NCK gelesen werden.
Im nächsten Auftrag können dann die Antriebsdaten gelesen werden.

Gemischter Betrieb war bei mir NICHT möglich !
Steuerung war 840pl FW 6.3.28

Ich denke, das könnte das Problem sein ! ?

 

[st_rupp]

Den Gedanken mit der gemischten Abfrage von NCK- und Drive-Variablen hatte ich auch schon.. Komisch, eigentlich sollte das doch keinen Unterschied machen da ja auch die Drive-Variablen über die NCK abgefragt werden.
Ich dachte der Sinn der NCKReadMixEX-Funktion wäre ja gerade mehrere Variablen aus unterschiedlichen Bereichen auf einmal zu lesen..??!
Aber das erklärt noch nicht warum ich in einem Aufruf nicht mehrere Antriebsparameter (Gleiche Area, gleicher Block, nur andere Unit) lesen kann. Es kommt zwar keine Fehlermeldung aber falsche Werte..

Noch mal deutlich: Ich lese die Daten der Antriebe aus der NCK (Bereich eNCK_FeedDrives bzw. eNCK_MainDrives / Block M) unter Verwendung der NCKReadMixEx-Funktion, NICHT direkt aus den Antrieben selbst!
Die Verbindung besteht nur per Ethernet zur NCU -> Slot 3 (NCK), keine Verbindung zu den Antrieben!

 

[LowLevelMahn]

Den Gedanken mit der gemischten Abfrage von NCK- und Drive-Variablen hatte ich auch schon.. Komisch, eigentlich sollte das doch keinen Unterschied machen da ja auch die Drive-Variablen über die NCK abgefragt werden.

die NC-Kommunikation scheint da nicht so homogen wie die PLC-Kommunikation zu sein, da gibt es hin und wieder mal kleine Einschränkungen - das könnte so eine sein, auch wenn nur ueber die NC kommuniziert wird

Ich dachte der Sinn der NCKReadMixEX-Funktion wäre ja gerade mehrere Variablen aus unterschiedlichen Bereichen auf einmal zu lesen..??!

AGLink arbeitet so wie ich das sehe sehr nah an der Protokollschicht - damit man damit z.B. auch performante OPC-Server usw. implementieren oder andere Besonderheiten des Protokolls nutzen kann
und beim PLC-Protokoll gibt es glaube ich keine solchen Ausnahmen

Aber das erklärt noch nicht warum ich in einem Aufruf nicht mehrere Antriebsparameter (Gleiche Area, gleicher Block, nur andere Unit) lesen kann. Es kommt zwar keine Fehlermeldung aber falsche Werte..

Ich bin mir auch noch nicht sicher wo der Fehler herkommt - daher habe ich mal ein kleines Testprogramm angehaengt - C/C++ mit Solution fuer VS2010 - ansonsten einfach die main.cpp kompilieren
- assert wenn ein wichtiger Fehler auftritt, und Ausgabe aller Werte, mit deinen 4 Variablen und den 3 Tests

leider konnte ich es nicht an einer NC testen weile ich gerade keine im Zugriff habe - aber wenn es wieder so weit ist würde ich auch gerne solche Fehler wie bei dir auftreten vermeiden

Zip-Update:
Noch eine Prüfung+Ausgabe fuer falsche Variablenkonfiguration eingebaut, Ausgabe der Werte nur wenn kein Fehler in der Variable

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

@st_rupp

Hoffe du bekommst mein Beispiel ohne Probleme zum laufen und kannst du bitte bei Source-Änderungen das ganze auch als Zip anhängen?

 

[st_rupp]

Habe dein Programm heute getestet, vielen Dank, da hast du dir ja einige Arbeit gemacht! Ergebnisse siehe Anhang.

Dabei gab's zunächst noch 3 kleine Probleme, die habe ich in der Main.cpp korrigiert und mit dran gehängt:
- Zeilennummern und Unit der Parameter waren in der Deklaration vertauscht
- ein Typedef-Fehler bei der Deklaration von char as uint8, habe ich auskommentiert, dann konnte ich's kompilieren
- Damit die Ausgabe auf der Konsole gelesen werden kann hab ich die "Beliebige Taste zum beenden drücken.." abfrage eingebaut

Resultate waren genau wie bei meinen bisherigen Tests:
- Werden die 3 Antriebs-Parameter (hier die Temperaturen) einzeln abgefragt, so sieht man im Wireshark die korrekten Werte.
- Werden alle 3 auf einmal abgefragt, sind die Werte bei allen 3 gleich und entsprechen dem Wert der ersten abgefragten, also 1. korrekt, Rest falsch
- Wird vor den Antriebsparametern eine Variable aus einem anderen Bereich (hier getestet mit dem NC-Programmnamen) gelesen, so erhält man für die Antriebsparameter den Fehler "Object does not Exist"
- In keinem Fall werden irgendwelche Werte vom Programm auf der Konsole ausgegeben (Siehe Screenshot), immer alles = 0, was ja eigentlich irgendwo zwischen 20-30 °C liegen sollte.

--> Für die ersten 3 Fälle habe ich keine Idee woher das kommt, fürchte jedoch dass es ein Bug der Sinumerik Firmware ist, also außerhalb der AGLink Software.
Ich werde das Ganze dazu noch einmal an einer anderen Maschine mit anderem SW-Stand testen.

--> Für den 4. Fall (Daten werden richtig von der Sinumerik gelesen, aber nicht "ausgewertet") sehe ich 2 Erklärungen: Die Daten landen erst garnicht im Puffer (-> Bug im AGLink) oder ich bin zu doof den Puffer richtig auszulesen...

Anhang anzeigen Test_Ergebnisse.zip


Update:
Hab weiter getestet. Es ist möglich mit einem Aufruf mehrere Parameter der GLEICHEN Unit (also des gleichen Antriebs) auszulesen. z.B. Motortemperatur, Geberposition, Winkelposition.
Dabei kommen die richtigen Werte im Wireshark, die NCK_demo.exe wie auch mein eigener Code zeigen aber nach wie vor keine Werte, weder in der Buffer- bzw. Byte-Ansicht noch als Wert.
Nur wenn man in einem Aufruf Werte aus mehreren Units lesen will funktioniert's nicht.

 

[LowLevelMahn]

Habe dein Programm heute getestet, vielen Dank, da hast du dir ja einige Arbeit gemacht!

nur ein wenig zusammenkopiert

Damit die Ausgabe auf der Konsole gelesen werden kann hab ich die "Beliebige Taste zum beenden drücken.." abfrage eingebaut

ich mache sowas immer mit Umleitung

Konsole: nck_drives_test.exe > out.txt
oder als Angabe bei den Debug-Einstellungen im Studio

dann muss man auch kein Screenshot machen

Werden alle 3 auf einmal abgefragt, sind die Werte bei allen 3 gleich und entsprechen dem Wert der ersten abgefragten, also 1. korrekt, Rest falsch

sieht aus wie ein Firmware-Bug - was soll der Sinn davon sein

Für den 4. Fall (Daten werden richtig von der Sinumerik gelesen, aber nicht "ausgewertet") sehe ich 2 Erklärungen: Die Daten landen erst garnicht im Puffer (-> Bug im AGLink) oder ich bin zu doof den Puffer richtig auszulesen...

ich bin scheinbar auch zu doof - ist ja mein Code

siehst du im Debugger irgendwelche Daten im buffer nach dem Read?

und kannst du bitte noch printf("Test1\n") ... davor einbauen dann kann man die Tests - falls noch welche dazu kommen besser unterscheiden

 

[st_rupp]

Zuviel Werbung?
-> Hier kostenlos registrieren

So, hab noch ein paar weitere Tests gemacht, siehe Anhang.
Der Buffer enthält beim CNC-Programmnamen den Klartext, bei den Antriebsparametern nichts (siehe Screenshots).
Also hier zumindest ein Fehler im AGLink?!

@ Rainer Hönle: Könnten Sie sich das mal ansehen? Danke!! Und haben Sie vlt. eine Idee, warum in einem ReadMixEx-Auftrag nur Daten aus einer Unit gelesen werden können? Bzw. warum der Zugriff nicht funktioniert wenn vor dem Antriebs-Parameter ein anderer NCK-Parameter gelesen wurde?

Anhang anzeigen Test_Ergebnisse2.zip

Nachtrag:
Habe einen Test an einer zweiten NC mit neuerer SW bzgl. des Verhaltens bei einer NCKReadMixEx mit unterschiedlichen Units im Bereich FeedDrives / MainDrives Block M gemacht.
Die erste Maschine hat V02.06+SP01+HF07 -> Alle zurückgelieferten Werte sind gleich und entsprechen dem ersten gelesenen Wert
Die zweite hat V02.07+SP3+HF10 -> Die NC meldet einen Fehler und liefert garkeine Werte
Siehe Wireshark Traces:
Anhang anzeigen trace Spinner.zip

 

[LowLevelMahn]

im Test 06 ist der Programmname am Ende ploetzlich als DINTEGER (0x06) - anstatt wie bei den anderen Reads als OCTET STRING (0x09), ich denke da macht die Firmware gehörig was falsch - möglicherweise steht aber auch in irgendeiner Siemens Doku vergraben das man Drive-Zugriffe nur Driver-weise nutzen und nicht mischen darf

 

[st_rupp]

Ich denke du hast recht, es scheint beim Zugriff auf die Drive-Parameter grundsätzlich nicht erlaubt zu sein in einer Anfrage Daten mehrere Antriebe = Units zu lesen.. (Siehe Nachtrag oben)
Na gut, dann muss ich hald jeden Antrieb einzeln abfragen... nicht schön aber was soll's.
Wenn ich nun wenigstens an die Werte kommen würde... woran kann es denn liegen, dass die Daten nicht im Puffer landen?
Könnte das das selbe Problem sein, dass hier im Thread schon ein paar Seiten weiter vorne beschrieben wurde?

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich nun wenigstens an die Werte kommen würde... woran kann es denn liegen, dass die Daten nicht im Puffer landen?
Könnte das das selbe Problem sein, dass hier im Thread schon ein paar Seiten weiter vorne beschrieben wurde?

Bei dir sind es die gleichen Typen - also diese die gefehlt haben, sollte aber in der aktuellen Version schon drinn sein, wenn Rainer damals nicht nur eine Beta verschickt hat

 

[LowLevelMahn]

kannst du noch die AGLink-Version mit ausgeben:

int major = 0;
int minor = 0;
int revision = 0;
int build = 0;
char date[30];
AGL_GetVersionEx(&major, &minor, &revision, &build, date);
printf("AGLink-Version: %d.%d.%d.%d %s\n", major, minor, build, revision, date);

 

[st_rupp]

Die Version ist:

AGLink Version: 4.7.7.0 2014-09-10

 

[st_rupp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hab gerade vom DeltaLogic Support eine neue DLL (4.7.41.0) bekommen, Nun funktioniert's!
Siehe Test-Ergebnisse im Anhang:

Anhang anzeigen out.txt

 

[st_rupp]

Jetzt fehlt mir noch ein Bereich: Die Einspeisung des Antriebssystems.

Im HMI unter "Inbetriebnahme" -> "Maschinendaten" gibt es folgende Kategorien:

• "Allgemeine MD" - Lesbar mit AGLink via: Bereich eNCK_AreaNCK / Block M --> Spalte entspricht MD-Nummer, Unit & Zeile = 1
• "Kanal MD" - Lesbar mit AGLink via: Bereich NCK_AreaChannel / Block M--> Spalte entspricht MD-Nummer, Unit entspricht Kanal-Nr., Zeile = 1
• "Achs MD" - Lesbar mit AGLink via: Bereich eNCK_AreaAxis / Block M --> Spalte entspricht MD-Nummer, Unit entspricht Achs-Index, Zeile = 1
• "Anwendersichten" - ? (für mich nicht wichtig)
• "Control-Unit MD" - ? (für mich bislang nicht wichtig)
• "Einspeisungs MD" - ? (wäre für mich interessant)
• "Antriebs-MD" - Lesbar mit AGLink via: eNCK_AreaFeedDrive bzw. MainDrive / Block M --> Spalte entspricht Parameter-Nummer, Unit entspricht Antriebs-Index, Zeile = 1

Hat jemand eine Idee, in welchem Bereich ich die MD's der Einspeisung lesen kann? Ich vermute stark Block M & Spalte = Parameter-Nummer, Aber keine Ahnung welche Area. Unit vermutlich gleich Index der Einspeisung, da ja (meines Wissens) mehrere Einspeisungen vorhanden sein können.

 

[LowLevelMahn]

Die Ergebnisse von Test 05 und Test 06 sind echt ein Firmware-Bug-Witz

Test 05


CNC-Progname
[0] (aus wireshark: Transport size: OCTET STRING (0x09)) <-- OK
Result: AGL40_SUCCESS
eNCK_MDB_String: _N_VERSUCHSPROGRAMM_V1_MPF

R35(X)
[1] (aus wireshark: Transport size: OCTET STRING (0x09))
Result: AGL40_NO_DATA_ERROR

R93(X)
[2] (aus wireshark: Transport size: OCTET STRING (0x09))
Result: AGL40_NO_DATA_ERROR

R94(X)
[3] (aus wireshark: Transport size: OCTET STRING (0x09))
Result: AGL40_NO_DATA_ERROR

nur verdrehen und schon geht die Party los

Test 06

R35(X)
[0] (aus wireshark: Transport size: REAL (0x07))
Result: AGL40_SUCCESS
eNCK_MDB_Float32: 19.099997

R93(X)
[1] (aus wireshark: Transport size: REAL (0x07))
Result: AGL40_SUCCESS
eNCK_MDB_Float32: 236.920166

R94(X)
[2] (aus wireshark: Transport size: REAL (0x07))
Result: AGL40_SUCCESS
eNCK_MDB_Float32: 56.920174

CNC-Progname
[3] (aus wireshark: Transport size: DINTEGER (0x06)) ????? in Test 05 als OCTET STRING (0x09)
Result: AGL40_SUCCESS
eNCK_MDB_String:

wäre schön wenn du noch ein bisschen spielen könntest - vielleicht erkennst du ja ein Prinzip dahinter

@gravieren

passiert sowas auch wenn man von der PLC die NC-Daten so auslesen will?

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

• "Einspeisungs MD" - ? (wäre für mich interessant)

am "einfachsten" wenn du auf dem HMI ein Wireshark-Log erstellst wenn die Daten angezeigt werden
also:

1. Wireshark starten
2. auf die Einspeisungs MD Ansicht wechseln
3. Wireshark-Logging starten
4. zwischen 2 gesuchten Variablen mit prägnanten Werte hin/her-wechseln (2-3 mal)
5. logging stoppen

Log hier einstellen

 

[LowLevelMahn]

kannst du noch 3 weitere Tests einbauen mit

R35(X)
CNC-Progname
R93(X)

RPA0
R35(X)
R93(X)

R35(X)
R93(X)
RPA0

RPA0 = R-Parameter[0] = eNCK_AreaChannel,eNCK_BlockRP,1,1,1,eNCK_MDB_Float64,8

 

[st_rupp]

Baue die Tests gleich ein, werde es dann an beiden Maschinen ausprobieren.

Das mit Wireshark ist ne gute Idee... funktioniert aber bei mir nicht, da unsere Maschinen nur das "light-HMI" haben, also die Thinclient-Panels (TCU's) die per VNC auf das interne HMI der NCK zugreifen. Keine PCU50.

Bräuchte also jemanden mit ner PCU 50, der das Testet oder einen anderen Ansatz.