FB_EL6851CommunicationEx

Der Zugriff auf die EL6851 sollte immer über diesen Baustein erfolgen. Dieses betrifft sowohl das Versenden der zyklischen DMX-Daten, als auch das Versenden der RDM-Befehle.

Sollen Daten zyklisch zu den DMX-Geräten versendet werden, so setzen sie den Eingang bEnableSendingData auf TRUE, den Eingang bSetCycleMode auf TRUE, den Eingang bSendDefaultData auf FALSE und den Eingang uiDataLength auf die entsprechende Länge (jn Byte). Die Daten, die versendet werden sollen, können über die Variable arrProcessData vorgegeben werden.

Sollen RDM-Befehle versendet werden, so setzen sie den Eingang bEnableSendingData auf FALSE und den Eingang bSetCycleMode auf FALSE. Die Bausteine für die DMX-RDM-Befehle greifen nicht direkt auf das Prozessabbild der EL6851 zu, sondern legen die einzelnen DMX-RDM-Befehle in einen Puffer ab. Der Baustein FB_EL6851CommunicationEx() liest sequentiell die Befehle aus diesen Puffer aus und gibt diese zu der EL6851 weiter. Hierdurch wird sichergestellt, dass nicht mehrere Bausteine gleichzeitig auf das Prozessabbild der EL6851 zugreifen. Der Puffer, in dem die DMX-RDM-Befehle abgelegt werden, ist in einer Variablen vom Typ ST_DMXCommandBuffer enthalten. Pro EL6851 gibt es eine Instanz vom Baustein FB_EL6851CommunicationEx() und eine Variable vom Typ ST_DMXCommandBuffer.

Über die Ausgänge des Bausteins kann ermittelt werden, wie stark der Puffer ausgelastet ist. Sollten Sie feststellen, dass der Puffer regelmäßig überläuft, so sollten mit Hilfe des TwinCAT System Managers die Auslastung der SPS-Task analysieren.

Der Baustein FB_EL6851CommunicationEx() kann, wenn nötig in einer separaten, schnelleren Task aufgerufen werden. In diesem Fall sollte die schnellere Task, in der der Baustein FB_EL6851CommunicationEx() aufgerufen wird, eine höhere Priorität haben, als die TASK, in der die Bausteine für die RDM-Befehle aufgerufen werden.

Zu beiden Betriebsarten finden sie auch entsprechende Beispiele im Anhang.

Anmerkung zu den IDs von DMX-Geräten

Jedes DMX-Gerät hat eine eindeutige, feste, 48-Bit lange Adresse, auch Unique ID oder kurz UID genannt. Diese Adresse besteht aus der Manufacturer ID (16 Bit) und der Device ID (32 Bit). Die Manufacturer ID identifiziert den Hersteller des Gerätes und wird von der ESTA (Entertainment Services and Technology Association) vergeben. Eine Liste mit allen bekannten Manufacturer IDs ist zu finden unter http://www.esta.org/tsp/working_groups/CP/mfctrIDs.php. Die Device ID wird frei vom Hersteller festgelegt. Hierdurch soll sichergestellt werden, dass jede UID weltweit einmalig vorhanden ist. Die UID kann in der Regel nicht verändert werden. Von der ESTA wurde Beckhoff Automation die Hersteller ID 0x4241 zugeordnet. Da auch ein DMX-Master eine UID besitzt, sollte diese entsprechend der ESTA angegeben werden (Eingang wSourceManufacturerId).

Eingänge

VAR_INPUT
  wSourceManufacturerId : WORD := 16#42_41;
  dwSourceDeviceId      : DWORD := 16#12_13_14_15;
  bEnableSendingData    : BOOL := TRUE;
  bSetCycleMode         : BOOL := TRUE;
  bSendDefaultData      : BOOL;
  uiDataLength          : UINT;
  dwOptions             : DWORD;
END_VAR

Name	Typ	Beschreibung
wSourceManufacturerId	WORD	Eindeutige Hersteller-Id vom DMX-Gerät. Sollte gemäß der ESTA 0x4241 sein.
dwSourceDeviceId	DWORD	Eindeutige Geräte-Id vom DMX-Gerät. Kann frei vergeben werden.
bEnableSendingData	BOOL	Ist die Klemme im CycleMode (Ausgang CycleMode = TRUE), so kann das Versenden mit diesem Baustein aktiviert (TRUE) oder gesperrt (FALSE) werden.
bSetCycleMode	BOOL	Aktiviert den CycleMode. Im CycleMode können die zyklischen Prozessdaten an die DMX-Geräte versendet werden. Zum Versenden der RDM-DMX-Befehle muss der CycleMode deaktiviert werden.
bSendDefaultData	BOOL	Ist dieser Eingang aktiv (TRUE), so werden im CycleMode die Standardwerte versendet.
uiDataLength	UINT	Dieser Eingang ist nur relevant, wenn der CycleMode aktiv ist. Er gibt die Länge des DMX512-Frames in Bytes an.
dwOptions	DWORD	Optionen (wird derzeit nicht benutzt).

Voraussetzungen

Entwicklungsumgebung	erforderliche TC3 SPS-Bibliothek
TwinCAT ab v3.1.4020.14	Tc2_DMX ab v3.5.3.0

Ein-/Ausgänge

VAR_IN_OUT
  stEL6851InData  : ST_EL6851InData;
  stEL6851OutData : ST_EL6851OutData;
  stCommandBuffer : ST_DMXCommandBuffer;
  arrProcessData  : ARRAY [1..512] OF BYTE;
END_VAR

Name	Typ	Beschreibung
stEL6851InData	ST_EL6851InData	Struktur im Eingangsprozessabbild der EL6851. Sie dient zur Kommunikation von der EL6851 zur SPS.
stEL6851OutData	ST_EL6851OutData	Struktur im Ausgangsprozessabbild der EL6851. Sie dient zur Kommunikation von der SPS zur EL6851.
stCommandBuffer	ST_DMXCommandBuffer	Verweis auf die Struktur zur Kommunikation (Puffer) mit dem Baustein FB_EL6851Communication()
arrProcessData	ARRAY OF BYTE	Über diese Variable werden dem Baustein die Daten übergeben, die zyklisch an die DMX-Geräte versendet werden sollen. Hierzu muss der CycleMode aktiv sein (siehe auch Eingang bSetCycleMode).

Ausgänge

VAR_OUTPUT
  bError                     : BOOL;
  udiErrorId                 : UDINT;
  bCycleMode                 : BOOL;
  byBufferDemandMeter        : BYTE;
  byBufferMaximumDemandMeter : BYTE;
  uiBufferOverflowCounter    : UINT;
  bLineIsBusy                : BOOL;
END_VAR

Name	Typ	Beschreibung
bError	BOOL	Dieser Ausgang wird auf TRUE geschaltet, wenn bei der Ausführung eines Befehls ein Fehler aufgetreten ist. Der befehlsspezifische Fehlercode ist in udiErrorId enthalten. Nur gültig, wenn bBusy auf FALSE ist.
udiErrorId	UDINT	Enthält den befehlsspezifischen Fehlercode des zuletzt ausgeführten Befehls. Nur gültig, wenn bBusy auf FALSE ist (siehe Fehlercodes).
bCycleMode	BOOL	Ist auf TRUE, wenn der CycleMode aktiv ist (siehe auch Eingang bSetCycleMode).
byBufferDemandMeter	BYTE	Belegung des jeweiligen Puffers (0 - 100%).
byBufferMaximumDemandMeter	BYTE	Bisherige maximale Auslastung des jeweiligen Puffers (0 - 100%).
uiBufferOverflowCounter	UINT	Bisherige Anzahl der Pufferüberläufe.
bLineIsBusy	BOOL	Solange der Baustein FB_EL6851Communication() DMX-RDM-Befehle bearbeitet, ist dieser Ausgang gesetzt.