VIPA als Modbus RTU Master

[EyeQ]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich versuche mich seid einiger Zeit daran, eine Kommunikation via Modbus zustande zu bringen. Der Vipa-Support konnte mir bisher leider nicht helfen. Ich habe eine Vipa-314SE (314-2BG03).
Meine HW habe ich so konfiguriert, wie es mir der Support empfohlen hat: DP-Schnittstelle auf Profibus, nicht vernetzt, fertig.

Im OB 100 wird der SFC216 aufgerufen und konfiguriert die Schnittstelle auf Modbus RTU Master.

So nun sende ich mittels SFC217 meinen Request, bekomme aber immer die Meldung "Quittungsverzugszeit überschritten". Mein Kommunikationspartner ist ein Motorcontroller von ComAP. Daraufhin habe ich meinen PC an die Schnittstelle gehängt und mit dem Tool "Simply Modbus Slave" abgehört.
Dabei musste ich feststellen, dass ich mit dem Tool nicht das angezeigt bekomme, was ich abgeschickt habe. Nicht nur dass die Bits andere Zustände zeigen, es werden teilweise sogar 1 Byte mehr oder weniger angezeigt.
Da im ersten Byte die Teilnehmeradresse steht und die nicht ankommt wie ich sie abgeschickt habe ist es mir klar, dass ich keine Antwort bekomme. Leider habe ich keine Erfahrung in Sachen Modbus. Deshalb weiss ich nicht genau ob ich die angezeigten Informationen richtig interpretiere. Ich habe nun mehrere verschiedene Requests gesendet und immer kam etwas anderes an als gesendet. ein Muster wie die empfangenen Daten umgewandelt sein könnten kann ich auch nicht erkennen.

Ich bin langsam echt am verzweifeln. VIPA sagt: Meine Config ist zu 100% richtig und das Programm funktioniert auch. ComAP sagt: sollte funktionieren, geht sonst auch. Die Einzigen Einstellungen die ich da machen kann sind Protokoll und Adresse.

Die Einstellung auf der Schnittstelle sollte auch richtig sein laut Info von ComAP.

Hat irgendjemand eine Idee was da los sein könnte ? Ich weiss nicht was ich noch machen soll :/
Ich hänge mal mein Testprojekt an, vllt hat ja jemand etwas Zeit es sich mal anzugucken.

Danke schon mal.

Edit: Das Ganze habe ich mit STEP7 5.4 SP5 projektiert, bennutze ein serielles Kabe für die Verbindung und die Schnittstelle am Motorcontroller funktioniert einwandfrei. Muss also an der VIPA liegen ??

 

[uncle_tom]

Hab mir dein Projekt mal angeschaut,

wenn ich den Auftrag richtig analysiert habe, dann versuchst du vom Slave mit der Adresse 1 das Register 8213 mittels Funktionscode 3 zu lesen.

Der Byteaufbau sollte so passen, der errechnete CRC-Wert würde auch dazu passen.

Ich kenn den VIPA-Treiber und die Hardware jetzt nicht weiter. Ich kenn´ mich aber mit Modbus recht gut aus, hab mir für S7 auch nen eigenen Modbus-Treiber geschrieben (CP340/CP341).

Hast du schon mal versucht den Slave (ComAP) mittels Modbus-Master Simulator auszulesen (z.B. Simply Modbus Master). Wenn das nicht funktioniert, dann funktioniert es mit der VIPA erst recht nicht.

Die Modbus-Spezifikation (Protokollbeschreibung, Byteaufbau, etc.) kannst du dir übrigens kostenlos herunterladen. Link

Hoffe dir ein bissel weiter geholfen zu haben.

Mfg
uncle_tom

 

[EyeQ]

Zuviel Werbung?
-> Hier kostenlos registrieren

Erstmal ein Danke für die schnelle Antwort...

Zu deiner Frage: Ja, ich spiele mit beiden tools schon ein weilchen herum.
Wenn ich via "Simply Modbus Master" die gleiche Anfrage an den Controller sende, bekomme ich eine plausible Antwort zurück, funktioniert also einwandfrei.
Sende ich aber von der SPS an den PC ("Simply Modbus Slave") bekomme ich genau diesen String "7F 7E AB FF FD C3 BC FF FF" wobei ich hier meine errechnete Checksumme mitsende (also 8 byte), bin mir aber nicht sicher ob ich das überhaupt tun muss. Wenn ich mehr mals hintereinander sende, kommt es vor, dass zwischendurch ein anderer String empfangen wird oO.

 

[EyeQ]

sorry, muss leider einen Doppelpost starten, da man im edit
keine Dateien anhängen kann :/

Screenshot Simply Modbus Slave.
Vielleicht kann ich den auch nur nicht richtig bedienen.

 

[uncle_tom]

Servus nochmal,

also das Telegramm von der Vipa macht überhaupt keinen Sinn (unsinnige Slave-Nummer; unsinniges Startregister und völlig unsinnige Anzahl von Registern sowie fehlerhafter CRC).

Ich hab mir jetzt mal das Handbuch der 314SE von VIPA geladen. Bzgl. der Parametrierung des Treibers bzw. der SFC´s bei Modbus steht ja eigentlich so gut wie gar nichts drin - es steht ja nur drin, dass die Nutzdaten per Pointer dem SFC zu übergeben sind - jedoch nicht wie diese aufzubauen sind (Function-Code etc.).

Ich geh mal davon aus, dass die CRC-Berechnung von der VIPA durchgeführt wird - irgendetwas muss der SFC ja auch noch tun - den Rest muss man ja eh schon selber machen (Nutzdaten zusammenstellen).

Ich hab eigentlich gedacht, dass der FC für die CRC Berechnung von VIPA ist, aber scheinbar ist der von dir (ist ja auch nicht geschützt). Wenn du dir das schon selber zurecht gelegt hast, dann könntest du auch mal versuchen die Vipa-Schnittstelle direkt im ASCII-Modus zu betreiben. Die von dir zusammengestellten Sende-Nutzdaten im DB600 entsprechen ja schon genau der Modbusspezifikation. Als Antworttelegramm solltest du dann auch wieder ein Telegramm mit etwa folgendem Aufbau erhalten:

Byte 1 - Functioncode (3)
Byte 2 - ByteCount (2, da 1 Modbusregister 2 Byte)
Byte 3 - High-Byte von Modbusregister 8213
Byte 4 - Low-Byte von Modbusregister 8213
Byte 5 - High-Byte CRC-Check
Byte 6 - Low-Byte CRC-Check

Im Byte 2 könnte auch der Wert 4 stehen, da ich mir jetzt aus dem Stehgreif heraus nicht mehr sicher bin ob hier die 2 Bytes vom CRC-Check mitgezählt werden.

Weiterhin solltest du evtl. mal klären ob es ausreicht den SFC für die Konfiguration der Schnittstelle nur im OB100 beim Anlauf aufzurufen (evtl. liegt ja hier das Problem.)

Mfg
uncle_tom

 

[EyeQ]

Zuviel Werbung?
-> Hier kostenlos registrieren

also das Telegramm von der Vipa macht überhaupt keinen Sinn (unsinnige Slave-Nummer; unsinniges Startregister und völlig unsinnige Anzahl von Registern sowie fehlerhafter CRC).

+ 1 Byte zu viel, eines zuwenig habe ich auch schon gesehen

Byte 1 - Functioncode (3)
Byte 2 - ByteCount (2, da 1 Modbusregister 2 Byte)
Byte 3 - High-Byte von Modbusregister 8213
Byte 4 - Low-Byte von Modbusregister 8213
Byte 5 - High-Byte CRC-Check
Byte 6 - Low-Byte CRC-Check

da fehlt doch noch die slave Adresse im Byte 1 oder?

Wenn du dir das schon selber zurecht gelegt hast, dann könntest du auch mal versuchen die Vipa-Schnittstelle direkt im ASCII-Modus zu betreiben.

Wie genau meinst du das? Die Schnittstelle über den config SFC als ASCII konfigurieren und einfach die Bytes abschicken ? könnte ich mal versuchen. Leider habe ich wenig erfahrung in Sachen serielle Kommunikation.

Weiterhin solltest du evtl. mal klären ob es ausreicht den SFC für die Konfiguration der Schnittstelle nur im OB100 beim Anlauf aufzurufen (evtl. liegt ja hier das Problem.)

Das wurde mir vom VIPA Support so "beigebracht". Kann ich mir auch kaum vorstellen dass der Baustein zyklisch aufgerufen werden muss. Aber ein Versuch wäre es mir schon Wert

Ich habe langsam ja das Gefühl das die CPU auf irgendeine Weise defekt ist, obwohl, wenn ich immer die selben Bytes schicke und die selben (falschen) bytes ankommen, mich das eher auf einen Softwarefehler schließen lässt.

Langsam bin ich echt kaputt.. Der Vipa Support braucht immer 3 Tage um keine Antwort zu finden und ruft dann nicht einmal zurück. Das hat mich echt enttäuscht. Naja ansonsten echt flott die Dinger ^^

Danke die Mühen die ihr euch wegen mir macht

 

[uncle_tom]

da fehlt doch noch die slave Adresse im Byte 1 oder?

da hast du recht (ich hab jetzt noch mal in meinem Source-Code nachgeschaut).

Wie genau meinst du das? Die Schnittstelle über den config SFC als ASCII konfigurieren und einfach die Bytes abschicken ? könnte ich mal versuchen. Leider habe ich wenig erfahrung in Sachen serielle Kommunikation.

genauso hab ich das gemeint. Der "Send.Query" Bereich im DB600 in deinem Projekt entspricht 100%ig dem Aufbau eines Modbus-Requests für den Function-Code 3 (Read-Multiple Registers). Wenn du diese Bytefolge im reinen ASCII-Modus über deine Schnittstelle verschickst, dann sollte dein Slave bzw. dein Test-Slave sich angesprochen fühlen und dir ein Antworttelegramm wie bereits beschrieben zurückschicken - vorausgesetzt die VIPA gibt das Telegramm bzw. die Bytefolge auch so an der Schnittstelle aus.

Wenn das auch nicht funktioniert, dann hat evtl. wirklich die Schnittstelle bzw. die CPU einen Defekt. Hier muss dann VIPA mal eine Aussage treffen.

Wir haben bei uns in der Firma auch schon das ein oder andere mal mit VIPA herumgespielt, sind dann aber meist zu der Erkenntniss gekommen - wenn schon Step 7 dann auch ne richtige Siemens CPU - und haben die VIPA wieder rausgeschmissen.

Mfg
uncle_tom

 

[EyeQ]

Hallo,

ich habe die zwei Sachen jetzt nochmal getestet. Den SFC216 zyklisch aufrufen hat keine veränderung gebracht. Dann habe ich die Schnittstelle mal im "reinen" ASCII Modus konfiguriert. Dabei bekomme ich die gleichen Daten wie bei Modbus RTU: 1 wird zu 7F usw. Mich wundert ja wirklich dass jeder Wert einen festen Gegenwert hat als ob er mit einer Konstante multipliziert wird. Leider habe ich keine Regelmässigkeit entdecken können, die man zur Umrechnung benutzen könnte.

Wie dem auch sei. Die CPU geht nun zurück an VIPA, die werden das mit meiner CPU ausprobieren und mir eine neue schicken. Also erstmal Schluss mit lustig.

Vielen Dank uncle_tom für deine kompetente Unterstützung.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist zwischen der VIPA und dem Motorcontroller irgendein Pegelwandler in der Busleitung?
Sind vielleicht die A- und B-Leitung der RS485 über Kreuz angeschlossen?

1 -> 7F : alle Bits negiert und Bit-Reihenfolge umgekehrt.
Ist da ein Schieberegister oder eine parallel/seriell-Wandlung im Spiel?

Gruß
PN/DP

 

[EyeQ]

Ist zwischen der VIPA und dem Motorcontroller irgendein Pegelwandler in der Busleitung?
Sind vielleicht die A- und B-Leitung der RS485 über Kreuz angeschlossen?

1 -> 7F : alle Bits negiert und Bit-Reihenfolge umgekehrt.
Ist da ein Schieberegister oder eine parallel/seriell-Wandlung im Spiel?

Gruß
PN/DP

Das Thema hat sich für mich immo erstmal erledigt, da ich keine CPU mehr habe. Aber auf die Idee bin ich auch schon gekommen. Leider trifft diese Feststellung nicht auf alle Zeichen zu. Bei einer gesendeten 3 kam schon ein anderes Ergebnis.
Ich habe übrigens ein noramles serielles Kabel benutzt (RS232) 2 und 3 gekreuzt 5 Masse. Dazwischen war nichts, Vipa Schnittstelle an Com-Port (PC). Der Mist muss irgendwo zwischen SFC217 und HW-Schnittstelle passieren :/. Naja mal abwarten was VIPA dazu sagt.

Trotzdem Danke.

 

[uncle_tom]

Servus nochmal,

Die VIPA-Schnittstelle ist aber doch eine RS485 und keine RS232 Schnittstelle. Das kann ja nicht funktionieren. Wenn du die mit deiner PC-Schnittstelle (COM1/2) verbunden hast, dann ist die jetzt unter Umständen kaputt.

Wenn du deinen PC richtig mit der VIPA oder irgendeiner anderen RS485 Schnittstelle verbinden willst, dann brauchst du einen Schnittstellenwandler (RS232==RS485).

Bei der VIPA-Schnittstelle werden für RS485 nur die Pins 3 und 8 benötigt.

Ich hab mal ein bissel gegoogelt bzgl. "ComAp - Motorcontroller". Ich geh mal davon aus, dass du sowas Link ähnliches im Einsatz hast.
Das Teil hat ebenfalls eine RS232 Schnittstelle, von daher hat das ganze mit dem Testreiber auf deinem PC funktioniert.

Da kann die VIPA jetzt vermutlich nichts dafür.

Als Schnittstellenwandler kannst du z.B. sowas

Link

verwenden.

Da hätten wir auch früher drauf kommen können, ich bin eigentlich fest davon ausgegangen, dass immer von RS485 die Rede war.

Mfg
uncle_tom

 

[EyeQ]

Zuviel Werbung?
-> Hier kostenlos registrieren

Servus nochmal,

Die VIPA-Schnittstelle ist aber doch eine RS485 und keine RS232 Schnittstelle. Das kann ja nicht funktionieren. Wenn du die mit deiner PC-Schnittstelle (COM1/2) verbunden hast, dann ist die jetzt unter Umständen kaputt.

...

Da kann die VIPA jetzt vermutlich nichts dafür.

Oh mann, ich fürchte du hast Recht. Darauf bin ich nu noch gar nicht gekommen. Das würde auch die vielen High-Bits erklären und auch dass keine Antwort kam.. ich bin ja so blöd Das is mir nun echt peinlich.