- Este tópico tem 14 respostas, 1 participante e foi atualizado pela última vez 2 anos, 4 meses atrás da
.
-
Publique
-
Eu preciso para se comunicar com 4 inversor Schneider ATV12 para dar-lhe alguns comandos básicos, comece direção, referência de velocidade, e retirar algumas outras bases de dados, a absorção, a frequência, alarmes.
A comunicação do ATV12 é modbus no RS485, eu uso um SlimLine CPU compact ethernet, que tem uma porta TCP / IP e uma porta RS232, dei uma olhada no fórum e não sei se entendi bem, mas pode haver a possibilidade de ter um conversor TCP / IP -> Modbus RS485 direto para SlimLine usando vários CEs? Eu entendi corretamente ou estou completamente fora da pista?
De outra forma eu ainda poderia usar a porta RS232 da CPU, no entanto neste momento eu seria obrigado a fazer um conversor justo?
Para obter informações, eu já uso a conexão TCP / IP do SlimLine para se comunicar com um painel IHM da weintek e um roteador.
O sistema SlimLine pode fazer as duas coisas como um conversor TCP / Serial (Tema) como um conversor Modbus TCP / Modbus RTU (Tema), mas esses dois recursos não são necessários no seu caso. Pelo que entendi, você deseja gerenciar o inversor a partir de um programa PLC.
Para fazer isso você só precisa instanciar um FB ModbusMaster e gerenciar comandos para inversores (Você pode consultar este tópico). Certamente era melhor usar um módulo de CPU MPS054A1 * 0 que já tem RS485 isolado porta serial, mas se você tem o modelo compacto no 'gama Serial / Serial Você pode encontrar o conversor certo para você.
Em relação à conexão TCP você pode usá-la para se conectar com o que quiser, os únicos limites são dados pela quantidade de soquetes que o sistema pode gerenciar (atualmente 32) e pelo uso de memória relocável RMalloc. Cada soquete usa a quantidade de memória definida em sua criação.
Obrigado pelos esclarecimentos, eu ainda tenho uma pergunta, para ser capaz de gerenciar todos os inversores 4 eu preciso de conversores serial / serial 4? Ou é um suficiente?
No caso de um ser suficiente, como eles devem estar conectados?
A principal característica do protocolo Modbus é precisamente o de poder operar em multidrop, ou seja, ter um sistema mestre que em diálogos de conexão de dois fios com um ou mais sistemas escravos, cada sistema escravo terá seu próprio endereço (nó Modbus definido).
Então, no seu caso, você terá que configurar um endereço diferente (Modbus Node) para cada inversor e então você pode conversar com todos com apenas uma linha serial RS485. A conexão é simplesmente em paralelo, os dois fios estão em paralelo em todos os dispositivos nota de aplicação).
Perfeito, muito gentil como sempre. Última pergunta :) em vez de usar um conversor tcp / ip RS485 / ethernet e conectar os inversores em tcp / ip aoelsist Eu poderia ter a vantagem de poder acessar diretamente os inversores, talvez através do easyaccess? então talvez seja possível alterar os parâmetros à distância?
Um pouco de confusão ... Enquanto isso, se você usar um conversor Ethernet / Serial para comunicar com os inversores e se quiser aceder a partir do HMI via EasyAccess tem que "desenganchar" do SlimLine, caso contrário, o ModbusMaster do SlimLine cuida da comunicação.
Muito, mas muito, muito melhor é usar a porta serial delo SlimLine para dialogar com o inveter, depois prossiga para SlimLine um servidor TCP em uma porta TCP (vamos assumir a porta 1000). Quando você se conecta da Ethernet à porta 1000 do SlimLine (Você pode fazer isso usando o EasyAccess). No programa, você pode desativar o ModbusMB FB e ativar o FB DataStreamExch ou ModbusTCPGateway para rotear dados da conexão Ethernet para a porta serial à qual os inversores (Fórum).
Estou usando o Modbus Master FB com excelentes resultados para me comunicar com 5 inversores. Mas de forma aparentemente aleatória o FB me reporta um erro que espionando ele com o Toolly é 10007506, se não entendi mal indica um erro no recebimento de dados, este erro porém não interrompe a comunicação, que continua sem problemas. O erro sai um pouco aleatoriamente em todos os inversores mais ou menos a cada 2/4 minutos, aqui está o relatório do console espião
03:23:03 (.310)|Tx|02 03 1C 20 00 01 82 63 03:23:03 (.011)|Rx|02 03 02 00 03:23:03 (.002)|Rx|Error:10007606, On Case:212, Back:51 ... 03:23:05 (.310)|Tx|03 03 1C 20 00 01 83 B2 03:23:05 (.016)|Rx|02 03 02 00 05 01 B7
É claro que faltam alguns caracteres na resposta, mas não entendo por quê. A configuração da taxa de Baud etc. Eu diria que está correta, caso contrário, acho que nunca iria se comunicar, em vez disso, posso controlar os inversores.
O timeout é de 100mS, o retardo é de 10mS (mas mesmo trazendo para valores superiores de 300mS) o problema ocorre o mesmo. Algum conselho ?
Como você diz e pode ver no relatório de espionagem, os personagens da resposta se perdem no FB ModbusMaster o parâmetro deve ser definido IFTime indicando o tempo entre quadros. No protocolo RTU os pacotes são separados por um tempo que varia de acordo com a taxa de transmissão, por isso deve ser configurado corretamente.
Se o dispositivo que responde por algum motivo inserir uma pausa na resposta, o FB interpreta como o fim do pacote e vai verificar, encontrando o erro.
O FB ModbusMaster_v1 foi completamente redesenhado, o controle sobre o tempo entre quadros foi eliminado, o pacote é completamente farejado e verificado tornando-o independente dos tempos.
Não me diga qual FB usa, sugiro que mude para a versão v1 e verifique seu funcionamento, atenção que na transição para v1 mudamos a definição d e os tempos de timeout e delay, agora são valores REAIS expressos em segundos.
Obrigado pela resposta rápida, queria tentar atualizar a biblioteca com o FB ModbusMaster_v1 Onde posso encontrá-lo?
Perfeito, parece que atualizando para ModbusMaster_v1 o problema desapareceu.
Sempre muito prestativo e prestativo como sempre!
Vagando no fórum vim a saber sobre este FB ACModbus, considerando que em certos instrumentos utilizo seus sistemas para me comunicar via Modbus RS485 com 5 Inversores, gostaria de ter mais algumas informações sobre este FB que presumo ter nascido recentemente.
Se eu não entendi mal, é "conveniente" usá-lo quando você precisa ler registros não consecutivos em vários dispositivos, correto?
Como a comunicação melhora? O uso deste FB pode melhorar o desempenho da comunicação e, portanto, também a velocidade?
Obrigado pelas explicações
Como você disse com razão o FB ACModbus, Array command Modbus, foi criado para facilitar a comunicação com dispositivos Modbus, permitindo que você defina os comandos a serem executados através de uma série de estruturas do tipo ACMODBUS_DATA.
O uso do FB certamente simplifica a escrita de programas, pois cuida de todas as operações de escalonamento dos comandos, otimizando a passagem de um comando para outro, justamente com o objetivo de obter o melhor desempenho possível.
Mas se quem escreveu um programa em ST usando o FB ModbusMaster ao programar adequadamente os comandos, ele já implementou todas as estratégias possíveis para minimizar os tempos que já obteve o desempenho máximo e, portanto, também o FB ACModbus não será capaz de fazer mais.
Não sei qual é a versão da biblioteca que você tem, mas se você baixar a última versão do site, com certeza encontrará o gerenciador mestre Modbus FB.
Agora é chamado ModbusMaster_v1, quem está familiarizado com nossas bibliotecas sabe que toda vez que os parâmetros de I / O são alterados em um objeto de biblioteca (Função ou FB) o nome do objeto também é alterado adicionando uma versão, como neste caso "_v1".
Se um objeto ModbuMaster anterior foi usado em um projeto antigo, ele pode ser recuperado da biblioteca eLLabObsoleteLib.
Nem é preciso dizer que em caso de revisão de um projeto antigo ainda seria melhor usar sempre as versões mais recentes disponíveis.
- Você deve estar logado para responder a este tópico.