- Este tópico tem 9 respostas, 3 participantes e foi atualizado pela última vez 10 anos, 12 meses atrás da
.
-
Publique
-
Eu comprei alguns módulos distribuídos Trycom I / O, eu queria usá-los para construir um sistema de automação residencial. Na prática, eu gostaria de conectar os switches às entradas digitais 16 do módulo TRPC26, enquanto que para as saídas 16 do módulo TRPC24 eu gostaria de conectar as saídas de controle do usuário (lâmpadas, aparelhos, etc.).
Estava pensando em usar o seu módulo de CPU SLine para o gerenciamento lógico da planta, é possível gerenciar esses módulos de E / S distribuídos via protocolo Modbus a partir de sua CPU?
o módulo TRPC26 use o comando modbus 01 Read Coil Status para ler o estado das 16 entradas digitais, enquanto o módulo TRPC24 use o comando modbus 15 Force Multiple Coils para escrever saídas digitais 16. Usando o bloco de função ModbusRTUMaster (Extracto manual), é possível ler as entradas do módulo TRPC26 e gravar as saídas no módulo TRPC24.
Criei um programa no SLine que lê ciclicamente as 16 entradas do módulo de entrada e as suporta em 16 variáveis BOOL (TRPC26Input [0..15]), copia 16 variáveis BOOL (TRPC24Output [0..15]) no 16 saídas lógicas do módulo de saída. Os dois módulos foram conectados à rede RS485, é necessário definir o endereço 0x01 (padrão) para o módulo de entrada lógica, o endereço 0x02 para o módulo de saída lógica, ver postar.
No programa, você encontrará um programa de escada Lógica, que coloca a entrada DI0 dos módulos de entrada na saída DO0 do módulo de saída. Você pode adicionar toda a lógica de que precisa adicionando linhas a este arquivo e / ou adicionando outros programas ao projeto.
O programa TRPComm realiza leitura cíclica e escrita de módulos I / O, programas InputRead e OuputWrite, eles trocam os bits de leitura e gravação nos módulos TRP para que as variáveis BOOL sejam ordenadas de acordo com as E / S no módulo. Programa de impressão, download do programa.
Sendo um sistema de automação residencial, eu recomendo você nos arquivos InputRead ed OutputWrite para renomear as variáveis de suporte de E / S distribuídas usando nomes que são mnemônicos para o seu sistema.
Para as entradas TRPC26Input [0] pode se tornar PlsLuceSalone, TRPC26Input [1] pode se tornar PlsLuceCucinaetc.
Para saídas TRPC24Output [0] pode se tornar CdoLuceSalone, TRPC24Output [1] pode se tornar CdoLuceCucinaetc.Peço esclarecimentos sobre o exemplo IOOverTRP que testou com sucesso em diferentes fabricantes de modbus IO.
Atualmente, estou realizando testes de comunicação com um Siemens S7-200 usado como escravo modbus do SlimLine. A única mudança que fiz para poder ler o escravo modbus mencionado foi definir FCode= 16 # 03 e defina o parâmetro Endereço de forma apropriada.
Eu encontrei a situação que pode ser deduzida do descobriristo é, a matriz TRPC26Read não é avaliado corretamente. De fato, da janela Assistir apenas o bit menos significativo da matriz é corretamente avaliado enquanto a tela% MW100.0 mostra que a comunicação é bem-sucedida.
Precisamos entender a diferença entre FCode 16 01 # (Leia o estado da bobina) e 16 03 # (Registo de retenção de leitura).
O comando 16 01 # lê o status de contatos lógicos, ou seja, variáveis booleanas, em seguida, lê 16 variáveis Pontos = 16, como no meu programa TRPCom, os 16 valores BOOL consecutivos da matriz são avaliados TRPC26Read.
O comando 16 03 # executa a leitura das palavras (bits 16) da memória, depois lendo a variável 1 Pontos = 1 como no seu exemplo, apenas uma variável USINT do programa é avaliada. Como você pode ver % MW100.0 é avaliado com o valor 16 # 0005 que é o valor presente no PLC Siemens.
Se o seu problema é dividir uma variável USINT em 16 variáveis BOOL, você pode usar blocos de função WordToByte e ByteToBit (Extracto manual).
Eu adiciono uma dica que pode ser útil para entender o endereçamento de sistemas SlimLine. SlimLine é baseado em um processador ARM que usa armazenamento de dados no little-endian, começa com o byte menos significativo e termina com o mais significativo.
Então, como você pode ver no exemplo la % MW100.0 é avaliado com o valor 16 # 0005, portanto, no local com deslocamento 0 da matriz TRPC26Read alocado ao mesmo endereço de% MW100.0 corresponde LSB do valor da palavra, enquanto que o local com deslocamento 1 corresponde ao MSB.
Visto que o valor da palavra 16 é # 0005, seu LSB será diferente de zero, ou seja, TRUE, enquanto seu MSB será igual ou FALSE. Se o valor da palavra fosse 16 # 0101, teríamos MSB e LSB com valor TRUE.
Eu queria esclarecimentos sobre a codificação usada pelo SlimLine para dados reais. Na prática, tenho de tratar como um número de ponto flutuante real (32bit) adquirido via MODBUS-RTU de um S7-200 plc FCode= 16 # 03 e Points= 2.
No manual do LogicLab, a única especificação referente ao tipo real é que ele tem a faixa -3.4E38 - + 3.4E38, enquanto o formato usado pelo S7-200 é "REAL 32 bits IEEE número de ponto flutuante de 32 bits de + 1,175495E- 38 a + 3,402823E + 38 de -1,175495E-38 a -3,402823E + 38 "
Eu esperava que a codificação fosse idêntica, mas não consigo memorizar o valor adquirido em uma variável REAL, screenshots, Espero que os testes realizados sejam claros.
O formato usado para variáveis REAL é IEEE 754, conforme mencionado em questo pós, suas imagens mostram que é o mesmo formato usado pelo S7-200. Na verdade, neste formato de representação, o valor REAL 2.0 está em hexadecimal 16 # 40000000 (como você pode ver na janela de depuração em S7-200).
Aviso! Ao ler variáveis de 32 bits via modbus, deve-se prestar atenção ao endianness dos dados, de fato o protocolo modbus não especifica em que ordem as duas partes de 16 bits dos dados de 32 bits devem ser retornadas. Portanto, é possível que em alguns sistemas a parte mais significativa seja retornada antes da parte menos significativa ou vice-versa.
Su SlimLine como já mencionado em outros posts o little-endian que começa com o byte menos significativo e termina com o mais significativo, e pelo que vejo é o mesmo tipo de representação que a Siemens usa no S7-200 (provavelmente usa um processador ARM). Na verdade, se você notar no% MW100.16 que é o primeiro registro lido pelo modbus você encontrará a parte menos significativa do número e no% MW100.18 a parte mais significativa.
Portanto, o seu erro está apenas na reversão das palavras na conversão WordToDouble.
Acrescento uma dica, já que o formato de representação do S7-200 é o mesmo do SlimLine, para ter o valor em REAL basta definir uma variável REAL em DB100.16 onde o modbus FB suporta os registros lidos pelo S7-200 para poder usá-lo em seu programa sem ter que usar o WordToDouble.
MyVariable AT% MD100.16: REAL; {DE: "Variável REAL lida por S7-200"}
Sim, claro que a solução que você propôs é viável, em questo pós você pode encontrar um exemplo de como gerenciar a partir de SlimLine Módulos de E / S distribuídos via Modbus. Depois que os módulos forem adquiridos, você suportará E / S nas variáveis de memória do SlimLine acessível a partir do Modbus. O PC pode ser conectado em Ethernet e o status das entradas adquirido via modbus TCP, usando por exemplo um software SCADA (Ver publicação), um aplicativo desenvolvido com ProfilabExpert (Ver publicação) ou um aplicativo desenvolvido ad hoc com a linguagem de programação que você conhece. Se o desenvolvimento do protocolo modbus TCP for muito complexo, você pode desenvolver um protocolo de comunicação adaptado às suas necessidades (Ver publicação) Se você só precisa ver o status dos sinos, como alternativa ao PC, recomendo usar um painel do operador tela sensível ao toque que já possui gerenciamento nativo do protocolo modbus TCP, além disso, se desejar, você pode gerenciar o som da campainha e também visualizar o histórico de intervenção dos sinos. O painel também pode gerenciar arquivos históricos, permitindo que você tenha um relatório das intervenções dos sinos em relação à data / hora.
- Você deve estar logado para responder a este tópico.