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

passen deine logs zu dem outputs - in spinner1.pcapng ist das 1. lesen auf den Y Block - in der Spinner1.txt aber nicht?

kannst du auch die main.cpp wieder anhaengen

und aenderst noch vorher die Zeile mit

Code: 
  //read from nc
  int result = AGL_NCK_ReadMixEx(p_connection, &data_rw[0], data_rw.size(), TIMEOUT, USERVAL);
  printf("Result: %s\n", agl_result_str(result));
  if(result != AGL40_SUCCESS)
  {
    if(result != AGL40_UNKNOWN_PLC_ERROR) // den lassen wir trotzdem durch
    {
      assert(false);
    }
  }
  if(result == AGL40_SUCCESS)
  {
     for(...)
     {
        ...
     }
  }
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Das mit dem Block Y hab ich eingebaut, da wird die NCK-Software-Version gelesen...
im Output ganz oben, unter der AGLink Version.
Hab deinen obigen code eingebaut und nochmal 2 tests gemacht, bei der Spinner mit der neueren SW bricht er immer ab nach dem Fehler.
Ich glaub ich hab nicht richtig verstanden wo der code hin soll. Hab die main.cpp mit dran.

Was anderes: Ich glaub ich hab rausbekommen was die Blöcke 0x80, 0x82 und 0x83 machen..
Jew. Mit AreaFeedDrive
0x80 --> "Control-Unit-MD", unit 1 == Control-Unit Nr. 1
0x82 --> "Antriebs-MD", eigentlich die gleichen Daten wie im Block M, aber die Unit zu Achsen Zuordnung ist anders (durcheinander, hab noch kein System gefunden)
0x83 --> "Einspeisungs-MD" , unit 1 == Einspeisung Nr. 1 --> Das sind die Daten, die mir noch gefehlt haben :)

Anhang anzeigen Test_Ergebnisse4.zip
 
die neue read_version und print_version hab ich mal entfernt - ich mag keine Code Duplikationen - weil in beiden muesste ich das Fehlerverhalten korrigieren
lieber die read_print... Funktion in 2 Funktionen splitten

jetzt muesste es weiterlaufen
 

Anhänge

  • main.zip
    5,2 KB · Aufrufe: 8
main UPDATE
*nck_read_print_vars in read und print getrennt - hoffe es laeuft so noch
*deine total komische (wirre schnittstelle, code duplikations usw....) read_print_nck_version mal durch was sinnvolles ersetzt
*dein std::string varnames[100]-Array entfernt - das hast du so nie gebraucht

btw: printf will std::string.c_str(), std::cout kann c-strings und std::strings

Was anderes: Ich glaub ich hab rausbekommen was die Blöcke 0x80, 0x82 und 0x83 machen..
Jew. Mit AreaFeedDrive
0x80 --> "Control-Unit-MD", unit 1 == Control-Unit Nr. 1
0x82 --> "Antriebs-MD", eigentlich die gleichen Daten wie im Block M, aber die Unit zu Achsen Zuordnung ist anders (durcheinander, hab noch kein System gefunden)
0x83 --> "Einspeisungs-MD" , unit 1 == Einspeisung Nr. 1 --> Das sind die Daten, die mir noch gefehlt haben :smile:
Zum Vergrößern anklicken....

dann koennen die Deltalogics die auch mal richtiger bennenen (hoffe du findest noch raus wie die Achsen bei 0x82 angegeben werden) - kannst du fuer diese neue Variablen auch noch Tests einbauen (in die neue main) und ein Log erstellen
 

Anhänge

  • main.zip
    5,6 KB · Aufrufe: 9
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich komme voraussichtlich leider erst wieder am Freitag an die Maschinen, dann teste ich es und berichte....
Vlt. bekomme ich ja noch raus für was die anderen 0x8X Blöcke sind.

Das mit dem Code.. Naja, ich hab nie programmieren gelernt, ich bin Maschinenbauer. Ich pfusch mir das nur so aus Beispielen (Internet) zusammen.
Ist auch keine "professionelle" Software die ich hier baue, sondern "nur" Forschung an der Uni.
Ich versuch's besser zu machen.... Danke für die Korrektur!
 
Vlt. bekomme ich ja noch raus für was die anderen 0x8X Blöcke sind.
Zum Vergrößern anklicken....

Das wäre echt super

Das mit dem Code.. Naja, ich hab nie programmieren gelernt, ich bin Maschinenbauer. Ich pfusch mir das nur so aus Beispielen (Internet) zusammen.
Ist auch keine "professionelle" Software die ich hier baue, sondern "nur" Forschung an der Uni.
Ich versuch's besser zu machen.... Danke für die Korrektur!
Zum Vergrößern anklicken....

ordentlich bist du schon mal - das ist schon 1/3 der Miete :)
 
So, ich wollte kurz bescheid geben, dass ich's gestern nicht mehr geschafft habe weiter zu testen. Ich werde nächste Woche weiter machen.
Bin noch auf ein paar weitere Dinge gestoßen, die mir seltsam erscheinen, melde mich dann nochmal wenn ich genaueres rausgefunden habe.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Anderes Thema: Mit meinem Programm möchte ich Daten von mehreren Maschinen, jew. mit einer PLC und einer NCK abfragen (Typische Werkzeugmaschinen / Bearbeitungszentren).

Dabei soll es einerseits möglich sein Daten EINER Maschine über kurze Zeiträume sehr granular aufzuzeichnen, d.h. alle X Millisekunden wobei X möglichst klein (~ 10-100ms) sein sollte.
--> Was ist denn hier als Untergrenze realistisch, wenn ich ca. 2x 19 PLC Variablen (d.h. 2 PLC-Abfragen) und 10x 19 NCK Variablen (d.h. 10 NCK-Abfragen) lesen will? Es handelt sich um ein Gigabit Netzwerk, in dem nur mein PC und max. 5 Sinumerik's hängen... Wo ist der Flaschenhals zu erwarten, irgendwelche Erfahrungen?

Andererseits sollte es auch möglich sein Daten mehrerer Maschinen über längere Zeiträume (Stunden / Tage) z.B. einmal pro Sekunde oder Minute aufzuzeichnen.
--> Wenn in dieser Zeit ein Problem im Netzwerk oder bei einer der Steuerungen auftritt, soll das die Aufzeichnung bei den anderen möglichst nicht beeinträchtigen.
Wenn z.B. eine von 5 Maschinen während der Aufzeichnung ausgeschaltet wird und ihre Steuerung nicht mehr erreichbar ist, soll das Timeout beim Verbindungsaufbau nicht dazu führen, dass die Abfrage der anderen verzögert wird.

Wie empfiehlt es sich denn hier grundsätzlich anzusetzen?
Multithreading? Dachte z.B. daran für jede Maschine einen eigenen Thread zu starten, evtl. jew. noch einen Thread für PLC und NCK... haltet ihr das für sinnvoll?
Momentan nutze ich die "normalen" ReadMixEx anfragen, habe aber in der Doku auch gelesen, dass es eine Art zyklischer Leseaufträge gibt. Verstehe aber nicht wie das funktionieren soll, hat da evtl. jemand ein Beispiel?
Und gibt es da irgendwelche Nachteile / Probleme? Wird dadurch die Steuerung belastet bzw. evtl. die eigentliche Funktion der Maschine beeinträchtigt?

Wäre für ein paar "Praxistipps" sehr dankbar!
 
noch ein Update fuer deine Tests (habs mal mit einer antriebslosen Test-NC durchgetestet)

waere schön wenn du:
-die 0x8x Bloecke rausfindest (die brauch glaube ich auch bald)
-weiterhin die anderen 2 NCs (mit den älteren Firmwarständen - zum Fehlervergleich) auch testen könntest - also alle die du bisher in den Fingern hattest

Wo ist der Flaschenhals zu erwarten, irgendwelche Erfahrungen?
Zum Vergrößern anklicken....

immer die PLC oder NC - dein Netzwerk wird dadurch kaum belastet, deine Lesegeschwindigkeit hängt davon ab wie die Zykluszeit deiner PLC ist oder wie stark z.B. deine NC belastet ist

Wie empfiehlt es sich denn hier grundsätzlich anzusetzen?
Multithreading? Dachte z.B. daran für jede Maschine einen eigenen Thread zu starten, evtl. jew. noch einen Thread für PLC und NCK... haltet ihr das für sinnvoll?
Momentan nutze ich die "normalen" ReadMixEx anfragen, habe aber in der Doku auch gelesen, dass es eine Art zyklischer Leseaufträge gibt. Verstehe aber nicht wie das funktionieren soll, hat da evtl. jemand ein Beispiel?
Und gibt es da irgendwelche Nachteile / Probleme? Wird dadurch die Steuerung belastet bzw. evtl. die eigentliche Funktion der Maschine beeinträchtigt?
Zum Vergrößern anklicken....

Thread pro NC/PLC oder mittels AGLink Jobs (dann macht AGLink das im Hintergrund) - ich glaube mit Timeout < 0 oder sowas - ist mit AGLink alles unproblematisch

die zyklischen Leseaufträge sind begrenzt (kommt drauf an was auf der NC läuft) verfuegbar - könnte aber bei dir reichen, damit musst du nicht pollen sondern die NC meldet sich bei Veraenderung
- es ist aber nicht so das du damit dann so viel schneller bist als pollend
 

Anhänge

  • main.zip
    5,9 KB · Aufrufe: 30
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, heute war ich wieder am Institut und habe weiter getestet...
Habe vergessen deinen neuen Test laufen zu lassen, werde das Morgen nachholen.
Zu den anderen 0x8Y Blöcken bin ich leider auch noch nicht schlauer geworden.

Ich habe mir das Timing bei der NCK mal etwas genauer angesehen.
Wenn man versucht von der PLC in einem Auftrag mehr als 19 Variablen zu lesen, wird der Auftrag vom AGLink automatisch in mehrere Job's mit max. 19 Variablen je Job zerlegt.
Beim lesen von der NCK ist dies bislang nicht der Fall, was dazu führt dass bei Aufträgen mit mehr als 19 Variablen ein Fehler auftritt.
Hab das dem Datalogic Support geschrieben, die meinten das Splitting wäre in der Tat bei der NCK noch nicht implementiert.
Außerdem hab ich ja das Problem, dass ich für jeden der NCK_AreaFeedDrive-Bereiche bzw. für jede Unit einen eigenen Aufruf starten muss, da sonst auch ein Fehler auftritt.
Wenn ich also Daten für 8-9 Antriebe, die Einspeisung und noch "normale" NCK Daten abfragen will, komme ich auf mind. 11-12 Abfragen, je nach Anzahl der Parameter pro Bereich.

Laut Wireshark log, dauert es ca. 7-10 ms, bis ich von der NCK eine Antwort auf eine Anfrage bekomme, in meinem Code komme ich so (laut MS Visual Studio Debugger) auf ca. 20-35ms. für eine Abfrage.
Mit einem Programm, das die Aufträge sequentiell absendet und immer erst auf die Antwort wartet bevor die nächste Anfrage gesendet wird, dauert ein "zyklus" mit allen meinen NCK Bereichen so zwischen 250-350ms. Dann noch die PLC Abfrage dazu und die Daten "verarbeiten", da wird's mit 500ms schon knapp.
Das ist leider recht langsam... hab also versucht das ganze zu beschleunigen. Dazu habe ich zunächst für jede Maschine einen Thread angelegt, der wiederum jew. für PLC und NCK einen Thread startet.
Hat die Situation etwas verbessert, aber leider nicht so wie ich's gerne hätte. Ideal wären so ca. 100ms für alle NCK Bereiche + PLC.
Dann habe ich versucht für jede NCK-Unit einen eigenen Thread zu erstellen. Resultat: Mein PC sendet innerhalb von ca. 30ms alle Jobs raus, aber von der NCU kommen nur noch teilweise antworten, ich fürchte das überfordert sie.
Hoffentlich finde ich da noch ein gutes "Mittelmaß"...
Werde morgen auch nochmal testen, was so als Untergrenze erreichbar ist, wenn ich nur einen Bereich lese. Die Tests waren nebenbei bemerkt überwiegend im Leerlauf, hoffe dass sich das im aktiven Betrieb nicht noch verschlechtert.

Habe von Deltalogic auch noch einmal ein Update bekommen, das die NCK Fehlercodes richtig ausgeben können soll, auch das hab ich noch nicht getestet.
War eine stressige Woche..
 
Ja, heute war ich wieder am Institut und habe weiter getestet...
Zum Vergrößern anklicken....
arbeitest du da oder Student?

Wenn man versucht von der PLC in einem Auftrag mehr als 19 Variablen zu lesen, wird der Auftrag vom AGLink automatisch in mehrere Job's mit max. 19 Variablen je Job zerlegt.
Beim lesen von der NCK ist dies bislang nicht der Fall, was dazu führt dass bei Aufträgen mit mehr als 19 Variablen ein Fehler auftritt.
Zum Vergrößern anklicken....
kannst du den mehr-als-19-Variablen-Test (mit dem Fehler) auch in die main.cpp bauen - dann haben die Deltalogics gleich ein Beispiel - und es koennte zusätzlich noch ein Antriebs-Variablen bezogenes Problem sein

Habe vergessen deinen neuen Test laufen zu lassen, werde das Morgen nachholen.
Zum Vergrößern anklicken....
bitte auch mit Logausgabe und Wireshark-Log
Außerdem hab ich ja das Problem, dass ich für jeden der NCK_AreaFeedDrive-Bereiche bzw. für jede Unit einen eigenen Aufruf starten muss, da sonst auch ein Fehler auftritt.
Zum Vergrößern anklicken....
Das sieht fuer mich ganz klar nach einer Firmware-Einschränkung aus - warum auch immer die NCK das nicht erlaubt

Laut Wireshark log, dauert es ca. 7-10 ms, bis ich von der NCK eine Antwort auf eine Anfrage bekomme, in meinem Code komme ich so (laut MS Visual Studio Debugger) auf ca. 20-35ms. für eine Abfrage.
Zum Vergrößern anklicken....
AGLink und dein Code sollte die Dauer nicht verdoppeln - teste mal im Release-Mode, und wie machst du dein Benchmarking (clock oder sowas ist unbrauchbar da Genauigkeit: +-10-20ms)

Werde morgen auch nochmal testen, was so als Untergrenze erreichbar ist, wenn ich nur einen Bereich lese. Die Tests waren nebenbei bemerkt überwiegend im Leerlauf, hoffe dass sich das im aktiven Betrieb nicht noch verschlechtert.
Zum Vergrößern anklicken....
bei so wenigen Variablen könnte es nicht so relevant sein

Habe von Deltalogic auch noch einmal ein Update bekommen, das die NCK Fehlercodes richtig ausgeben können soll, auch das hab ich noch nicht getestet.
Zum Vergrößern anklicken....
dann sieht man vielleicht auch was bei den Drives das Problem ist
 
Ich schreibe meine Master-Arbeit dort, also noch Student.
Den Test baue ich noch ein.
Und meinen Code versuche ich noch etwas zu optimieren, mal schauen wie weit ich komme...
 
zu Test 11:
Ich sehe im Wireshark kein falsches Verhalten von AGLink (da wird nicht - und muss auch nicht gesplittet werden)
hab dann mit dem Support telefoniert und das NCK-Splitting sollte doch schon drinn sein (ich nutze das doch) (nur bei speziellen Drives fehlt das - möglicherweise ein Missverständniss)
vermute das dein Test 11 eine weiterer Einschränkung bei Abfrage von Drive-Parametern aufzeigt (die sich in allen Belangen scheinbar anders verhalten als alles was ich bisher gesehen habe)

bau mal den Test 12 noch bei dir ein - da werden 50x RPA[0] gelesen - erzeugt mind. 3-4 Jobs in Wireshark

Code: 
  // Test 12
  printf("\n\nTest 12 50x RPA[0]   \n");
  printf("----------------------------------------------------------------\n");
  {
    nck_vars_t vars;
    for(size_t i = 0; i < 50; ++i)
    {
      vars.push_back(rpa0);
    }
    read_print_nck_vars(connection, vars);
  }
 
Zuletzt bearbeitet:
Hier die Ergebnisse.
Du hast recht - "Normale" NCK Abfragen mit mehr als 18 Parametern werden auch gesplittet.
Jedoch keine Zugriffe auf die eNCK_AreaFeedDrive / BlockM, Block0x82, Block0x83...
Woher kommt das denn?!! Ich hatte vermutet, dass das AGLink einfach stur das RW-NCK-Array in 18-Variablen große Stücke teilt, egal welcher Bereich oder Block abgefragt wird.. Aber scheinbar ist dem nicht so? Findet da noch irgendwie eine Optimierung statt?

Unsere Anlagen haben immer noch den Software-Stand, mit dem sie ausgeliefert wurden also von 2011-2012.
Wie aufwändig / teuer ist es denn so eine Maschine "upzudaten"?
Würde mich schonmal interessieren ob in der aktuellen Version auch noch solche Bugs hat, bzw. wie die sich verhält...

Anhang anzeigen Test_Ergebnisse6.zip
 

Similar threads

P
TIA Simodrive 611 NCU aus alter CNC + CPU 314C-2DP + TIA V17?
Antworten
16
Aufrufe
619
DeltaMikeAir
DeltaMikeAir
S
Sinumerik 840D - HMI Advanced 6.4.18 Fragen Inbetriebnahme
Antworten
3
Aufrufe
2K
STEP7_NEWBEE
S
S
Sinumerik 840D Power Line - Frage zu Lizenzen usw..
Antworten
2
Aufrufe
3K
STEP7_NEWBEE
S
1970ante@
TIA E/A direkt an der 840d sl aus der SPS 317 schreiben bzw lesen.
Antworten
8
Aufrufe
1K
1970ante@
1970ante@
W
Sonstiges Sinumerik 840D SL Signal an PLC bei Punkt erreicht ohne Vorlaufstopp
Antworten
4
Aufrufe
4K
Wincctia
W
Zurück
Oben