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

[st_rupp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe gerade in den Schaltschränken unserer Maschinen nachgesehen, keine der beiden hat ein solches Modul verbaut.. denke diese Blöcke sind bei mir einfach ungenutzt. Dann bleibt noch der Block 0x81 "CULink". Da bin ich gerade noch dran, vlt. finde ich das noch raus. Von den Units her scheint er bei mir so aufgebaut zu sein wie die anderen 0x8er Blöcke (unit == Achsen bzw. DO-Index).

 

[LowLevelMahn]

wenn du Tests machst bitte die letzte main.cpp aus Post #138 (habs ein paar mal upgedated)

 

[st_rupp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok, ich glaube ich hab nun auch den 0x81 gefunden... wenn man im HMI / Inbetriebnahme das Service-Passwort eingibt, erscheinen bei den Maschinendaten zusätzlich die Punkte "Komm.-MD" (vermutlich Kommunikations-MD), "Allgemeine SD", "Kanal SD", "Achs SD" und "Anzeige MD".

Bereich 0x81 scheint den"Komm-MD" zu entsprechen. Die Parameter dort scheinen für die Kommunikation zwischen NCU und SINAMICS CU relevant zu sein, bzw. die Topologie des Antriebssystems abzubilden.
Besteht aber nur aus Int8 und Int16, die "Namen" (eigentlich Nummern zwischen 0 und 99) von Antriebsobjekten enthalten und Störcodes die (bei mir) alle 0 sind. Leider nicht besonders aufschlussreich, aber der Vollständigkeit halber...

Bzgl. der Variablenanzahl im Bereich FeedDrive teste ich später mit deiner neuen main.cpp weiter, jetzt geh ich erst mal was essen...

 

[LowLevelMahn]

mach auf jeden Fall einen Durchlaufen mit den Variablen die ich im Test stehen habe (mit split_vh_max_items = true und split_vh_blocks = true) - also wie es da steht mit single,block,smart
und dann noch einen weiteren Test mit allen Variablen die du lesen willst - also auch mit mehr als 19 von einem FeedDrive usw. - es sollte gehen, dann koennen wir die Zeiten mal anschauen

 

[st_rupp]

So, im Anhang die Ergebnisse.
Im 1. Test hab ich deine Variablen benutzt, außer der Cycle-Time, die hat Probleme mit der Buffer-größe gemeldet...
Im 2. hab ich dann 22Variablen vom ALM (Block 0x83) und jew. 6 (3 aus Block M und 3 aus Block0x82) von jedem der 3 Antriebe... das hat so noch nicht funktioniert. Was macht denn deine Smart-Funktion, Nach was werden die Aufrufe aufgeteilt?

Soweit ich das verstanden habe, müssten
1. Anfragen mit unterschiedlichen Units aufgeteilt werden (unterschiedliche Units gleichzeitig scheinen ja generell nicht zu funktionieren)
2. Anfragen mit Area H/V von den anderen Areas getrennt werden
3. H/V Anfragen nach Blöcken aufgeteilt werden, bei anderen Areas ist das egal (bei der alten Firmware kommen sonst für alle Blöcke die Werte des 1. Blocks, bei der neueren AGL40_WRONG_KONTEXT)
4. H/V Anfragen max. 19 Variablen in einem Auftrag lesen (unabhängig vom Datentyp / Länge der gelesenen Variablen)

Richtig?!
Anhang anzeigen Test_Ergebnisse9.zip

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im 1. Test hab ich deine Variablen benutzt, außer der Cycle-Time, die hat Probleme mit der Buffer-größe gemeldet...

der liefert als Fehlermeldung die notwendige Größe (einfach anhand davon die Variable richtig konfigurieren)

Im 2. hab ich dann 22Variablen vom ALM (Block 0x83) und jew. 6 (3 aus Block M und 3 aus Block0x82) von jedem der 3 Antriebe... das hat so noch nicht funktioniert.

hat sich nicht oder hatte sie nicht - also ging es?

Soweit ich das verstanden habe, müssten
1. Anfragen mit unterschiedlichen Units aufgeteilt werden (unterschiedliche Units gleichzeitig scheinen ja generell nicht zu funktionieren)
2. Anfragen mit Area H/V von den anderen Areas getrennt werden
3. H/V Anfragen nach Blöcken aufgeteilt werden, bei anderen Areas ist das egal (bei der alten Firmware kommen sonst für alle Blöcke die Werte des 1. Blocks, bei der neueren AGL40_WRONG_KONTEXT)
4. H/V Anfragen max. 19 Variablen in einem Auftrag lesen (unabhängig vom Datentyp / Länge der gelesenen Variablen)

beim 1. Punkt gilt das aber nur fuer V,H,C - beim Rest ist es (scheinbar) egal

 

[LowLevelMahn]

laut deiner main.cpp aus Test_Ergebnisse9.zip sind die beiden bools split_vh_max_items und split_vh_blocks immer noch auf false
dann gibts kein V,H Block und Variablenanzahl Splitting - diese bitte auf true stellen - oder was denkst du warum ich das dazu schreibe

und probier bitte nochmal die H-Variable zu lesen (nach Size/Typ korrektur) - also nur 1 in vars, auch wenn es nicht klappt davon ein einzelnes Wireshark Log

 

[st_rupp]

der liefert als Fehlermeldung die notwendige Größe (einfach anhand davon die Variable richtig konfigurieren)

ja macht er.. er sagt er braucht 2 Byte... die Variable ist aber schon als uint16 mit 2 Byte konfiguriert..?

hat sich nicht oder hatte sie nicht - also ging es?

nein, hat nicht funktioniert.

beim 1. Punkt gilt das aber nur fuer V,H,C - beim Rest ist es (scheinbar) egal

Beim Rest spielen die Units (meines Wissens nach) auch keine Rolle, oder?

laut deiner main.cpp aus Test_Ergebnisse9.zip sind die beiden bools split_vh_max_items und split_vh_blocks immer noch auf false
dann gibts kein V,H Block und Variablenanzahl Splitting - diese bitte auf true stellen - oder was denkst du warum ich das dazu schreibe :smile:

War etwas im Stress, hab das wohl übersehen.. werd's am Montag nochmal probieren.

und probier bitte nochmal die H-Variable zu lesen (nach Size/Typ korrektur) - also nur 1 in vars, auch wenn es nicht klappt davon ein einzelnes Wireshark Log​

Siehe oben, wireshark log mach ich auch am Montag

Schönes Wochenende!

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

bin gespannt was mit der H-Variable los ist

mal schauen ob mit den beiden bools auf true dann alles klappt - mal schauen wie deine Zeiten noch gedrückt werden können

bis Montag

 

[LowLevelMahn]

nochmal die main.cpp überarbeitet - jetzt ist alles so eingestellt wie soll und alle Tests laufen so ab wie nötig - der H-Variablen-Test ist am Ende also reicht ein komplettes out.txt+Wireshark-Log von der Spinner

 

[st_rupp]

Guten Morgen,
bevor ich weiter testen kann muss ich für unser Projekt eine kleine Powerpoint zusammenstellen und meinen Chef's erklären wie der Zugriff funktioniert...
Ich konnte leider bei Deltalogic keine Info's dazu finden auf welchem Protokoll die AGLink SW basiert.
Kann mir einer von euch hier bitte weiterhelfen? Müssen keine technischen Details sein, eine grobe Beschreibung sollte reichen.
Hier was ich bisher rausgefunden habe:
- "Früher" hat der Zugriff mal mit Dynamic Data Exchange (DDE) funktioniert, ist aber wohl veraltet
- Wie ich ja im Wireshark gesehen habe handelt es sich bei der Kommunikation um das S7 Protokoll, Erklärung dazu habe ich hier gefunden: https://wiki.wireshark.org/S7comm
- Aber wie ist das nun auf beiden Seiten implementiert? Die Sinumerik kann das wohl "nativ", ist es dann korrekt AGLink als eine Art "S7-Treiber" zu bezeichnen?
- Falls ja, auf welchem Layer wäre AGLink anzusiedeln?
Wäre für eine kurze Erklärung sehr dankbar!

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Genau, die Sinumerik (sowohl PLC als auch NCK) unterstützen das S7-Protokoll nativ, haben es also direkt "im Bauch". ACCON-AGLink ist ein S7-Treiber, der die Spezialitäten der S7-PLCs und der Sinumerik-NCKs implementiert hat und mit diesen Geräten reden kann.
Laut Siemens wäre dies Layer 7 und darunter (ich nenne es trotzdem intern Layer 5, da meiner Meinung nach für einen Layer 7 noch mehr dazugehört).

 

[st_rupp]

Super, danke für die schnelle Erklärung!!

 

[LowLevelMahn]

wie laufen die Tests?

 

[st_rupp]

Zuviel Werbung?
-> Hier kostenlos registrieren

So, hier die neuen Ergebnisse. Das Splitting funktioniert jetzt!
Im 2. Test habe ich noch ein paar allgemeine Variablen dazu gefügt und die Bufflen bei den H-Variablen auf 4 / Int32 geändert, da im Wireshark log 4 als Größe in der Antwort der NCK stand. Hat dann zwar keinen Fehler mehr geliefert, aber Wert = 0, keine Ahnung ob das richtig ist so...

Anhang anzeigen Test_Ergebnisse10.zip

 

[LowLevelMahn]

kannst du auch einen Release-Mode-Test machen:

1. Release-Mode kompilieren
2. ausserhalb der IDE (sonst ist immer noch der Debugger aktiv und macht alles langsamer) die out.txt erzeugen -> was sagst du zu den Zeiten

 

[LowLevelMahn]

und die Bufflen bei den H-Variablen auf 4 / Int32 geändert, da im Wireshark log 4 als Größe in der Antwort der NCK stand. Hat dann zwar keinen Fehler mehr geliefert

ich mache es falsch - da gibt es eine AGL_CheckVarSize... Routine - die rufe ich jetzt auf, dann kommt es auch richtig raus

, aber Wert = 0, keine Ahnung ob das richtig ist so...

besser als nichts - vielleicht findet sich noch jemand mit 2 Channels und ein paar H-Variablen

 

[st_rupp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok, hier also der Test als release-Build.
Ist in der Tat schon nochmal deutlich schneller geworden. So funktioniert das gut! 200ms, damit kann ich arbeiten
Wenn die Deltalogics diese "Smart-Read"-Funktion jetzt noch in das AGLink integrieren, dann könnte ich meinen Code deutlich schöner und einfacher gestalten.
4D Vektoren machen das ganze aktuell etwas unübersichtlich...

Anhang anzeigen Release_Test.zip

 

[Thomas_v2.1]

Also wenn es ein Ergebnis gibt wie die bisher unbekannten 0x8.. Module zu bezeichnen sind, dann könnte mir das ggf. jemand mitteilen, und ich pflege das dann bei Wireshark ein.

 

[st_rupp]

Also, die 0x8er Blöcke sind in der AreaFeedDrive wie folgt belegt:

0x80
Parameter der SINAMICS Control Unit, im HMI "Control-Unit-MD" genannt
Unit entspricht der Nummer des Control Moduls (es können mehrere in einem Antriebsverband vorhanden sein) Unit 1 == CU 1
Column entspricht der Nummer des MD's, z.B. 35 bei p0035
Row ist bei einzeiligen Parametern = 1, bei mehrzeiligen Parametern der Index in eckigen Klammern + 1, z.B. 1 bei p0039[0] oder 5 bei p0039[4]

0x81
Parameter zur Konfiguration der Kommunikation im Antriebsverband, im HMI"Komm.-MD" (vermutlich Kommunikations-MD) genannt.
Ist im HMI nur bei gesetztem Service Passwort sichtbar

0x82
Parameter der SINAMICS Motor Module bzw. Antriebe, im HMI "Antriebs-MD" genannt,
eigentlich die gleichen Daten wie im Block M, aber die Unit / Antriebs - Zuordnung ist anders
Im BlockM entspricht die Unit dem Achs-Index, hat z.B. die Z-Achse den Index 3, so ist ihr Antrieb im BlockM bei Unit 3 zu finden.
Beim 0x82er ist die Zurodnung anders, hab kein System gefunden...
Column entspricht der Nummer des MD's, z.B. 35 bei p0035
Row ist bei einzeiligen Parametern = 1, bei mehrzeiligen Parametern der Index in eckigen Klammern + 1, z.B. 1 bei p0039[0] oder 5 bei p0039[4]

0x83
Parameter des SINAMICS Active Line Module (ALM), im HMI "Einspeisungs-MD" genannt,
Unit entspricht der Nummer des ALM (es können mehrere in einem Antriebsverband vorhanden sein) Unit 1 == ALM 1
Column entspricht der Nummer des MD's, z.B. 35 bei p0035
Row ist bei einzeiligen Parametern = 1, bei mehrzeiligen Parametern der Index in eckigen Klammern + 1, z.B. 1 bei p0039[0] oder 5 bei p0039[4]


0x84 (bisher nicht getestet)
laut einer Doku die LowLevelMan ausgegraben hat,
befinden sich hier Parameter des "TB" (vermutlich "Terminal Block", ein I/O-Erweiterungsboard zur NCU)

0x85 (bisher nicht getestet)hier befinden sich vermutlich dann Parameter der "TM" ("Terminal Module(s)", die analogen/digitalen I/O-Module für den Terminal Block)

In unseren Maschinen sind soweit ich das überprüfen konnte keine solchen Erweiterungsmodule verbaut, daher konnte ich die Bereiche nicht testen.
Werde aber nochmal nachsehen ob mann evtl. mit einer höheren Sicherheitsstufe die leeren MD-Bereiche im HMI findet