PROFINET: Kann man die "endianess" vorgeben?

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

ich mache große Fortschritte beim implementieren eines Open-Source PROFINET Masters für das Apache PLC4X Projekt. (Ja wir haben eine Vendor ID ;-) )

Allerdings bin ich gerade über eine Sache gestolpert:
Ich nutze ein SIMOCODE PRO V PN Profinet, welches ich mit Tia Portal Pro und Simocode Pro (v16) projektiert habe. Ein PROFINET Master kann sich auch korrekt verbinden und die BUS leuchte geht an. Jetzt versuche ich das für das PLC4X Projekt nachzubauen. Datenstrukturen, Serializer und Parser sind fertig und tun ihren Job auch ordentlich.

Um den Verbindungsaufbau zu machen, muss ich ja PROFINET IO Connection Manager (PNIO-CM) verwenden. Das ist a eine reihe von Protokollen gestapelt.
Nun kann ich im DCE/RPC teil angeben, ob die Nachricht big-endian oder little-endian sein soll. In einem Wireshark Mitschnitt habe ich gesehen, dass hier Little-Endian verwendet wurde. Das hat den unschönen Nebeneffekt, dass ich innerhalb meines Treibers die Endianess wechseln muss.
- Ethernet (Big-Endian)
- IP (Big-Endian)
- UDP (Big-Endian)
- DCE/RPC (Little-Endian)
- PROFINET IO CM (Little-Endian)
- Blöcke im PROFINET (Big-Endian)

Also hatte ich im DCE/RPC einfach mal frecherweise gesagt: Big-Endian und habe entsprechend die DCE/RPC und PROFINET IO (Sind ja eigentlich nur die 5 Längen- und Anzahl-Angaben) auch Big-Endian gemacht.

Wireshark decodiert mir alle Felder identisch mit meinem mitschnitt. Allerdings bekomme ich ein "nca_unk_if" ... also ein reject, welches allerdings auch Little-Endian kodiert ist.

Kann es sein, dass mein kleiner Trick dem Controller nicht gefällt? Ich würde dies nur gerne bestätigt haben, bevor ich anfange den Aufwand zu betreiben die Endianess in der Mitte des Stacks zwei mal zu wechseln.

Gruß,
Chris

 

[Thomas_v2.1]

Die Angabe der Endianess und auch des String Encodings gelten nur für den RPC Header.

Ich habe grad mal nachgesehen, S7-1200 ist IO Controller, S7 Et200S CPU ist IO Device. Controller fragt im CR mit Big Endian an, Device antwortet mit Little Endian.

 

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Thomas,

danke fürs nachschauen ... dann verstehe ich allerdings nicht, warum in Wireshark die daten im PROFINET IO CM immer im gleichen encoding behandelt werden, als im DCE/RPC angegeben werden. Ich habe mal zwei Beispiele angehängt. Da sieht man, dass im falle von Little-Endian im DCE/RPC auch der PROFINET IO Container (also das teil, dass die ganzen Blöcke enthält) auch Little-Endian ist ... allerdings sind die Blöcke selbst dann wieder immer Big-Endian.

Ich habe nochmal verglichen und ich hatte lediglich unterschiede in vendorId productId (sind ja im objectUid encodet) sowie im vorderen block der Activity UUID. Daher habe ich mal testweise diese werte aus dem funktionierenden mitschnitt genommen und da habe ich einen positives Connection Response bekommen. Danach habe ich getestet ... am ende mag scheinbar das gerät meine Kombination aus productId und vendorId nicht.

Soweit ich das verstanden habe, wird die Vendor ID einem "Hersteller" offiziell zugeteilt. Im Falle der Apache Software Foundation ist das die 0x060B ... die product Id kann der Vendor dann selbst vergeben. Wir haben uns für "0xC0FE" entschieden ;-) ... leider nimmt das gerät allerdings keine dieser werte an.

Was mache ich hier falsch?

 

[chrisdutz]

Argh ... als ich mal decodiert habe, was das denn für eine Vendor ID ist ist es mir wie Schuppen von den Augen gefallen ... das war nicht vendor-id und product id des PROFINET-IO master herstellers, das sind die IDs des Zielgeräts ... 0x002A ist SIEMENS ... oh man :-(
Bitte entschuldigt meine blödheit :-( und danke nochmal.

 

[Thomas_v2.1]

Es gibt oder zumindest gab mal die letzten Draft Versionen der Profinet Spezifikation im Netz, wenn man nicht der PNO beitreten und die offiziellen Specs erwerben möchte. Das ist zwar nicht nur ein Dokument sondern besteht aus vielen einzelnen die aufeinander aufbauen. Aber selbst die Draft Version ist besser als sich auf Wireshark zu verlassen, das dokumentiert zudem auch nicht die Ausnahmen und Besonderheiten.

 

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe sogar eigentlich die Spec käuflich erworben. Zum Glück ist es hier nicht so schlimm wie in anderen specs (bei der KNX spec z.B.). Generell wird hier immer ein ISO layer nach dem anderen bis ins kleinste detail beschrieben. Wenn ich einen Treiber schreibe, interessieren mich alledings die layer zwar auch, allerdings sind für mich die querschintt informationen wie "wie sieht ein Connection Aufbau" aus. Hier habe ich mir auch eher angewöhnt die Kommunikation zu beobachten und dann in der Spec erklären zu lassen. Aber vielen dank für die Infos ;-)

 

[chrisdutz]

Hallo,
Um diese Unterhaltung nicht im nichts enden zu lassen: Ja ich kann die Endianess vorgeben, wenn ich einen Request losschicke. Das PN Gerät akzeptiert diese auch in beiden varianten. Nur bestimmt dies nicht, wie die Antwort zurück kommt. Ich kann also nicht durch einen Big-Endian Request einen Big-Endian Response erzwingen. Bei mir kam also in allen fällen ein Little-Endian Response an und ich musste den Treiber dementsprechend flexibler machen.

Gruß,
Chris