Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 12 von 21 ErsteErste ... 21011121314 ... LetzteLetzte
Ergebnis 111 bis 120 von 207

Thema: 840D sl NCU Variablen und Antriebsparameter lesen/schreiben

  1. #111
    Registriert seit
    17.11.2015
    Beiträge
    50
    Danke
    3
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.

  2. #112
    Registriert seit
    17.11.2015
    Beiträge
    50
    Danke
    3
    Erhielt 1 Danke für 1 Beitrag

    Standard

    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!

  3. #113
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    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?
    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?
    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
    Angehängte Dateien Angehängte Dateien
    Geändert von LowLevelMahn (18.01.2016 um 06:21 Uhr)

  4. #114
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    schon weiteres herausgefunden? bist ein bisschen ruhig geworden

  5. #115
    Registriert seit
    17.11.2015
    Beiträge
    50
    Danke
    3
    Erhielt 1 Danke für 1 Beitrag

    Standard

    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..

  6. #116
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    Ja, heute war ich wieder am Institut und habe weiter getestet...
    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.
    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.
    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.
    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.
    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.
    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.
    dann sieht man vielleicht auch was bei den Drives das Problem ist

  7. #117
    Registriert seit
    17.11.2015
    Beiträge
    50
    Danke
    3
    Erhielt 1 Danke für 1 Beitrag

    Standard

    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...

  8. #118
    Registriert seit
    17.11.2015
    Beiträge
    50
    Danke
    3
    Erhielt 1 Danke für 1 Beitrag

    Standard

    So, hier die Ergebnisse der Tests mit der neuesten AGLink Version.
    Hab noch die Ergebnisse des Multithreading-Tests dazu, und ein Beispiel (Test5) des Job-Splittings bei der PLC (Das war ein Auftrag mit 21 Variablen, der vom AGLink automatisch aufgeteilt wurde).

    Test_Ergebnisse5.zip

  9. #119
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    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);
      }
    Geändert von LowLevelMahn (22.01.2016 um 13:18 Uhr)

  10. #120
    Registriert seit
    17.11.2015
    Beiträge
    50
    Danke
    3
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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...

    Test_Ergebnisse6.zip

Ähnliche Themen

  1. OPC Variablen via C++ lesen und schreiben
    Von AkrapovicSPS im Forum Hochsprachen - OPC
    Antworten: 4
    Letzter Beitrag: 12.09.2013, 08:38
  2. Variablen schreiben und lesen aus TwinCat3-Projekt
    Von patzer103040 im Forum CODESYS und IEC61131
    Antworten: 5
    Letzter Beitrag: 08.04.2013, 12:11
  3. C#-Variablen in TwinCAT lesen und Schreiben
    Von kcirtap im Forum CODESYS und IEC61131
    Antworten: 2
    Letzter Beitrag: 29.11.2010, 10:18
  4. GUDs lesen und schreiben 840D
    Von PG710 im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 20.12.2008, 12:12
  5. Antworten: 0
    Letzter Beitrag: 08.11.2008, 08:36

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •