TIA Kommunikation TIA CPU1511 mit Roboter Dobot Nova 2 via Modbus

[Ralph H.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe in einer Anlage die mit TIA V19 Update 5 programmiert ist einen Roboter Dobot Nova 2. Der Roboter soll mit der CPU (1511F-1PN) über MODBUS TCP kommunizieren was auch schon in Ansätzen funktioniert.

Wie kann ich möglichst elegant die Beschaltung des IN/OUT MB Data PTR variabel gestalten um die verschiedenen Register des Roboters schreiben oder lesen zu können?

 

[LehnerTh]

Hallo!

Das kommt ein bisschen darauf an wie viele/welche Daten.

Ich habe das meistens mit Schrittketten in SCL gemacht.
Lesen:
- Mode, Address, Len setzen
- Client Triggern
- Warten ob Done (-> PTR irgendwohin speichern) oder Error (-> Anzeige/Schrittkette reset)
- Wieder von vorne mit nächster Address

Beim Schreiben halt PTR beschreiben, dann triggern und auf done/error warten.

Wenn du viele Adressen hast kannst du diese für Schreiben/Lesen je in ein Array packen, dazu je ein Array für die PTR Daten.
Dann holst du beim Lesen die Adresse aus ReadAdressArray[0], wartest auf done und schreibst PTR in das ReadPTRArray[0].
Dann Zähler erhöhen und wieder von vorne.
Analog dazu das Schreiben.

 

[Ralph H.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die Antwort.
Wie viele Daten es sind weiß ich noch nicht genau. Vom Datenformat geht es von einzelnen Bits bis zu 8 Byte langen Real Werten.

 

[Ralph H.]

Danke für Deine Antwort.
Wie viele Daten es sein müssen weiß ich noch nicht. Die Datenformate gehen von einzelnen Bits bis zu 8 Byte großen LReal Werten

 

[LehnerTh]

Ok mit verschieden langen Daten hab ich das auch noch nicht gemacht.
Wenns nur wenige Daten sind würd ich alles händisch ausprogrammieren und direkt zuweisen.

Wenns viele Daten sind, würde mir auf die schnelle einfallen auch ein Array für LEN anzulegen und das PTR-Array 2 dimensional damit du in jedem Index 8 byte hast.
Und dann anhand des LEN-Array die Daten lesen/schreiben bzw. dann außerhalb der Schrittkette zur Weiterverarbeitung aufbereiten.
Da ist zwar schon etwas getrickse mit den bytes dabei aber es sollte gehen...
Vielleicht hat jemand eine elegantere Lösung?

 

[Bapho]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe vor ein paar Wochen einen Dobot Magician hingestellt bekommen und sollte da was für eine Messe programmieren.
Nach ewigem rumprobieren, haben wir dann einen Arduino rangeklemmt, daß ganze Ding in C programmiert und dann an dem Arduino paar E/As eingerichtet.
Für die Messe hats gereicht, keine Ahnung ob deine Kiste da bissle komfortabler ist, aber am Ende war das für mich einfacher, als mit der komischen Software rumzufrickeln.

 

[Ralph H.]

Guten Morgen LehnerTh,
kannst Du mir bitte zeigen in welchen Datenformaten Du die Parameter am MB Client parametriert hast damit ich verschiedene Register schreiben und lesen kann? Wie hast Du den DB für die Schreib- und Lesedaten aufgebaut.

 

[LehnerTh]

Guten Morgen auch!

Wie gesagt habe ich das mit verschiedenen Datentypen auch noch nicht gemacht...
Der Pointer am MB_DATA_PTR lässt sich wohl nicht dynamisch ändern.
Ich würde versuchen die bits auch als ganzes word zu lesen und dann auszuwerten.

Mit meinen Array-DBs ging es darum verschiedene, nicht zusammenhängende Adressbereiche zu lesen/schreiben, aber immer nur ganze words...
Ein AdressArray[0..x] hatte quasi die Leseadressen gespeichert. Die bin ich mit einem Zähler durchgelaufen, hab jeweils auf das done gewartet und das was im Puffer vom PTR stand in ein LeseDatenArray[0..x] zur späteren verwendung abgelegt. Da war der Puffer nur 1 word groß.

 

[Ralph H.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen LehnerTh,

ich melde mich nochmal mit einigen Fragen. Wie hast Du den Request am MB-Client beschaltet? Wie überträgst Du die Daten zum Schreiben oder lesen in den MB_Data_PTR?
Bei mir sieht es aktuell so aus:

 

[LehnerTh]

Da musst du dir eine Schrittkette bauen, SCL empfiehlt sich hier.
LEN hängt natürlich von deinem Puffer ab. Der Puffer muss wohl fix bleiben, sonst hätte wahrscheinlich schon jemand was dazu geschrieben.
->Also LEN bleibt immer gleich

Lesen:
- Mode auf den benötigten Lesemodus setzen, Addr auf die gewollte Adresse setzen
- REQ setzen
- Kommt Done -> Puffer irgendwohin speichern zur späteren Verarbeitung -> REQ Rücksetzen -> Wieder von oben starten mit nächster Addr
- Kommt Error -> Abbruch, neu starten, reseten, Fehler anzeigen, wie du willst
Solange bis alle Addr abgearbeitet sind
Dann weiter zum Schreiben

Schreiben:
- Mode auf den benötigten Schreibmodus setzen, Addr auf die gewollte Adresse setzen
- Gewollten Wert auf Puffer schreiben
- REQ Setzen
- Kommt Done -> REQ Rücksetzen -> Wieder von oben starten mit nächster Addr
- Kommt Error -> Abbruch, neu starten, reseten, Fehler anzeigen, wie du willst
Solange bis alle Addr abgearbeitet sind

Kann man auch lokal mit einem Modbus-Server testen wenn man die Hardware noch nicht hat.
In diesem Video wird Lesen/Schreiben mit den Modes und lokales Testen nochmal genau erklärt.

 

[LehnerTh]

Wenn dieser Grundaufbau mal läuft kommt es nur noch drauf an welche und wieviele Daten du Lesen/Schreiben musst.

Um bei vielen Adressen nicht alles händisch coden zu müssen, lege ich mir ein Array an.
Mein Array of udt hat gleich einen Namen (für Codeverständnis und Visu, die Adresse, den Wert (Aus/In den Puffer) und einen Umrechnungskoeffizient für die spätere Umrechnung.

Für das hier gezeigte Lesen wird getriggert und bei erhaltenem Done der trigger (1 Zyklus) weggenommen und der Zähler erhöht.
Dann kommt noch ne Error-Auswertung und es läuft.

 

[LehnerTh]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich sehe gerade du willst 4 bit schreiben.
Zum Schreiben des Puffers musst du halt die 4 bits einzeln setzen, so wie du sie je nach gewolltem Befehl brauchst.

Sagen wir zum Stoppen braucht der Roboter 0101.
Dein Tastendruck belegt die 4 bits am PTR-Puffer wie gewollt und startet dann den Schreibvorgang-Ablauf einmalig.

Sonst schreib mal detailliert was du brauchst.
Lesen und/oder schreiben. Laufend oder Ereignisgesteuert mit Tasten. Verschiedene Datentypen (bits, words)?

man kann das z.B. auch trennen und auf mehrere Clients aufteilen. Ein Client würde Ereignisgesteuert einzelne bits schreiben und den Roboter zu Starten/Stoppen. Ein anderer könnte words (Statusinfo, Koordinaten) lesen.

 

[LehnerTh]

Noch ein Hinweis ohne die Anwendung zu kennen: Stoppen durch Modbus ist alles andere als Sicher! Bei Kommunikationsproblemen kann es sein dass das Ding weiterfährt!

 

[Ralph H.]

Hallo LehnerTh,

vielen Dank für Deine Hinweise.
Die Bandbreite der Werte die geschrieben oder gelesen werden sollen geht von wenigen Bits bis zu LREAL Werten für die Positionen. ich möchte zB. den aktuellen Status des Roboters permanent auslesen. Andere Signale wie z.B. Programmstart sind ereignisgesteuert. An dem Roboter ist ein Doppelgreifer montiert der von der SPS gesteuert wird. Für Aktionen mit einem der Greifer wird der Roboter in einem Pausenzustand angehalten. Um die Kommunikation zu überwachen möchte ich ein Lebensbit schreiben und lesen.
Wie meinst Du das mit der 2. Instanz vom MB_Client? Meine Mailadresse ist rh@sax-munition.de.
Ich stehe auch im Austausch mit der deutschen Vertretung von Dobot.

 

[Maagic7]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie kann ich möglichst elegant die Beschaltung des IN/OUT MB Data PTR variabel gestalten um die verschiedenen Register des Roboters schreiben oder lesen zu können?

Wieso?
Modbus hat 64K 16Bit Register. Lies doch die Daten die brauchst auf einmal. Bei TCP interessiert nicht, ob da ein paar Bytes dabei sind, die du nicht brauchst. Bzw. Mach dir ein paar Aufrufe des Lesebausteins, der verschieden Registerbereiche liest.
Mei Modubs TCP hast du 12Byte Frame Daten und die maximale Datenlänge die du als Daten pro Frame angeben kannst ist 16Bit also 64KB. Das wären 32K Register auf Einmal. Bei einer 1Mbit Verbindung schafft man 128KB/sec. Nehmen wir mal an du liest auf 3x je 4KB, das sind dann 12KB gesamt, des geht rund in 1/10sec.

 

[LehnerTh]

Wenn die Daten so unterschiedlich sind, empfiehlt es sich wie Maagic sagt. Große Bereiche lesen und die Daten dann zerlegen.
Mit mehreren Clients meinte ich, du kannst die verschiedene Client-Instanzen machen wenn du verschiedene Puffer brauchst/willst, z.B. eine für das Lesen der großen Daten und eine für das Schreiben der einzelnen bits. Dann kannst du in deinem Ablauf die beiden Instanzen nacheinander Triggern.

Dann halt das Programm Schritt für Schritt ausbauen.
Manuell Verbindung aufbauen und Lesen -> Größeren Bereich lesen und Daten zerlegen -> In einen Ablauf packen und Automatik Testen.
Das selbe für das Schreiben.

 

[Ralph H.]

Wie muss ich die beiden MB Client parametrieren wenn ich einen zum Lesen und einen zweiten zum Schreiben nutzen möchte?

Kann ich zum Zerlegen der gelesenen Daten die Funktion "Deserialiseren" benutzen? Wie müssen die beteiligten DB's aufgebaut sein? Für einen Screenshot wäre ich dankbar.

 

[LehnerTh]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die parametrierst du gleich, nur am Connect musst du eine andere Verbindungs-ID angeben. Du bist aber von der SPS her auf eine gewisse Anzahl maximaler Verbindungen limitiert.
Mit Deserialise kenn ich mich nicht aus...

 

[Ralph H.]

Hallo zusammen.

ich kämpfe immer noch mit der Parametrierung des MB Client. Ich will testweise eine Achsposition lesen. Die ist ab dem Register 31217 lesbar. Welche Länge muss ich für einen LREAL Wert angeben?



Die Fehlermeldung "818B" bedeutet laut TIA Hilfe:

Ich hoffe auf Eure Expertise.

 

[LehnerTh]

LREAL sind 64bit, also 4 Words. LEN sollte also passen.
Wie sind deine Achspositionen angelegt? Als LREAL? Versuch mal am PTR ein Array [0..3] of Word anzuhängen.