M2100控制协议详解：GrassValley设备自动化接口指南

M2100

控制协议

需积分: 10 109 浏览量更新于2024-07-28 收藏 765KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

M-2100 Automation Interface Protocol Manual 13

Automation Determinacy Constant Considerations

All messages sent as commands are considered to be deterministic (their

execution must occur a guaranteed time after the M–2100's receipt of the

command) and they must be sent with certain considerations. Queries are

executed as soon as they are received and are not considered deterministic.

Some automation commands can be sent as a command or as a query. Com-

mands and queries have been summarized in Table 5 on page 30 which

lists each command and their possible state.

Deterministic commands always require a certain amount of time to

execute on the M–2100 before the next command or query is received. The

time allowed for execution of commands is called the Automation Deter-

minacy Constant. It can be set by the user in the Automation Control

section of the General Parameters form in the M–2100 Conﬁguration

Manager application or using the VxShell command autoDeterCfgSee at

the FCM Console port. It is set to a minimal default value of 2 ﬁelds.

To guarantee enough time for the execution of a deterministic command to

complete, commands must be received by the M–2100 no later than 13 mil-

liseconds into the ﬁeld. All commands will be performed 2 ﬁelds after they

are received, unless the Automation Determinacy Constant has been set to

a different value. As stated above, queries are executed immediately and

are not affected by the Automation Determinacy Constant.

When multiple commands are sent from an automation system, there must

be a gap of at least 1.3 milliseconds between the end of one automation

message and the start of the next message. If this minimum duration is not

observed, the M-2100 may assume that the two messages are part of a

single message and they may not be executed properly.

Automation commands of the same type that are sent in sequence must be

also separated by enough time to allow their complete execution. It is con-

sidered an error for an automation system to send an automation

command before execution of a previously sent command of the same type

has been completed. For example, if a TX_NEXT command is sent, the

automation system must wait until that command has completely executed

before sending another TX_NEXT command.

Commands with special considerations are summarized below.

XPT_TAKE and BREAK_AWAY Commands

The XPT_TAKE and BREAK_AWAY commands cut the indicated cross-

points on the designated buses. These hard cuts occur immediately upon

expiration of the Automation Determinacy Constant interval.

14 M-2100 Automation Interface Protocol Manual

Section 1 — Automation Message Protocol

TX_START Command

There is another consideration for the TX_START command. It is recom-

mended that the audio component not be a hard cut as a normal practice.

The purely digital switch of the M–2100 will be clean, but the possibly dra-

matic change in audio energy is likely to cause artifacts such as pops and

thumps in the analog audio processing that may follow.

Therefore, any audio take transition is automatically changed to a Fade for

the audio component. A Take transition is upgraded to a Fade-Fade for

audio (but the video and key components, if any, remain as Takes). A Take-

Fade transition is similarly upgraded to an asymmetrical Fade-Fade, again

for the audio component only.

If a transition contains an audio component that is transitioned using a

Fade-Fade transition type, and a video and/or key component is transi-

tioned using a Take transition type, it is necessary to delay the Take to occur

at the minimum point (bottom) of the fade. Thus the switching of the video

and key components of a transition will be delayed if there is an audio com-

ponent in a transition.

This is an intolerable situation for the deterministic TX_START command.

To correct this situation, an additional delay constant, referred to as the

Transition Delay Constant, was introduced. As depicted in Figure 1, this

Transition Delay Constant is the guaranteed additional delay, after the

expiration of the Automation Determinacy Constant, to the point where the

new video/audio/key signals ﬁrst appear on the program bus.

During this Transition Delay Constant, an audio component, if present, will

be fading down, At the end of the Transition Delay Constant, the video and

key cuts will occur (assuming a Take transition type) and the audio will be

at the bottom of the fade, beginning the fade up to the new source.

The Transition Delay Constant operates for all transition types and all

source components. The normal value of this constant is 6 ﬁelds, and is

ﬁxed for all ﬁeld rates. The Transition Delay Constant must always be equal

or greater than the Audio Fade Rate for a Cut, which is normally 100 ms (6

ﬁelds in 525 line rate, 5 ﬁelds in 625 line rate).

The Transition Delay Constant can be set using the VxShell command

transDelayConsCfgSee

and is not accessible via the Conﬁguration

Manager.

The Audio Fade Rate for a Cut Constant can be set using the VxShell

command

cutAudioRateCfgSee ()

and is expressed as milliseconds. It

is not accessible via the Conﬁguration Manager.

This audio cut rate value can be set to any value desired but will only apply

to a Take transition. All other transition types (fade-fade, take-fade, fade-

take) are set to a default value of 100 mS.

剩余77页未读，继续阅读

DVB_SING1

粉丝: 0
资源: 4

M2100控制协议详解：GrassValley设备自动化接口指南

VUM9000X02读写控制协议

M1553B通信协议官方介绍

LWM2M协议报文解析

3.4m i2c协议 文档

请帮我写在RX72M上实现canopen协议栈的代码

单片机控制m62429 c 驱动程序

M62429可以一边与单片机通讯过程中，一边输出控制声音吗

ch582m控制ws2812c代码

pid控制大疆电机m3508

stm32 bacnet协议

m2m 1.0 加密封包分析工具

stm32 lwm2m

台达vfd-m485通讯

p_sequencer和m_sequencerde的区别

举具体例子 SWD协议

两台施耐德m218之间 ethernet 通讯

dmx512协议 stm32

rs485 协议基本逻辑

canopen协议栈 stm32

最新资源

3.4m i2c协议文档