Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched. Close

Problem mit CAN-Modul-Mapping auf WAGO PFC200

Anonymous
2019-01-02
2019-05-24
  • Anonymous - 2019-01-02

    Originally created by: MR_CAN

    Hallo zusammen und ein frohes Neues!

    Ich nutze eine WAGO PFC 200 (750-8204) mit der 3S-Runtime (3.5.11.20) und CODESYS V3.5 SP15 Patch 1 (unten beschriebenes Fehlerverhalten wurde aber auch mit einer neueren CODESYS-Version und einer neueren Runtime getestet, um einen Versionsfehler auszuschließen)

    Folgendes Fehlerverhalten/Konfiguration: CAN-Netz mit Buskoppler 750-348 und folgenden Modulen:

    750-502 (2K Dig. Ausgang)
    750-530 (8K Dig. Ausgang)
    750-530 (8K Dig. Ausgang)
    750-430 (8K Dig. Eingang)
    750-430 (8K Dig. Eingang)
    750-1425 (PTC Eingang)
    750-610 (Einspeisung)
    750-502(2K Dig. Ausgang)
    750-455 (Analog Eingang)

    Auch im Konfigurationsmodus kann ich die Ausgangskanäle so nicht ansteuern. Wenn ich das erste Modul in der CoDeSys-Konfiguration weglasse, funktioniert es, aber dann sind logischerweise die beiden Kanäle des ersten Modules auf dem -530 abgebildet, und der erste Kanal des -530 liegt auf Kanal 3. Also ein Offset von 2 Bit, da das Modul hardwareseitig gesteckt ist, aber nicht konfiguriert. Wenn ich es in CoDeSys konfiguriere, kann ich gar nichts ansteuern. Wenn ich dagegen das zweite -502 entferne (das vorletzte Modul), dann läuft es.

    Ich habe damit jetzt einiges herumprobiert, von Verschieben der Reihenfolge in CoDeSys, bis zum Löschen des Kompletten Busknotens und neuem Anlagen in der richtigen Reihenfolge. Auch ein zweiter (neuer) 750-348 Koppler kam zum Einsatz. Das Verhalten ist für mich etwas merkwürdig und ich kann nicht genau beschreiben, wo genau das Problem liegt, aber es gibt offensichtlich massive Probleme mit dem Mapping und der von mir gezeigten Konfiguration.

    Hat jemand eine Idee, woran das liegen kann? Liegt hier möglicherweise ein Bug vor?

     
  • eschwellinger

    eschwellinger - 2019-01-02

    Hi,
    am besten du "scannst" mal die KBus Module ( rechtsclick Geräte suchen,
    das geht sowohl beim KBUS als auch auf dem CANopenManager)
    Ich würde definitiv die aktuelleste CODESYS Version und auch die aktuelle PFC200 Runtime version verwenden da zu Sp13 da bezüglich Mappings von Zählerklemmen
    was korrigiert wurde.

    Grüße
    Edwin

     
  • Anonymous - 2019-01-02

    Originally created by: MR_CAN

    Hi,

    KBUS-Scan funktioniert bei mir nicht (wird im Rechtsklick-Menü nicht angeboten; siehe Bild). Beim CANopen-Manager funktioniert es.

    IMG: KBUS

     
  • eschwellinger

    eschwellinger - 2019-01-02

    du must den "PFC200 BUS "links im Baum selektieren damit das Menu Kommando erscheint...

    Grüße
    Edwin

     
  • Anonymous - 2019-01-02

    Originally created by: MR_CAN

    Dann werden aber nur die direkt an der SPS abgeschlossenen Module gescannt. Dort gibt es keine Probleme. Das Problem liegt an den Modulen an einem Buskoppler. Geht dort auch ein KBus-Scan? Ansonsten habe ich den Buskoppler auch schon gelöscht und neu eingefügt, dann die vorhandenen Module angefügt. Funktioniert aber trotzdem nicht.

     
  • Anonymous - 2019-01-02

    Originally created by: MR_CAN

    Es funktioniert einfach nicht. Nun habe ich folgenden Aufbau (im Anhang) sowohl genauso mit der Hardware aufgebaut, als auch in CoDeSys konfiguriert.

    Das zweite 750-502 - Modul lässt sich nicht ansteuern. Ist auch kein Wunder, wenn man sich das zugehörige Mapping ansieht. Egal wie ich die Module schiebe und anordne, das Mapping funktioniert nicht, wenn ein zweites 502 dabei ist. Was stimmt da nicht?

    IMG: mapping.png

     
  • Anonymous - 2019-01-02

    Originally created by: MR_CAN

    und nochmal etwas ausprobiert: Komplett leeres Projekt, CAN, CANopen_Manager und den Koppler 750-348 eingefügt. Dann das PDO-Mapping geöffnet und die oben im Bild gezeigten Module angehängt. Bis zum ersten 750-502 wird das RPDO1 ordentlich gefüllt, beim zweiten 750-502 wird links der Gerätebaum noch normal erweitert, beim PDO-Mapping passiert aber gar nichts. Wenn ich dagegen weitere 750-530-Module anhänge geht es beliebig normal weiter und es wird auch entsprechend ein zweites RDPO geöffnet.

    Irgendetwas scheint da mit CoDeSys und dem 750-502 nicht zu stimmen.

     
  • eschwellinger

    eschwellinger - 2019-01-03

    Hi,
    kannst du mal die EDS Files anhängen die du verwendest?
    Würde erst mal eher auf einen Fehler im EDS File tippen ...

    Grüße
    Edwin

     
  • Anonymous - 2019-01-03

    Originally created by: MR_CAN

    Guten Morgen,

    das müsste diese sein (Anhang).

    Viele Grüße,
    Marcel

    750 348m12.zip [17.16 KiB]

     
  • eschwellinger

    eschwellinger - 2019-01-07

    Hallo Marcel,
    was du definitiv machen kannst (also als Workaround)
    "Autoconfig PDO Mapping" ausschalten und dann eben das PDO MAPPING manuell konfigurieren.
    Aktuell ist noch nicht klar ob das am EDS file liegt oder an CODESYS:
    Grüße
    Edwin

     
  • Anonymous - 2019-01-08

    Originally created by: MR_CAN

    Hallo Edwin,

    danke für die Info und den Tipp. Welches Objekt wäre denn das richtige für das 2-Kanal-Ausgangsmodul? In Codesys wird beim Autoconfig immer ein 8bit-Objekt angelegt. Soll das so? (ich weiß, kann am EDS, oder an Codesys liegen Kannst Du schreiben, was ich für das 750-502 manuell eintragen muss?

    Wann ist ungefähr mit einer Fehlerbehebung zu rechnen? Macht es sonst evtl. Sinn, bei WAGO anzufragen, ob deren EDS fehlerhaft ist?

    VG,
    Marcel

     
  • eschwellinger

    eschwellinger - 2019-01-08

    Hallo Marcel,

    also das Mapping ist korrekt.
    Nach EDS erzeugt das Modul 750-530 das Objekt 6200sub1 mit Länge 8 bit.
    Das zweite Modul 750 530 dann das selbe nochmals auf Objekt 6200sub2.
    Das 75x-1425 erzeugt nach EDS dann 2 Subobjekte mit Länge 8bit. Also 6200sub 3 und 4.
    Damit fängt das erste 750 502 Modul bei Subindex 5 an. Laut EDS propagiert ein 750-502 Modul jeweils 2bit in das Subobjekt.
    D.h. bei Objekt 6200 sub5 kommen die ersten 2 Bit vom ersten 750-502 Modul und die nächsten 2 bit vom zweiten.
    Es muss also nur Subindex 5 gemappt werden um beide Module anzusprechen.
    Das Subobjekt hat aber nur Länge 4 bit.
    CODESYS muss aber 8 bit mappen, da im EDS eine Mapping Granularität von 8 bit angegeben ist. D.h. kleinere Mappings sind laut EDS nicht erlaubt.
    Vielleicht ist das aber auch im EDS falsch eingetragen.
    Man könnte mal probieren, Autoconfig im Slave abzuschalten und dann die Mapping Länge im Konfigurator auf 4 bit anzupassen.
    Wenn das dann geht, dann ist das ein Fehler im EDS bzw. in der Slave Firmware.

    Ansonsten könnte auch mal ein CAN Trace helfen oder CAN Debug Compiler Define und Log-Auszug.
    Damit man mal sieht, wo es Probleme in der Konfigurationsphase gibt.
    Also -> compiler define CANOPEN_DEBUG setzen und dann das SPS log posten...

    Grüße
    Edwin

     
  • Anonymous - 2019-02-11

    Originally created by: MR_CAN

    Hallo Edwin,

    ich wollte mal nachfragen, ob es hier schon neue Erkenntnisse gibt, oder ob der Fehler schon genau gefunden und lokalisiert ist.

    Zurzeit kann ich an der Anlage leider keine Tests durchführen, für die ich immer erst die Module umstecken müsste. Ich brauche demnächst aber eine zuverlässig funktionierende Anlage, möglichst ohne solcher Workarounds. Deshalb mal die Frage, ob an diesem Fehler noch bei 3S gearbeitet wird.

    Ich wäre über eine kurze Info sehr dankbar.

    Viele Grüße,
    Marcel

     
  • eschwellinger

    eschwellinger - 2019-02-11

    hm nein.. machen kann ich so nichts ohne das Gerät:

    Zitat:
    "Vielleicht ist das aber auch im EDS falsch eingetragen.
    Man könnte mal probieren, Autoconfig im Slave abzuschalten und dann die Mapping Länge im Konfigurator auf 4 bit anzupassen.
    Wenn das dann geht, dann ist das ein Fehler im EDS bzw. in der Slave Firmware. "

    Zitat:
    Ansonsten könnte auch mal ein CAN Trace helfen oder CAN Debug Compiler Define und Log-Auszug.
    Damit man mal sieht, wo es Probleme in der Konfigurationsphase gibt.
    Also -> compiler define CANOPEN_DEBUG setzen und dann das SPS log posten...

    Grüße
    Edwin

     
  • Anonymous - 2019-02-14

    Originally created by: MR_CAN

    schade, Log im Anhang.

    AutoConfig deaktivieren funktioniert nur bedingt, wenn ich im Gerätestamm die Reihenfolge ändere, ändern sich trotzdem PDO und andere Module verlieren ihre Variablenzuordnungen.

    Ich habe die Anlage jetzt wieder kurz außer Betrieb genommen, um es zu testen, aber auch mit manueller PDO-Anpassung läuft dann nichts.

    Lt. 3S-Gerätekompatibilität ist das 750-502 ganz klar unterstützt, getestet wurde es dann vermutlich aber nicht.

    Vielleicht kann ich noch einen Tipp bekommen, wie genau das Mapping von Hand gesetzt werden muss, damit die Anordnung aus dem Anhang funktioniert.

    Jetzt heißt es erstmal wieder rückbauen, damit die Anlage wieder läuft (ohne den eigentlich benötigten Kanal des 750-502).

    Leider etwas unbefriedigend, da noch nichtmal klar ist, ob der Fehler bei WAGO oder 3S liegt und scheinbar auch keiner weiß, wie er zu beheben ist

    Grüße,
    Marcel

    IMG: modulanordnung.png

    log.xml [59.1 KiB]

     
  • Anonymous - 2019-05-22

    Originally created by: MR_CAN

    Edwin Schwellinger hat geschrieben:
    hm nein.. machen kann ich so nichts ohne das Gerät:

    Hallo Edwin,
    hat der gepostete Log etwas gebracht? Waren Fehler zu erkennen?

    Grüße,
    Marcel

     
  • eschwellinger

    eschwellinger - 2019-05-24

    Hi,

    Da bleibt nur Handbuch und Hersteller.
    Man sieht nur, dass Mapping 16000sub05 abgelehnt wird und der Reset auf Werkseinstellungen mit Sub2 nicht funktioniert.
    In diesem Fall fürchte ich du musst den Wago Support/Klemmenhersteller melden.
    Einen CAN trace hinschicken wäre natürlich optimal.
    Grüße
    Edwin

     

Log in to post a comment.