Para reutilizar a mesma tela gráfica em vários equipamentos no PowerB, não basta duplicar o device ou copiar a PX. Os bindings precisam utilizar ORDs relativas, permitindo que a mesma tela resolva os pontos a partir do componente no qual está sendo utilizada.
Neste tutorial será utilizada como exemplo uma tela de fan coil associada a um device BACnet. O objetivo é relativizar a PX modelo e reutilizá-la em outros equipamentos com a mesma estrutura de pontos.
O comando Duplicate ou uma cópia simples pode duplicar a tela, mas as ORDs absolutas continuam apontando para os componentes utilizados quando a PX foi criada. Antes de replicar o gráfico, revise e relativize seus bindings.
1. Antes de iniciar
Utilize uma tela gráfica já testada e funcionando como modelo para os demais devices.
Os componentes que reutilizarão a mesma PX devem possuir os slots, pastas e nomes utilizados pelas ORDs relativas. Não basta que somente o nome final do ponto seja igual.
É recomendado conhecer a navegação da station, edição de telas gráficas e estrutura dos componentes no PowerB.
2. Por que duplicar a PX não é suficiente
Uma PX criada sobre um equipamento normalmente contém bindings que apontam para caminhos específicos da station. No exemplo deste tutorial, um dos pontos utiliza a seguinte ORD:
station:|slot:/Drivers/BacnetNetwork/MFC1/points/HabilitadoEsse caminho identifica explicitamente o device MFC1. Se o gráfico for simplesmente copiado ou o device for duplicado, o binding pode continuar apontando para o MFC1.
Após a relativização, o mesmo binding pode ficar:
slot:points/HabilitadoNesse caso, o caminho passa a ser resolvido a partir do componente no qual a PX está sendo utilizada. Assim, a mesma tela pode trabalhar com os pontos de MFC1, MFC2 ou outro device compatível.
Se MFC1 e MFC2 possuírem a estrutura points/Habilitado, a ORD slot:points/Habilitado utilizará o ponto do MFC1 quando a PX estiver aplicada ao MFC1 e o ponto do MFC2 quando estiver aplicada ao MFC2.
3. Conferir a tela modelo e os Bound Ords
Abra a PX que será utilizada como modelo e confirme que ela está funcionando corretamente antes da relativização.

No modo de edição da PX, localize a seção Bound Ords. Essa área reúne as ORDs utilizadas pelos bindings do arquivo PX e permite verificar quais referências ainda dependem de caminhos absolutos.

Uma única ORD absoluta esquecida pode fazer a tela parecer correta e, ao mesmo tempo, continuar lendo ou comandando um ponto do equipamento utilizado como modelo.
4. Entender a estrutura relativa do device
No exemplo, o device MFC1 possui uma pasta points que contém os objetos BACnet utilizados pela PX.

A relativização dos bindings utilizados por esta PX resulta em referências como:
slot:slot:points/Habilitadoslot:points/Estado$20Controleslot:points/Modo$20operacao$20$28MV$29slot:points/Temp$20Ambienteslot:points/Setp$20Refr
Alguns caracteres aparecem codificados nos nomes dos slots. Um espaço, por exemplo, pode aparecer como $20. Não remova ou altere essas sequências manualmente sem verificar o caminho resultante.
5. Relativizar as ORDs da PX
Valide os caminhos relativos
Verifique se os caminhos resultantes correspondem à estrutura abaixo do componente que utilizará a PX. Para o exemplo deste tutorial, os pontos devem permanecer abaixo de
points/.Confirme a relativização
Clique em OK para aplicar as alterações.
A partir desse momento, a PX deixa de depender do caminho absoluto do MFC utilizado como modelo e passa a resolver os bindings a partir do componente ao qual a view estiver associada.
6. Validar a PX após a relativização
Antes de reutilizar a tela, abra novamente a PX no device original e valide os principais pontos de leitura e comando.
Confira os valores
Verifique se os valores apresentados continuam correspondendo ao equipamento modelo.
Teste os comandos
Quando aplicável, execute comandos pela tela e confirme que eles atuam nos pontos corretos.
Revise os Bound Ords
Confirme que os bindings que deveriam ser relativos não mantiveram referências explícitas ao device original.
7. Replicar o device e reutilizar a tela
Depois de validar a PX relativizada, o device pode ser duplicado para criar equipamentos equivalentes na station.
O comando Duplicate também copia configurações do equipamento original. Revise parâmetros como Device ID, endereço IP, MAC Address e demais identificadores utilizados pelo driver antes de colocar o novo device em operação. Valores duplicados podem provocar conflitos de comunicação.
Quando a estrutura dos dois devices for compatível, os widgets e Bound Labels da PX passarão a utilizar os pontos do novo equipamento porque os bindings são relativos.
Quando vários componentes utilizam o mesmo arquivo PX, alterações feitas nesse arquivo podem refletir em todos os componentes que o reutilizam. Avalie o impacto antes de alterar uma tela utilizada como modelo comum.
8. Reutilizar a PX em devices que já existem
Não é necessário excluir devices já configurados apenas para utilizar o comando Duplicate. Quando o equipamento já existe na station, é possível associar a PX relativizada diretamente a ele.
Crie uma nova view no device existente
No componente desejado, acesse Views → New View.
Use o mesmo nome da PX relativizada
Em View Name, informe exatamente o nome do arquivo PX que será reutilizado.
9. Quando a estrutura do componente é diferente
A ORD relativa precisa representar a estrutura real abaixo do componente que utiliza a PX. Nem todo equipamento possui uma pasta chamada points.

Se o ponto TempAmbiente estiver diretamente abaixo do componente, a referência relativa poderá ser:
slot:TempAmbienteNesse cenário, utilizar slot:points/TempAmbiente não funcionaria, porque a pasta points não existe nessa posição.
A pasta points é comum em devices de comunicação, mas não é uma regra universal. Sempre confira a árvore real do componente antes de definir ou editar uma ORD relativa.
10. Relativização manual
Também é possível editar manualmente as ORDs seguindo a mesma lógica utilizada pela função Relativize Ords. Esse método é útil quando apenas algumas referências precisam de ajuste ou quando a estrutura exige tratamento específico.

Ao editar ORDs manualmente, teste leitura e comando de cada binding alterado. Um caminho incorreto pode apontar para outro componente ou simplesmente não resolver.
11. Validar a tela replicada
Após aplicar a PX em outro equipamento, valide o funcionamento antes de considerar a replicação concluída.
A PX original continua funcionando; a tela aplicada ao novo device apresenta os valores desse equipamento; os comandos atuam no device correto; os Bound Ords não mantêm referências indevidas ao equipamento modelo; e a comunicação do device duplicado foi revisada e configurada com identificadores próprios.
12. Se os bindings não apontarem para o device correto
| Comportamento | O que verificar |
|---|---|
| A tela do novo device mostra valores do equipamento modelo. | Revise os Bound Ords e procure referências absolutas que ainda contenham o nome ou caminho do device original. |
| Alguns widgets funcionam e outros não. | Confira individualmente os bindings e valide se todos os caminhos relativos existem no novo componente. |
| Um widget apresenta erro ou não resolve. | Compare a estrutura do novo componente com a estrutura utilizada pela ORD relativa. |
slot:points/... não funciona. | Confirme se existe uma pasta ou slot points abaixo do componente que utiliza a PX. |
| Um comando atua no equipamento errado. | Interrompa o teste e revise imediatamente o binding do widget; ele pode ainda apontar para uma ORD absoluta. |
| O device duplicado não comunica corretamente. | Revise Device ID, endereço IP, MAC Address e demais parâmetros específicos do driver. |
| O device já existe e não deve ser duplicado. | Associe a PX com Views → New View e utilize Reuse. |
13. Alternativa avançada: Tag-Based Px Bindings e NEQL
A relativização por slots é indicada quando os equipamentos seguem estruturas padronizadas. A partir do Niagara 4.9, o Niagara também oferece Tag-Based Px Bindings, que podem utilizar consultas NEQL para localizar componentes por tags e relações.
O Px Editor disponibiliza a função Neqlize Ords para converter bindings baseados em caminhos de slots em bindings baseados em NEQL. Essa abordagem pode ser especialmente útil quando equipamentos equivalentes possuem nomes ou estruturas diferentes, mas estão corretamente modelados por tags e relações.
Tag-Based Px Bindings e NEQL são apresentados aqui apenas como alternativa avançada. O procedimento principal deste tutorial utiliza a relativização tradicional, adequada ao cenário de devices com estrutura equivalente.
Ainda precisa de ajuda?
Entre em contato com o suporte técnico da Mercato. Para agilizar o atendimento, informe o equipamento, produto ou sistema relacionado e descreva brevemente a dúvida ou o problema encontrado.
Falar com o suporte no WhatsApp →

