Endereçamento Dali Light: Como?
Como estou tentando criar um programa que aborda as várias luminárias, eu queria saber melhor, teoricamente, não os comandos a dar, mas por que estou dando aquele comando específico .
Eu procurei por um longo tempo para encontrar também exemplos sobre Dali2 endereçando comandos de luz.
Então eu encontrei um artigo que me dizia que eu tinha que digitar algum tipo de comando duas vezes, para que Dali pudesse entendê-los.
Isto é o que li:
De acordo com a IEC 60929, um DALI Master deve repetir vários comandos dentro de 100ms, para que os DALI-Slaves os executem.
Minhas perguntas para você são estas:
- Que comandos preciso repetir em meu programa para ser eficaz?
- Qual ordem de comandos devo respeitar?
- Seria melhor se eu usasse o tipo de processo de autômato de estado ou buffer?
- Por que devo repetir os comandos?
Estou usando o microprocessador Stm32, então meu código deve ser o mais leve e eficiente possível.
Respostas
Os comandos de configuração devem ser repetidos duas vezes em 100ms sem qualquer outro comando intermediário antes que o reator os aceite. Isso é feito como uma forma de evitar a corrupção do sinal ou mensagens espúrias alterando acidentalmente uma configuração. Os quadros DALI são codificados em Manchester, o que evita que um único bit do quadro cause uma interpretação problemática, mas não tem um CRC, que é uma forma comum de detecção de erro na comunicação serial. Portanto, é útil ter outro método para garantir que o comando pretendido foi recebido.
A lista dos comandos que devem ser repetidos é fornecida em qualquer documentação que você tenha sobre DALI, incluindo o agora substituído IEC 60929, onde afirma que os comandos 32-128 devem ser repetidos e alguns dos comandos especiais como Inicializar e Randomizar. O novo padrão é IEC62386 e há uma tabela (Tabela 15 em IEC62386-102 Ed 2) que mostra quais comandos devem ser repetidos; a coluna é chamada "Enviar duas vezes".
A ordem dos comandos depende da lógica da sua aplicação e das regras para mensagens DALI fornecidas na norma. Por exemplo, para definir um parâmetro de configuração, ele deve primeiro ser transferido usando o registrador de transferência de dados DTR (ou DTR1, DTR2) e, em seguida, armazenado - fazer isso na ordem oposta não faz sentido. Por exemplo, para definir o nível máximo, o comando é 42, opcode byte 0x2A e usa DTR0, então o conjunto de comandos é
Command 257, SET DTR0 [with whatever value you want as a byte]
-any delay you like here-
Command 42, SET MAX LEVEL (DTR0) [addressed to the gear as necessary]
-less than 100ms delay-
Command 42, SET MAX LEVEL (DTR0) [addressed to the gear as necessary]
O comando 257 SET DTR0 não é endereçado, portanto, será aplicado a todas as engrenagens conectadas ao barramento e energizadas. Se você deseja que SET MAX LEVEL seja aplicado a apenas uma engrenagem endereçada curta, ou um endereço de grupo, ou broadcast, isso afeta o byte de endereço que você precisa definir no Comando 42 SET MAX LEVEL. Somente as engrenagens que correspondem a esse endereço usarão o DTR para definir seu próprio parâmetro MAX LEVEL.
A repetição dos comandos de configuração não faz nada para garantir que o valor DTR esteja correto na engrenagem. Se você tiver uma engrenagem que foi endereçada por curto, ou apenas uma engrenagem no barramento, então você pode ler o DTR antes ou depois de executar o comando SET para garantir que estava no valor correto. (Em geral, você não pode reler os valores com consultas de transmissão ou grupo por causa de colisões entre vários equipamentos de controle. A menos que você esteja usando consultas específicas de tipo de dispositivo e tenha apenas um único exemplo disso no barramento).