Wartestatus des INPUT-Befehls deaktivieren?

  • Hallo,
    ist es möglich nur eine gewisse Zeit auf einen Datenempfang zu warten?


    Mein Problem ist, dass ich von der SPS nur Daten sende, wenn diese sich ändern.
    Genau das gleich möchte ich auf der Robi-Seite. Es wird zur SPS gesendet, wenn sich bestimmte Daten ändern; ansonsten wird empfangen.
    (d.h. es wird zyklisch die Leitung abgehört, ob Daten anliegen, wenn nicht geht's im Prog weiter)
    Die Bearbeitung (Roboterbewegung, usw.) soll in einem zweiten Task laufen.
    Wie kann ich das realisieren bzw. ist dies überhaupt möglich?

  • ANZEIGE
  • Hallo,


    ich glaube den Input-Befehl kann man nicht mehr unterbrechen, wenn er einmal ausgeführt wird. Da müsste man schon den Task stoppen.


    Um das Problem zu umgehen, fallen mir mehrere Möglichkeiten ein:


    Man könnte ON COM benutzen und in einer Interruptbehandlungroutine nur dann lesen, wenn wirklich Daten da sind. Allerdings habe ich mit Interrupts im Zusammenhang mit Ethernet keine guten Erfahrungen gemacht. Fehler in solchen Programmen lassen sich nur schwer finden.


    Wie unten im Thread "Ansteuerung über LabView" könnte man mit mehreren Tasks arbeiten. Das Hauptprogramm ist für die Roboterbewegung zuständig und startet mit XRUN zwei weitere Tasks, einen für das Lesen und einen für das Schreiben. Ob die beiden dann die gleiche TCP-Verbindung verwenden können oder sollten, kann ich nicht sagen. Besser ist es evtl. zwei Verbindungen aufzumachen und jede nur in eine Richtung zu nutzen.


    Variante drei ist eher was für PCs. Man könnte die Kommunikationsrichtung umdrehen, auf das Input verzichten, sich über das Kommunikationsprotokoll quasi als Debugger anmelden und Variableninhalte direkt modifizieren. Ist aber definitiv was für Fortgeschrittene.


    Meine Empfehlung Nummer vier kann nur lauten Profibus zu verwenden. Da erledigen beide Seiten den Variablenabgleich automatisch, ohne das man in den Anwendungsprogrammen irgendwas tun muss.


    Grüße


    Urmel

  • Hallo,
    Voraussetzung ist leider eine Ethernet Verbindung.


    Das mit der Interruptbehandlungsroutine hört sich gut an.
    Was für schlechte Erfahrungen hast du da gemacht? Datenverlust? Zeitproblem?


    Was allerdings ein Problem bei dem Befehl ON_COM ist, dass bei einer Interruptauslösung die Roboterbewegung gestoppt wird.
    Kann man das umgehen? z.B. über zwei Tasks (in einem Interrupt mit senden und empfangen, und im zweiten mit Robi-Bewegungen)
    ... und der Befehl COM_STOP bringt mich da ja auch nicht weiter, da ich somit die Empfangsdaten nicht einlese.


    Hintergrung: Mein Robi soll nur dann stehen bleiben, wenn ein bestimmter Wert in der Empfangsdatenstruktur sich ändert.

  • Nur nochmal zum Verständnis, mit einer zweiten Ethernetverbindung meine ich nur einen zweiten TCP-Port. Also z.B. COM2 zum Senden und COM3 zum Empfangen. Kein zweites Kabel, das unterstützt der Roboter sowieso nicht.


    Bei Interruptprogrammen kann man, wie gesagt, Fehler nur sehr schwierig finden. Es lässt sich nicht immer nachvollziehen, was ein Programm gerade macht. Ich bin auch nicht ganz überzeugt, ob Melfa Basic in diesem Punkt völlig bugfrei ist.

    Einmal editiert, zuletzt von Urmel ()

  • Das ist schon klar. Es soll aber auch nur ein TCP-Port verwendet werden.


    Was ist, wenn ich drei Tasks verwende:
    1. Roboterbewegung
    2. Datenempfang
    3. Daten senden


    Wenn sich jetzt der Roboter bewegt und Task 2 auf INPUT steht, könnte ich ja wie du vorhin erwähnt hast, den Task 2 stoppen, wenn keine Daten anliegen und weiter zum senden (Task 3) gehen.
    Somit habe ich den Input-Befehl abgebrochen.
    Könnte es dabei zu einem Programmabbruch durch eine Fehlermeldung oder zu Performance Problemen kommen?
    Ist diese Möglichkeit ratsam?


  • Das ist schon klar. Es soll aber auch nur ein TCP-Port verwendet werden.


    Du machst es einem aber wirklich nicht einfach. :kopfkratz:


    Zitat von Zizou


    Was ist, wenn ich drei Tasks verwende:
    1. Roboterbewegung
    2. Datenempfang
    3. Daten senden


    Wie schon gesagt, bin ich mir nicht sicher, ob es dabei erlaubt ist in beiden Tasks z.B. ein Open auf den selben Comport zu machen, vermutlich nein.


    Zitat von Zizou


    Somit habe ich den Input-Befehl abgebrochen.


    Ja, aber vermutlich nicht die TCP-Verbindung so geschlossen, dass man sie in Task 3 verwenden kann.


    Zitat von Zizou


    Könnte es dabei zu einem Programmabbruch durch eine Fehlermeldung oder zu Performance Problemen kommen?


    Ersteres ist wahrscheinlich, letzteres ziemlich sicher.


    Zitat von Zizou


    Ist diese Möglichkeit ratsam?


    Ich würde sagen nein.


    Versuch entweder Task 2 und Task 3 zusammenzupacken und verwende einen Interrupt zum Empfangen,
    oder sende einfach immer Daten, auch wenn sich nichts geändert hat. Roboterseitig sehe ich da keinen so großen Performanceunterschied.

    Einmal editiert, zuletzt von Urmel ()

  • Einen Interrupt kann ich nicht verwenden, da hierbei die Roboterbewegung gestoppt wird.



    Ja, aber vermutlich nicht die TCP-Verbindung so geschlossen, das man sie in Task 3 verwenden kann.


    D.h. solange der Input-Befehl aktiv ist, kann ich keinen Print-Befehl ausführen, oder?


  • Auch wenn der Interrupt in Task 2 stattfindet ?


    "Bei anliegendem Interrupt wird die Roboterbewegung gestoppt."
    So steht es im Handbuch und in der Hilfe.


    Diese Aussage hat ja nichts mit Multitasking zu tun und ist deshalb vermutlich egal in welchem task es steht.


    Aber jetzt mal Allgemein:
    Ist so ein Befehl wie der INPUT auch bei anderen Herstellern üblich, oder wird da so etwas besser gelöst?


  • "Bei anliegendem Interrupt wird die Roboterbewegung gestoppt."
    So steht es im Handbuch und in der Hilfe.


    Diese Aussage hat ja nichts mit Multitasking zu tun und ist deshalb vermutlich egal in welchem task es steht.


    Schade aber auch ...



    Aber jetzt mal Allgemein:
    Ist so ein Befehl wie der INPUT auch bei anderen Herstellern üblich, oder wird da so etwas besser gelöst?


    Nicht jeder Hersteller hat überhaupt sowas.


    Kuka hat z.B. nur CRead/CWrite für die serielle Schnittstelle.
    Wenn Du über Ethernet gehen willst musst du entweder KRL-XML kaufen, um XML-Daten zu übertragen, oder einen OPC-Server installieren.


    Motoman und Fanuc haben Protokolle, mit denen man Variablenwerte ändern kann. Sowas hast du aber bei Mitsubishi auch, es blockiert auch nicht, aber es dürfte aber SPS-seitig eine Herausforderung sein, da es textbasiert ist.


    http://www.roboterforum.de/rob…oboter_rv3sb-t3878.0.html

  • Hallo Urmel,
    du hattest mal wieder recht.
    Bei Multitasking mit dem Kommunikations-Interrupt in Task 2 wird die Roboterbewegung (Task 1) nicht gestoppt.
    (Das steht auch in der Anleitung, aber an einer ganz anderen Stelle und wird nur kurz in einem Satz erwähnt)


    Ich hab es ausprobiert und es funktioniert tatsächlich.


    Somit bedanke ich mich für deine super Idee, ohne die ich so etwas nie ausprobiert hätte.


    Gruß Zizou

  • Dadurch ist jetzt eine weiteres Problem entstanden.


    Kann ich denn einen Fahrbefehl abbrechen?
    z.B.:
    Prog in Task 1:
    MOV P1 'Roboterfahrt zu Position 1


    Wie kann ich jetzt die laufende Bewegung stoppen?
    SERVO OFF möchte ich nur ungern verwenden.


    Anschließend soll Programm 1 auf eine andere Zeile springen. Ist das aus dem zweiten Programm möglich, oder kann ich das Programm nur zurücksetzen (XRST)?

  • Tja, da sieht man wieder die Unterschiede in den Handbüchern:


    Im deutschen Handbuch steht bei ON COM


    Zitat


    Bei anliegendem Interrupt wird die Roboterbewegung gestoppt.


    und im englischen


    Zitat


    If the communicative interrupt occurs while the robot is moving, robots operating within the same slot will stop.


    Wieder was dazugelernt. ;)


    Grüße


    Urmel


  • Kann ich denn einen Fahrbefehl abbrechen?


    Probier mal in Task 2 etwas wie

    Code
    100 M_01 = 1


    und in Task 1 dann

    Code
    100 MOV P1 WTHIF M_01 = 1,SKIP
    110 M_01 = 0


    Die Variablen mit dem Unterstrich sind vordefiniert und dienen dem Datenaustausch zwischen den Tasks.


    Allerdings habe ich SKIP bisher nur mit IO-Bits verwendet.



    Anschließend soll Programm 1 auf eine andere Zeile springen. Ist das aus dem zweiten Programm möglich, oder kann ich das Programm nur zurücksetzen (XRST)?


    Also richtig gutes Programmdesign ist das ja nicht.


    Eventuell geht

    Code
    MOV P1 WTHIF M_01 = 1,HLT


    und dann ein Neustart mit XRST und XRUN.


  • Also richtig gutes Programmdesign ist das ja nicht.


    Aber für mein erstes Roboterprog, nicht schlecht 8)


    Möchte ja nur verhindern, dass weitere Fahrbefehle ausgeführt werden. Aber das kann ich jetzt ja alles mit ...

    Code
    100 MOV P1 WTHIF M_01 = 1,SKIP


    ... machen.



    Die Variablen mit dem Unterstrich sind vordefiniert und dienen dem Datenaustausch zwischen den Tasks.


    Diese Variablen sind doch globale Variablen.
    Ich kann doch auch meine selbst definierten globalen Variablen nehmen, oder?

    Code
    DEF INTE i_Mode


    ich muß nur aufpassen, dass diese im anderen Task vor der DEF noch nicht verwendet werden.

  • Zur Datenübertragung zwischen zwei Tasks braucht man normalerweise schon die globalen Variablen.


    Die selbst definierten sollten eigentlich nur in dem Task sichtbar sein, in dem sie angelegt wurden. :denk:


    [Edit]
    Du kannst natürlich selber globale Variablen anlegen, aber die müssen in einem speziellen Programm angelegt werden, dass nur diesem Zweck dient.

    Einmal editiert, zuletzt von Urmel ()

  • Hallo,
    ich habe folgende Zeile bei der ein Fehler auftritt.

    Code
    1360 	MVS,-35 WTHIF M_99 > 3,SKIP             '35mm von der aktuellen Position nach oben fahren


    Die folgende Zeile funktioniert, aber ich benötige den oberen Code-Teil.

    Code
    1360 	MVS P1,-35 WTHIF M_99 > 3,SKIP             '35mm über die Position 1 fahren


    Was mach ich im ersten Code-Ausschnitt falsch? Hab es auch schon mit Klammern probiert.

  • Hast du da ein Space zwischen MVS und Komma ?


    Wenn ja, solltest du die Frage mal dem Mitsubishi Support stellen. Sieht nach einem Bug aus.


    Schreib dann halt ersatzweise


    Code
    1360 MVS P_CURR,-35 WTHIF M_99 > 3,SKIP


    oder, falls der Roboter da in Bewegung ist


    Code
    1340 DLY 0.01
    1350 PTMP = P_CURR
    1360 MVS PTMP,-35 WTHIF M_99 > 3,SKIP


    Schönes Wochenende


    Urmel

  • Hallo Urmel,
    wie ist das denn bei anderen Roboterherstellern mit der Ethernetkommunikation?
    Ist es üblich, dass ASCII-Zeichen + "CR" (bzw. "CR"+ "LF") zur Übertragung verwendet werden?
    Oder gibt es auch Hersteller die den Ethernet-Datenframe direkt mit Binärdaten füllen?


    Soweit ich herausgefunden habe, werden bei Mitsubishi und Denso die Daten im ASCII-Format übertragen.

  • Also "Ethernet-Datenframe direkt mit Binärdaten füllen" wäre ja die Verwendung von Raw-Sockets (ohne Protokoll), das ist sogar im PC-Bereich sehr selten.


    Wenn du meinst Binärdaten über TCP oder UDP versenden, dann gilt die Einschränkung bei Mitsubishi nur für Melfa Basic. Bei den neuen modularen Steuerungen (SQ-Serie) kann die Roboter-CPU mit SPS- oder PC-CPUs zusammengesteckt werden. Sowohl die SPSen der Q-Serie, als auch die CPUs mit Windows XP embedded oder VxWorks können auch kompliziertere Datenübertragungen.
    http://www.mitsubishi-automati…modularplc_iq_content.htm


    Ansonsten kann ich die Frage nur für zwei andere Hersteller beantworten:


    Kuka: Nur XML-Datenübertragung oder OPC, keine Strings oder Binärdaten, beides nur gegen Aufpreis


    Stäubli: Man kann Strings mit Zeilenendezeichen oder einzelne Bytes lesen und schreiben.


    Grüße


    Urmel

    Einmal editiert, zuletzt von Urmel ()

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden