FB_EL6851Communication
 | Dieser Baustein ist veraltet. Nutzen Sie stattdessen den 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_EL6851Communication() 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_EL6851Communication() 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_EL6851Communication() kann, wenn nötig in einer separaten, schnelleren Task aufgerufen werden. In diesem Fall sollte die schnellere Task, in der der Baustein FB_EL6851Communication() 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 Hersteller-Id (16 Bit) und der Geräte-Id (32 Bit). Die Hersteller-Id identifiziert den Hersteller des Gerätes und wird von der ESTA (Entertainment Services and Technology Association) vergeben. Eine Liste mit allen bekannten Hersteller-Ids ist zu finden unter http://www.esta.org/tsp/working_groups/CP/mfctrIDs.php. Die Geräte-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). |
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;
wSourceManufacturerId: Eindeutige Hersteller-Id vom DMX-Gerät. Sollte gemäß der ESTA 0x4241 sein.
dwSourceDeviceId: Eindeutige Geräte-Id vom DMX-Gerät. Kann frei vergeben werden.
bEnableSendingData: Ist die Klemme im Cycle-Mode (Ausgang bCycleMode = TRUE), so kann das Versenden mit diesem Baustein aktiviert (TRUE) oder gesperrt (FALSE) werden..
bSetCycleMode: Aktiviert den Cycle-Mode. Im Cycle-Mode können die zyklischen Prozessdaten an die DMX-Geräte versendet werden. Zum Versenden der RDM-DMX-Befehle muss der Cycle-Mode deaktiviert werden..
bSendDefaultData: Ist dieser Eingang aktive (TRUE), so werden im Cycle-Mode die Standardwerte versendet.
uiDataLength: Dieser Eingang ist nur relevant, wenn der Cycle-Mode aktiv ist. Er gibt die Länge des DMX512-Frames in Bytes an.
dwOptions: Optionen (wird derzeit nicht benutzt).
VAR_OUTPUT
bError : BOOL;
udiErrorId : UDINT;
bCycleMode : BOOL;
byBufferDemandMeter : BYTE;
byBufferMaximumDemandMeter : BYTE;
uiBufferOverflowCounter : UINT;
bLineIsBusy : BOOL;
bError: 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: Enthält den befehlsspezifischen Fehlercode des zuletzt ausgeführten Befehls. Nur gültig, wenn bBusy auf FALSE ist. Siehe Fehlercodes.
bCycleMode: Ist auf TRUE, wenn der Cycle-Mode aktiv ist (siehe auch Eingang bSetCycleMode).
byBufferDemandMeter: Belegung des jeweiligen Puffers (0 - 100%).
byBufferMaximumDemandMeter: Bisherige maximale Auslastung des jeweiligen Puffers (0 - 100%).
uiBufferOverflowCounter: Bisherige Anzahl der Pufferüberläufe.
bLineIsBusy: Solange der Baustein FB_EL6851Communication() DMX-RDM-Befehle bearbeitet, ist dieser Ausgang gesetzt.
VAR_IN_OUT
stEL6851InData : ST_EL6851InData;
stEL6851OutData : ST_EL6851OutData;
stCommandBuffer : ST_DMXCommandBuffer;
arrProcessData : ARRAY[1..512] OF BYTE;
stEL6851InData: Struktur im Eingangsprozessabbild der EL6851. Sie dient zur Kommunikation von der EL6851 zur SPS.
stEL6851OutData: Struktur im Ausgangsprozessabbild der EL6851. Sie dient zur Kommunikation von der SPS zur EL6851.
stCommandBuffer: Verweis auf die Struktur zur Kommunikation (Puffer) mit dem FB_EL6851Communication()-Baustein.
arrProcessData: Ü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).