Bitweise Mapping eines StatusWord (Antrieb)

[clumsi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin!

Ich arbeite mich gerade ein wenig in TwinCAT 3 ein.

Wenn ich das Variablenmapping für einfache digitale EtherCAT-Klemmen machen möchte, kann ich jedem Ein-/Ausgangskanal eine BOOL-Variable aus meinem PLC-Programm zuordnen.

Nun habe ich einen CANopen-Antrieb an eine EL6751 (CANopen Master) angefügt und möchte das Status-/Controlword mappen. Geht das nur als Ganzes, oder kann ich auch hier schon die einzelnen Bits des Status-/Controlwords entsprechenden BOOL-Variablen meines PLC-Programmes zuordnen?
Wie geht man am besten vor, um die Bits eines Status-/Controlwords ("Ready to switch on", "switched on", ....) zu mappen, und nicht nur das gesamte Status-/Controlwords als PLC-Variable vorliegen zu haben?

Viele Grüße und einen schönen Sonntag!

 

[StructuredTrash]

Auf der Mapping-Seite würde ich es beim WORD belassen. Die Daten müssen ja zyklisch vom I/O-Abbild ins PLC-Abbild kopiert werden, und das geht mit einem WORD deutlich schneller als mit 16 Bits. Bei TC3 kann man so was elegant mit UNIONs im PLC-Programm lösen, z. B. so:

TYPE uniDSStatWord :    // DS402 drive status word
UNION
    Flag:WORD;    // As flag word
    Bits:strDSStatWord;    // As bits
END_UNION

TYPE strDSStatWord :    // DS402 drive status word bits
STRUCT
    VoltEnbl:BIT;    // 00 - Voltage enabled
    AmplEnbl:BIT;    // 01 - Amplifier enabled
    DrivEnbl:BIT;    // 02 - Drive enabled
    FailActv:BIT;    // 03 - Failure active
    VoltPres:BIT;    // 04 - Voltage present
    NotQStop:BIT;    // 05 - Not quick stop
    OprtDisb:BIT;    // 06 - Operation disabled
    WarnActv:BIT;    // 07 - Warning active
    Bit08:BIT;    // 08 -
    Bit09:BIT;    // 09 - 
    TargRchd:BIT;    // 10 - Target reached
    LimtActv:BIT;    // 11 - Limit active
    ComdAckn:BIT;    // 12 - Command acknowledge (Homing attained, PP set point accepted, PV drive stopped)
    ComdFail:BIT;    // 13 - Command failure (Homing not finished, PP position following error, PV velocity following error)
    DrivStop:BIT;    // 14 - Drive stopped
    Bit15:BIT;    // 15 - 
END_STRUCT

Für das Mapping nimmst Du das WORD, im PLC-Programm kannst Du dann auf die einzelnen Bits zugreifen, und sie werden im Online-Modus auch einzeln angezeigt.
PS: Nicht durch die Namen verwirren lassen. Ich finde die DS402-Bezeichnungen z. T. nicht ganz zutreffend und verwende deshalb eigene.

 

[clumsi]

Zuviel Werbung?
-> Hier kostenlos registrieren

super, danke für den Tipp! Werde ich mal ausprobieren.

Hat mich nur gewundert, dass ich in CoDeSys wahlweise entweder das gesamte Steuerwort mappen kann, oder auch die einzelnen Bits. Bei TwinCAT scheint es diese Option gar nicht erst zu geben.

 

[StructuredTrash]

Das ist der Punkt, an dem sich die Wege der beiden trennen. Beckhoff kauft das Laufzeitsystem nicht bei 3S ein, sondern hat ein eigenes.

 

[oliver.tonn]

Das ist der Punkt, an dem sich die Wege der beiden trennen. Beckhoff kauft das Laufzeitsystem nicht bei 3S ein, sondern hat ein eigenes.

Woher hast Du diese Info? Das sie das Laufzeitsystem stark anpassen würde ich unterschreiben, aber ein eigenes?

Von irgendwas mit Internetzugang gesendet.

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wurde mir mal von einem Beckhoff-Vertriebler so erklärt. Glaube ich auch, denn sonst würde die Trennung zwischen Codesys-Entwicklungsumgebung und Beckhoff-Systemmanger doch keinen Sinn machen.

 

[oliver.tonn]

Glaube ich auch, denn sonst würde die Trennung zwischen Codesys-Entwicklungsumgebung und Beckhoff-Systemmanger doch keinen Sinn machen.

Bei V2 machte das schon Sinn, für verschiedene Schnittstellen musste man da verschiedene Konfiguratoren einsetzen, z.B. SYCON.net von Hilscher, weil diese nicht wie bei V3 über Plugins integriert waren. Beckhoff hatte das aber schon damals alles in ein Programm gepackt.

Von irgendwas mit Internetzugang gesendet.

 

[StructuredTrash]

Trotzdem denke ich, dass es eine Eigenentwicklung ist. Schliesslich hatte Beckhoff so ein System bereits vor TwinCat. Warum hätte man das wegwerfen sollen?

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Trotzdem denke ich, dass es eine Eigenentwicklung ist. Schliesslich hatte Beckhoff so ein System bereits vor TwinCat. Warum hätte man das wegwerfen sollen?

Ich erinnere mich an ein DOS-System für Lightbus-Koppler, aber auch da kam einiges von 3S.

Von irgendwas mit Internetzugang gesendet.

 

[StructuredTrash]

Die S1000/S2000 sind, so weit ich weiss, Beckhoff-Eigenentwicklungen. Aber wie auch immer, für den Anwender stellt sich das Beckhoff-System doch deutlich anders dar als andere Codesys-basierende Steuerungen (wobei Du das vermutlich besser beurteilen kannst, ich kenne mich ausserhalb der Beckhoff-Welt nicht so gut aus).

Um zum Thema zurückzukommen:
Die Kombination Beckhoff-Steuerung mit kompletter I/O-Ausrüstung von Fremdherstellern ist für meinen Geschmack auch nur auf Basis von EtherCat sinnvoll, auf ältere Feldbussysteme sollte man da lieber verzichten. Ich verwende die EL6751 auch nur noch, weil ich noch auf Jahre hinaus mit äteren Geräten leben muss, die nur CanOpen können.

 

[Guga]

Noch meine 2 cents zum off topic Thema.
in TwinCAT kommt von 3S der Compiler der das Binärgebilde erstellt als auch die Komponente die den Code ausführt/rechnet.
Die Echtzeit und wann die Komponentenaufgerufen wird bzw. wo es physikalisch läuft (z.B. isolierter Kern) ist von Beckhoff. Gerade bei isolierten Kernen wird es deutlich - das hatte Beckhoff früher im Portfolio als 3S.
Zu CoDeSys 2 Zeiten also eindeutig: Alles um das PLC Control hat einen Bezug zu 3S, der SystemManager ist aber Beckhoff.

Guga