TIA Kommunikation S7 1212 (TIA V15.1) mit Roboter (Universal Robots UR10e) via OUC Kommunikation

[Mogli]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen zusammen,

wir haben hier einen Roboter von Universal Robots, der mit einer S7 1212 kommunizieren soll.
Die Kommunikation ist eine OUC -Verbindung. Ich kann von der SPS aus Signale (via String) an den Roboter senden.
Dort kommen die Signale auch korrekt an und der Roboter macht das, was er machen soll.

Jedoch klappt das mit dem Auslesen der Antwort vom Roboter nicht so ganz.
Dazu verwende ich in der SPS einen TRCV Baustein.
Wenn ich jetzt einen String an den Roboter sende, sieht die Antwort, die ich bekomme wie folgt aus:


Weiß jemand wie man diese Antwort "lesbar" machen kann?

Hat schonmal jemand von euch versucht eine Siemens SPS mit einem Universal Robot via Dashboard Server kommunizieren zu lassen?

Habe das ganze auch im Forum von Universal Robots angefragt. Nachfolgend der Link dazu:

Communication UR10e with Siemens PLC (TIA) via Dasboard Server

Good morning together, I´m struggling to get a running communication between my UR10e and my Siemens PLC (CPU 1212 TIA15.1) via Dashboard Server. To do the data exchange I use a OUC Communication which is established via TCON (and deactivated via TDISCON): For sending and receiving data i...

forum.universal-robots.com

Schon Mal vielen Dank für eure Hilfe/ Vorschläge.

Grüße aus Luxembourg!

 

[Oberchefe]

wenn du das als ASCII anzeigst, steht da ab dem ersten 6F:

ould not understand: 'sana.urp'""could not understand: '

 

[Windoze]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mach mal aus deiner String-Variable ein "Array of Char". Der Roboter wird sicherlich nicht die Kopfbytes eines S7-Strings schicken / empfangen wollen. Es gibt die Systemfunktionen "Strg_To_Chars" und "Chars_To_Strg" um zwischen Char-Arrays und S7-Strings zu wandeln.

 

[Mogli]

@Oberchefe danke für deine Antwort

@Windoze
ich habe mal aus dem String ein Array of CHAR (0..100) gemacht.
Der DB sieht dann wie folgt aus (mit Inhalt):






Leider finde ich nirgends im Internet (auch nicht durch den Support von Univeral Robots) wie die Antwort des Roboters aufgebaut ist.
Jedesmal wenn ich einen neuen Befehl an den Roboter schicke, beginnt die Antwort von dem Roboter auf einem anderen Byte.

In den obrigen Bildern, habe ich dem Roboter den Befehl "Play" gesendet: Der Befehl sieht auf Siemens Seite wie folgt aus:

Der Befehl wird auch so, in dieser Syntax vom Roboter erkannt und angenommen und der Roboter macht auch das was er soll.

Laut UR Handbuch, soll die Antwort des UR "Starting program" oder "Failed to execute: play" lauten.

Ich sehe, dass ich diese Antwort (dieses Mal) ab Byte 74 finden kann. auf Byte 73 sehe ich "$L" und auf Byte 90 steht das gleiche "$L". Also steht die erwartete Antwort vom Roboter zwischen den beiden "$L" im Array.
Alles was vor Byte 74 und nach Byte 90 kommt ist was undifiniertes/ altes?

Gibt es eine Möglichkeit, dass man in dem Array of CHAR (in meinem DB) heraussucht, wo das erste Mal "$L" steht und man dann die restlichen CHAR verbindet, bis man auf das zweite "$L" trifft?

Schonmal vielen lieben Dank für eure Hilfe.
Grüße aus Luxembourg!

 

[Dirk.Schneider]

Hallo Mogli

ich habe die UR schon öfters über eine Profinetverbindung mit einer S7-1214 verbunden, dies funktioniert tadellos
wäre das nicht auch bei Dir denkbar ?

mfg Dirk Schneider

 

[Mogli]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo @Dirk.Schneider

vielen Dank schon Mal für deine Antwort.

eine Profinetverbindung habe ich ebenfalls. Hierrüber mache ich diverse "Handshakes". Dies funktioniert ohne Probleme.
Jedoch kann ich darüber nicht alles abdecken, was ich für den Prozess benötige (Lösen der Bremse, Quittieren der Safety, Roboterprogramme wechseln etc).

Ebenso möchte ich eigentlich nicht, dass jemand das Roboter Panel anfassen soll (dieses wird sich innerhalb eines Schutzzaunes befinden).
Um dann den Roboter von meiner Siemens Steuerung aus komplett steuern zu können, brauche ich irgendwie Zugriff auf den Dashboard Server des UR. Denn hier kann ich dem Roboter diverse "vorgefertigte" Befehle zukommen lassen.

Das senden zum Roboter klappt auch ohne Probleme und der Roboter macht auch genau das, was ich ihm sage.
Jedoch wäre es (vorallem wenn man verschiedene Roboterprogramme laden möchte) wichtig, dass man eine "brauchbare" und lesbare Antwort von dem Roboter bekommt.

Oder wie realisierst du das?

Grüße aus Lux!

 

[PN/DP]

Klingt so als ob der Robi unterschiedlich lange Antworten sendet. Wie sieht denn Dein Nachrichtenempfang mit TRCV aus? Wenn da mit festen Nachrichtengrößen gearbeitet wird, dann verschieben sich die empfangenen Nachrichten im Empfangspuffer ... Du müsstes die Nachrichten aber Zeichenweise verarbeiten, um mitzukriegen von wo Anfang und Ende der Nachrichten sind.

Harald

 

[Mogli]

Hallp @PN/DP

Das kann sehr gut möglich sein. Leider findet man im Internet nichts zu dem Thema und der UR-Support reagiert bislang nicht auf Anfragen.

Ich habe bislang noch nie mit dem TRCV gearbeitet, und diesen wie in einem Beispielvideo gezeigt wurde beschaltet.







Muss man hier etwas anders einstellen? Bzw. überhaupt etwas einstellen?

Schon Mal vielen Dank!

Grüße aus Luxembourg!

 

[Windoze]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du beim TRCV die Datenlänge auf "0" stellst, werden die Daten immer sofort an das Programm übergeben.
Du musst dann aber mit dem Signal "NDR" die Daten sofort verarbeiten (Länge steht in "RCVD_LEN").
Im nächsten Zyklus könnten die Daten schon wieder mit dem nächsten Paket überschrieben werden.

Beim Senden solltest du nicht direkt den S7-String senden, sonst bekommt der Roboter immer vor dem Kommando die Kopfbytes des Strings.
Dann brauchst du auch kein Zeilenumbruch VOR dem Kommando damit der Roboter die ungültigen Zeichen wegschmeisst.

 

[Mogli]

Hallo @Windoze
Da ich den gleichen Trigger fürs senden und empfangen nutze (trigger wird betätigt durch drücken eines Buttons im HMI betätigt), dachte ich, dass die Empfangssignale so nutzen kann. Wenn ich mir den Empfangs-DB ansehe, bleiben die Daten da ganz normal stehen.

In einem älteren Forum-Eintrag (UR Forum) hatten Leute gezeigt, wie sie die Daten an den UR senden. Ich nutze die gleiche Syntax und es funktioniert einwandfrei (also das Senden).

 

[Windoze]

Das Problem ist, wenn der Roboter Daten sendet während du den Empfangsbaustein nicht freigibst werden diese (bis zu einer gewissen Menge) von der SPS zwischengepuffert.
Wenn du dann parallel mit dem Senden auch den Empfangsbaustein freigibst bekommst du alle Daten die noch im Puffer sind als Block.
Ich würde den Empfangsbaustein immer freigeben und mit dem Trigger nur die Auswertung freigeben.
Dann sollten die Telegramme des Roboters immer gleichmäßig im DB ankommen.

Zusätzlich hast du das "Problem" das du dem Roboter quasi zwei Befehle sendest. Einmal die String Kopfbytes und danach den eigentlichen Befehl.
Ich weis nicht, wie der UR reagiert wenn er einen ungültigen Befehl bekommt. Wenn er den einfach ignoriert funktioniert alles, ist aber trotzdem unschön.
Wenn er aber eine Antwort ala "Unbekannter Befehl" sendet, landet diese natürlich auch in deinem Empfangspuffer.

Hier mal ein Beispiel, wie du Einen String korrekt als Zeichen sendest:
#BefehlAlsString ist dein Bisheriger String
#Sendepuffer ein Char-Array

 

[Mogli]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du beim TRCV die Datenlänge auf "0" stellst, werden die Daten immer sofort an das Programm übergeben.
Du musst dann aber mit dem Signal "NDR" die Daten sofort verarbeiten (Länge steht in "RCVD_LEN").
Im nächsten Zyklus könnten die Daten schon wieder mit dem nächsten Paket überschrieben werden.

Beim Senden solltest du nicht direkt den S7-String senden, sonst bekommt der Roboter immer vor dem Kommando die Kopfbytes des Strings.
Dann brauchst du auch kein Zeilenumbruch VOR dem Kommando damit der Roboter die ungültigen Zeichen wegschmeisst.

Guten Morgen @Windoze,

Schon Mal vielen Dank für deine Hilfe und das Beispiel von Eintrag#11.

Das Ganze sieht nun so aus:






Jetzt eine Frage. Wie macht man das mit dem TRCV? Stehe auf dem "Schlauch". Ich bekomme immer das Signal "Busy".
Vielleicht habe ich deinen Vorschlag auch falsch verstanden...
Mein Problem ist, dass ich nicht weiß, wie lange die Antwort des Roboters ist.

Wenn du dann parallel mit dem Senden auch den Empfangsbaustein freigibst bekommst du alle Daten die noch im Puffer sind als Block.
Ich würde den Empfangsbaustein immer freigeben und mit dem Trigger nur die Auswertung freigeben.
Dann sollten die Telegramme des Roboters immer gleichmäßig im DB ankommen.

Wie macht man das?

Grüße aus Lux

 

[Windoze]

Das sieht soch soweit schon ok aus.
Das "BUSY" dauerhaft da ist ist normal, der Baustein wartet auf das nächste Datenpaket.
Immer wenn der Roboter ein Datenpaket schickt, ist für einen SPS-Zyklus "NDR" auf true.
Parallel steht in "RCVD_LEN" die Länge des Datenpakets, aber auch nur für einen Zyklus.

Grob würde ich mir mit dem Trigger ein Bit setzen und während das Bit aktiv ist und "NDR" kommt die Empfangenen Daten auswerten.
Wenn das korrekte Paket empfangen wurde, kannst du das Bit wieder zurücksetzen.
Dazu gehört dann natürlich noch eine Fehlerauswertung und ein Timeout, falls der Roboter nicht antwortet.

 

[Mogli]

Das sieht soch soweit schon ok aus.
Das "BUSY" dauerhaft da ist ist normal, der Baustein wartet auf das nächste Datenpaket.
Immer wenn der Roboter ein Datenpaket schickt, ist für einen SPS-Zyklus "NDR" auf true.
Parallel steht in "RCVD_LEN" die Länge des Datenpakets, aber auch nur für einen Zyklus.

Grob würde ich mir mit dem Trigger ein Bit setzen und während das Bit aktiv ist und "NDR" kommt die Empfangenen Daten auswerten.
Wenn das korrekte Paket empfangen wurde, kannst du das Bit wieder zurücksetzen.
Dazu gehört dann natürlich noch eine Fehlerauswertung und ein Timeout, falls der Roboter nicht antwortet.

hmmm... wenn ich den eingang "EN_R" aber auf "true" setze, dann wird das NDR nie aktiv.






Und auch die Antwort bleibt dann immer leer.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

NDR wird wird nur für 1 Zyklus aktiv, wenn der Kommunikations-Partner etwas gesendet hat. NDR = "New Data Received"

Wie lang ist Dein Trigger? Wenn der nur 1 Zyklus lang ist, dann ist es nahezu umöglich, daß im selben Zyklus ein NDR kommt.

PS: versuche nicht, zu viel Code in ein Netzwerk zu quetschen. Netzwerke die größer als eine Bildschirmseite sind, kann man nicht vernünftig beobachten.

Harald

 

[Mogli]

NDR wird wird nur für 1 Zyklus aktiv, wenn der Kommunikations-Partner etwas gesendet hat. NDR = "New Data Received"

Wie lang ist Dein Trigger? Wenn der nur 1 Zyklus lang ist, dann ist es nahezu umöglich, daß im selben Zyklus ein NDR kommt.

PS: versuche nicht, zu viel Code in ein Netzwerk zu quetschen. Netzwerke die größer als eine Bildschirmseite sind, kann man nicht vernünftig beobachten.

Harald

Hallo @PN/DP,

das ist mir bewusst. Darum habe ich mir ein SR Baustein dazwischen gelegt um zu sehen, dass das NDR Signal auch da war.
Jedoch bleibt der SR Baustein zunächst = false. Erst wenn ich das Telegramm 2x sende bekomme ich am Receive-Baustein was an.

 

[Windoze]

Probier mal "ADHOC" am TRCV auf true zu setzen. Das hatte ich vorher in deinen Screenshots übersehen.

 

[Mogli]

Zuviel Werbung?
-> Hier kostenlos registrieren

hi @Windoze

Vielen Dank für den Hinweis!




Jetzt kommen die Daten auch in dem DB an:

Und sie fangen immer bei Byte 0 an.
Da die Antworten unterschiedlich lang sind kommt meine Zusatzfrage.

Kann man den Array of CHAR umwandeln/ bearbeiten, sodass ich mir nur die BYTE anzeigen lassen, die ich benötige?
Die Anzahl sehe ich ja durch die Variable "RCVD_LEN.

Schon Mal tausend Dank!
Du hast mir sehr geholfen.

Grüße aus Lux!

 

[Windoze]

Du kannst die Daten z.B. mit "Chars_To_Strg" wieder zu einem String zurückwandeln.
Mit "Cnt" kannst du dort angeben, wieviele Zeichen er wandeln soll.

 

[Mogli]

Hi @Windoze

vielen Dank!
Jetzt kann ich endlich "sinnvolle" Antworten vom Roboter empfangen


TOP!

Grüße aus Luxembourg