PROFINET: Alternative zu RealIdentificationData requests?

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich arbeite im Apache PLC4X Projekt gerade an unserm PROFINET Treiber. Hier versuche ich die Benutzung so einfach wie möglich zu machen.
Nun habe ich das problem, dass ich z.B. mit meinem Simocode Pro V PN Gerät wunderbar anhand der vendor-id und device-id das passende GSD file finden kann und anhand der Daten, die mir die Antwort auf ein RealIdentificationData request liefert, kann ich mir quasi direkt ausgeben lassen, welche addressen das gerät akzeptiert und welchen Datentyp sie haben. Man kann diese dann direkt nutzen, um die daten zu abonnieren.

Die Adressen sehen in diesem Fall dann folgendermaßen aus:

1.1.INPUT.0:BYTE[10]

Nur habe ich einige Adam PN Geräte und eine Wago PN Buscoppler ... diese scheinen allerdings diesen RealIdentificationData request nicht zu unterstützen. Hier bekomme ich immer ein "nca_unk_if" als Antwort.

Gibt es alternative Wege, um herauszufinden welche ModuleIdentNummer für einen slot und welche SubmoduleIdentNummer für einen subslot definiert sind? Sonst muss ich diese in der Adresse mitliefern, was diese echt unschön machen würde und auch den Workflow etwas behindert, da ich nicht mehr wirklich einfach mir alle Adressen auflisten lassen kann und man diese dann direkt verwenden könnte.

Würde mich sehr über zusätzlich Infos freuen.

Gruß,
Chris

 

[olliew]

Um welcher RealIdentificationData geht es denn genau, gibt ja 4 Varianten? Indexnummer?

 

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dies ist der Request, den ich schicke und auf den SIemens geräte scheinbar korrekt antworten:

Distributed Computing Environment / Remote Procedure Call (DCE/RPC) Request, Seq: 1, Serial: 0, Frag: 0, FragLen: 84
    Version: 4
    Packet type: Request (0)
    Flags1: 0x20, Idempotent
    Flags2: 0x00
    Data Representation: 100000 (Order: Little-endian, Char: ASCII, Float: IEEE)
    Serial High: 0x00
    Object UUID: dea00000-6c97-11d1-8271-00010904002a
    Interface: PNIO (Device Interface) UUID: dea00001-6c97-11d1-8271-00a02442df7d
    Activity: eb384666-efb6-45a1-9490-06f558de009f
    Server boot time: Unknown (0)
    Interface Ver: 1
    Sequence num: 1
    Opnum: 5
    Interface Hint: 0xffff
    Activity Hint: 0xffff
    Fragment len: 84
    Fragment num: 0
    Auth proto: None (0)
    Serial Low: 0x00
    Complete stub data (84 bytes)

PROFINET IO (Device), Read Implicit
    Operation: Read Implicit (5)
    ArgsMaximum: 16696
    ArgsLength: 64 (0x00000040)
    Array: Max: 16696, Offset: 0, Size: 64
        MaximumCount: 16696
        Offset: 0 (0x00000000)
        ActualCount: 64
    IODReadReqHeader: Seq:0, Api:0x0, Slot:0x0/0x1, Len:16696
        BlockHeader: Type=IODReadReqHeader, Length=60(+4), Version=1.0
        SeqNumber: 0
        ARUUID: 00000000-0000-0000-0000-000000000000
        API: 0x00000000
        SlotNumber: 0x0000
        SubslotNumber: 0x0001
        Padding: 2 byte
        Index: RealIdentificationData for one API (0xf000)
        RecordDataLength: 16696 (0x00004138)
        TargetARUUID: 00000000-0000-0000-0000-000000000000
        Padding: 8 byte

 

[chrisdutz]

Mit diesen Informationen kann ich dann mehr oder weniger direkt mit dem Gerät kommunzieren, ohne dass ich im GSD die ids herauslesen muss:

PROFINET IO (Device), Read Implicit
    Operation: Read Implicit (5)
    Status: OK
    ArgsLength: 124 (0x0000007c)
    Array: Max: 16696, Offset: 0, Size: 124
        MaximumCount: 16696
        Offset: 0 (0x00000000)
        ActualCount: 124
    IODReadResHeader: Seq:0, Api:0x0, Slot:0x0/0x1, Len:60, AddVal1:0, AddVal2:0
        BlockHeader: Type=IODReadResHeader, Length=60(+4), Version=1.0
        SeqNumber: 0
        ARUUID: 00000000-0000-0000-0000-000000000000
        API: 0x00000000
        SlotNumber: 0x0000
        SubslotNumber: 0x0001
        Padding: 2 byte
        Index: RealIdentificationData for one API (0xf000)
        RecordDataLength: 60 (0x0000003c)
        AdditionalValue1: 0
        AdditionalValue2: 0
        Padding: 20 byte
    RealIdentificationData: APIs:1, Slots:2
        BlockHeader: Type=RealIdentificationData, Length=56(+4), Version=1.1
        NumberOfAPIs: 1
        API: 0x00000000
        NumberOfSlots: 2
        Slot: SlotNr:0 Ident:0x10 Subslots:4
        Slot: SlotNr:1 Ident:0x20 Subslots:1

Bei meinen Adam PN geräten und meinem Wago Buskoppler bekomme ich dagegen das hier:

Distributed Computing Environment / Remote Procedure Call (DCE/RPC) Reject, Seq: 1, Serial: 0, Frag: 0, FragLen: 4
    Version: 4
    Packet type: Reject (6)
    Flags1: 0x28, Idempotent, No Fack
    Flags2: 0x00
    Data Representation: 100000 (Order: Little-endian, Char: ASCII, Float: IEEE)
    Serial High: 0x00
    Object UUID: dea00000-6c97-11d1-8271-000102ee011d
    Interface: PNIO (Device Interface) UUID: dea00001-6c97-11d1-8271-00a02442df7d
    Activity: cea8cd95-481b-45a5-bb8e-b1184cd15496
    Server boot time: Unknown (0)
    Interface Ver: 1
    Sequence num: 1
    Opnum: 5
    Interface Hint: 0xffff
    Activity Hint: 0xffff
    Fragment len: 4
    Fragment num: 0
    Auth proto: None (0)
    Serial Low: 0x00
    Status: nca_unk_if (0x1c010003)

Beim positiven response, habe ich den DCE/RPC teil weg gelassen ... im Fehlerfall gab es leider keinen weitergehenden inhalt.

 

[olliew]

macht es ein Unterschied wenn im Request SubslotNumber 0x0000 verwendet wird?
welcher Response gibt es zu ein ImplicitRead von Index 0xF821?

 

[chrisdutz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit der subslotnummer 0 ist es das gleiche ergebnis ... das mit dem ImplicitRead muss ich mal in ruhe implementieren. Melde mich sowie ich antworten habe.

Aber gestern auch darüber gestolpert, dass ich den generellen Verbindungsaufbau hinbekommen habe ... allerdings hängt das gerät dann sehr schnell wieder auf ... etwas Recherche hat gezeigt, dass PN ein jitter von 100 Microsekunden erlaubt ... das sind 0,1ms ... heißt dass, wenn mein Programm nicht in der Lage ist auf 0,1ms genau requests zu generieren, dass eine Kommunikation dann überhaupt nicht möglich ist? In dem Fall bin ich mit Java sowieso auf dem Holzweg. Vielleicht nochmal mit Rust probieren (Habe keine lust auf C und ich denke Go wird keine Vorteile gegenüber Java bringen) ... wobei evtl. bin ich ja mit einem nicht RealTime-OS da sowieso verloren.

 

[olliew]

Mit der subslotnummer 0 ist es das gleiche ergebnis ... das mit dem ImplicitRead muss ich mal in ruhe implementieren. Melde mich sowie ich antworten habe.

Das verstehe ich nicht? Ein ImplicitRead ist doch genau das was du machst?

PROFINET IO (Device), Read Implicit
Operation: Read Implicit (5)
ArgsMaximum: 16696
ArgsLength: 64 (0x00000040)

.....

... etwas Recherche hat gezeigt, dass PN ein jitter von 100 Microsekunden erlaubt ... das sind 0,1ms ... heißt dass, wenn mein Programm nicht in der Lage ist auf 0,1ms genau requests zu generieren, dass eine Kommunikation dann überhaupt nicht möglich ist?

Bei normale Verbindungen ist der Jitter kein absolut-wert, in großenordnung 50 % sollte z.B. noch funktionieren in Laborumgebung.
Mit welcher Zykluszeit / Reduktionratio machst du den IOC-AR? Schraub das mal deutlich runter.

 

[chrisdutz]

Hi,

Oh ... stimmt ja ... wird nur im WireShark anders angezeigt ... ich hoffe das ist keine dumme frage: Wenn ich in dem ImplicitRead also statt dem Index: 0xF000, den 0xF821 nehme, dann bekomme ich nur eine leere "API" 0x00 00 00 00" zurück bei dem Siemens gerät und dennoch den gleichen fehler bei meinen Adams und der Wago.

Momentan habe ich diese settings:

    private int sendClockFactor = 128;
    private int reductionRatio = 16;
    private int watchdogFactor = 4;
    private int dataHoldFactor = 4;

Vorher hatte ich diese:

    private int sendClockFactor = 32;
    private int reductionRatio = 16;
    private int watchdogFactor = 3;
    private int dataHoldFactor = 3;

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

das ist kein leere API, sondern API 0x0

APIData
    BlockHeader: Type=APIData, Length=8(+4), Version=1.0
    NumberOfAPIs: 1
    API: 0x00000000

Normalerweise sollte dies beantwortet werden bei halbwegs aktuelle PN Devices. Hast du eventuell andere Devices zum ausprobieren zur Hand?

 

[olliew]

Wird der ConnectRequest mit SendClock 128 und ReductionRatio 16 auch korrekt rausgeschickt? und mit Response OK beantwortet?
SendClock 128 wird nicht zwingend von jedes PN Device unterstützt.

Wie schnell gehen denn deine RT Frames raus?

 

[chrisdutz]

Also mit den einstellungen kommt ein OK zurück

PROFINET IO (Device), Connect
    Operation: Connect (0)
    Status: OK
    ArgsLength: 90 (0x0000005a)
    Array: Max: 16696, Offset: 0, Size: 90
    ARBlockRes: IO Controller AR, Session:1, MAC:88:3f:99:00:06:ef, Port:0x8892
    IOCRBlockRes: Input CR, Ref:0x0001, FrameID:0x8002
    IOCRBlockRes: Output CR, Ref:0x0002, FrameID:0x8000
    AlarmCRBlockRes: Alarm CR, Ref:0x0000, MaxDataLen:200
    ARServerBlockRes
    [ARUUID:bbe50adc-e4fd-4f17-81c8-3e8493e22c62 ContrMAC:f8:e4:3b:b6:9b:bf ContrAlRef:0x0 DevMAC:88:3f:99:00:06:ef DevAlRef:0x0 InCR:0x8002 OutCR=0x8000]

Und wegen dem anderen device ... ich habe hier nun theoretisch 2 Adam Geräte, 2 S7-1200, einen Wago PN Felbbus koppler (neustes modell) und eine PhoenixContact PLCNext (die sich seltsamerweise auch als PN device meldet) Ich muss heute mittag mal mit allen durch spielen ... vielleicht antwortet ja die Wago darauf (hatte es jetzt nur mit den Adam teilen getestet)

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

S7-1200 kann auch als Device eingestellt werden. Such mal nach I-Device.

 

[chrisdutz]

Ok ... also ich habe mal meine S7 umkonfiguriert ... hatte zum Glück eine v4+ aber habe auch fortschritte gemacht ... wir arbeiten in Apache PLC4X zu zweit an einem PN treiber und mein Kollege hat es hinbekommen, dass das PN gerät zumindest 80 Sekunden lang erfolgreich daten austauscht ... jetzt muss ich noch schauen, was anders ist und dann zusehen, dass das auch länger geht. Ich denke dass da vermutlich eine drift in den cycle countern ist. Aber ich bin mir sicher ich werde das bald mal rausfinden.