Início > Fórum > Programação IEC 61131 (LogicLab) > Perguntas sobre o uso do bloco de função ModbusMaster
etiquetadas: XUnificado
- Este tópico tem 14 respostas, 6 participantes e foi atualizado pela última vez 3 anos, 3 meses atrás da Sergio Bertana.
-
autorPublique
-
Novembro 15, 2016 em 1: 18 pm #36074Emilianoparticipante
Com referência ao bloco ModbusMaster, no manual de programação IEC 61131-3 LogicLab, são mencionados os códigos de erro que podem ser capturados por meio da função SysGetLastError. Em particular, erros durante a recepção do quadro de resposta às mensagens transmitidas pelo mestre que são indicados como 10007500 ~ 7 (ou seja, de 0 a 7), mas sem associar os vários casos. No meu caso particular, recebo o erro 10007505, mas não entendo a que condição se refere (caractere errado, comprimento errado, CRC, etc.).
Pelo que entendi pela leitura do manual, toda vez que um ciclo de leitura / gravação é executado, no final do ciclo a saída “Concluído” é gerada, seja a ação bem-sucedida ou não. Porém, é possível ter indicações neste sentido por meio dos valores assumidos pelas saídas “Ok” e “Falha”. Mas caso o ciclo falhe, a próxima tentativa de leitura / escrita é feita diretamente pelo bloco ModbusMaster ou é necessário realizar um novo chaveamento da entrada Enable?
Se a mesma área de memória deve ser sempre lida em um único escravo mantendo a entrada "Habilitar" sempre ativa, os ciclos de leitura são realizados diretamente pelo bloco ModbusMaster ou alternando a entrada Habilitar deve sempre ser implementado para ativar o vários ciclos?
Novembro 15, 2016 em 2: 18 pm #39752Sergio BertanaAdministrador do fórumNa verdade não relatamos todos os erros, geralmente indicando que o erro está na transmissão ou recepção do pacote também porque muitas vezes o erro dá uma indicação incorreta de qual é o problema. No seu caso, o erro 10007505 indica o recebimento de uma resposta de um ID de nó diferente ou o recebimento de um código de função diferente do solicitado. A melhor maneira de entender onde está o problema é ativar a espionagem (Tema).
No que diz respeito à leitura consecutiva, a saída de Pronto negado na entrada permitir, possivelmente definindo um horário de Demora se você quiser interpor um tempo entre os comandos. O FB foi projetado para permitir cascata e este tema vamos tratar do assunto.
A resposta à sua última pergunta está implícita na resposta anterior.
Dezembro 8, 2016 em 7: 58 pm #39778SilvioparticipanteEstou tentando configurar um NetlogIII para comunicação em modbus RTU com um drive ABB ACS580 conectado no fieldbus RS485. No LogicLab eu usei os blocos Sysfopen e ModBusMaster. A primeira pergunta é com relação à numeração das portas, não consegui encontrar informações nos manuais, o fieldbus corresponde a COM2, correto?
Uma vez que o programa foi carregado, o inversor confirma que a conexão está ok, sem erro e indica que está recebendo e enviando dados no modbus corretamente enquanto no PLC a variável SysGetLastError me dá o erro 10007506 e do console telnet do Toolly eu exibo o erro “Quadro de resposta muito longo”.
Estou tentando ler uma palavra de 16 bits em um registro de memória. Verifiquei novamente os cabos, polaridade, velocidade e bit de paridade do barramento nos dois dispositivos e está tudo correto. Não há outros dispositivos no barramento, o resistor de terminação está ativo no Drive e no PLC enquanto o bias também está ativo no drive.
Dezembro 9, 2016 em 7: 32 am #39779Sergio BertanaAdministrador do fórumNo XTarget_12 (do firmware SFW184B000) o FB foi criado para abrir a porta serial SysSerialPort o que permite além da abertura também definir os parâmetros de comunicação. Embora seja correto usar o Sysfopen Eu sugiro que você use o novo FB (se necessário, atualize o firmware no NetlogIII Veja FAQ) A porta Fieldbus é a porta COM2, o erro 10007506 que você vê conforme relatado no manual refere-se a um erro na recepção.10007500~7 Errore in ricezione frame risposta (Carattere errato, lunghezza errata, CRC).Agora você me disse que em Telnet com Toolly você vê "Quadro de resposta muito longo", então significa que você o ativou SpyOn e você está espionando a comunicação modbus com o inversor. Então, tanto o quadro de solicitação enviado quanto o quadro de resposta recebido são exibidos, se você marcar estes frames seguindo a especificação do Modbus, você provavelmente verá que um certo número de registros foi solicitado na solicitação e que mais dados foram recebidos na resposta do que o esperado. Por que isso acontece, devo ver o relatório de espionagem no Toolly, mas, em geral, você tem certeza de que configurou o modo de comunicação corretamente (taxa de transmissão, paridade, bits), tem certeza de que está usando o código de leitura correto e o correto endereço de registro (lembre-se do deslocamento de 1). O ModbusMaster FB diz: "De acordo com as especificações do modbus o endereço enviado no quadro de dados é (Endereço-1)” Isso ocorre porque quem é compatível com Modbus adiciona 1 ao endereço recebido, mas muitos devices eles não somam, então você tem que adicionar 1 ao valor de Endereço passou para o FB. Se você me enviar um printscreen da tela do Toolly, talvez eu possa ser mais preciso.
Dezembro 9, 2016 em 10: 11 am #39780SilvioparticipanteEnquanto isso, obrigado pela resposta rápida e completa, suporte excepcional!
Assim que eu posso fazer um teste com o bloco SysSerialPort, eu realmente tive algumas dúvidas sobre a diferença entre os dois blocos. No console da Toolly, vejo que o pacote enviado e recebido coincide:| Tx | 02 04 9 44 00 01 5F BC
| Rx | 02 04 9 44 00 01 5F BC
| Er | Responda muito tempoModBusMaster: Tipo: 0; Nó: 2; FCode: 16 # 03; Endereço: 40005, Pontos: 1; IFTime: 286; Tempo limite: 500; Atraso: 1000.
(Peço desculpas, mas não consegui encontrar como anexar as imagens ao fórum ...)O endereço não é um problema porque tenho uma série de registradores adjacentes, portanto, no máximo, devo ler um dado diferente do desejado.
Dezembro 9, 2016 em 12: 54 pm #39781Sergio BertanaAdministrador do fórumObrigado pelos elogios ... hoje um dia de bridge e depois sem telefonemas você tem mais tempo para o fórum. O quadro modbus enviado não retorna para mim. o nó é 02, mas o código de função é 04 e não 03, como você diz que definiu. O endereço de registro como você vê é 9C44 que corresponde a 40004 (Conjunto de endereços -1), peça um registro 00 01 e o CRC é 5FBC.
Mas a resposta está errada, não deve coincidir de forma alguma com a solicitação, pareceria um eco feito pelo inversor que absolutamente não deve acontecer, pois o FB espera a resposta que deveria ser do tipo 02 04 02 xx xx CRC. Ou seja, você pediu um cadastro e o drive responde com 02 bytes seguidos do valor e do CRC.
Você pode tentar espiar com uma porta RS485 em paralelo na linha de comunicação para ver se após o quadro de solicitação há um quadro de eco e, em seguida, realmente o quadro de resposta. Após o primeiro quadro recebido, o FB o verifica e, se houver erro, aborta a espera pelo próximo comando e, portanto, não mostra o quadro correto que se segue.
O motivo do erro é evidente, 7 bytes de resposta são esperados e, em vez disso, 8 chegam.
Dezembro 10, 2016 em 7: 45 pm #39783SilvioparticipanteEu executei o teste com o FB SysSerialPort mas sem sucesso. O Drive me diz que não há atividade no Bus e não troca dados, enquanto no PLC o ModBusMaster FB me dá o erro 10007010.
Se em vez disso eu tentar novamente com o Sysfopen Eu recebo de volta a troca de pacotes com o erro já destacado. Também verifiquei no manual da unidade se existe a possibilidade de uma resposta de eco, mas não encontrei nenhum vestígio, por isso não posso explicar a resposta. Também tentei novamente diminuindo a velocidade do barramento para 9600, mas sem sucesso, o cabo não é o topo, mas considerando que não tem nem 2m de comprimento, não acho que haja problemas de interferência.
Dezembro 12, 2016 em 7: 37 am #39784Sergio BertanaAdministrador do fórumO erro indica que o valor do arquivo não está definido, mas você passou o valor do arquivo de saída do SysSerialPort FB para o ModbusMaster FB? Em comprimentos tão curtos, o cabo normalmente não tem problemas, agora para entender o problema, o único é espiar comunicação em RS485 ou enviar comandos Modbus da Toolly (veja o último post este tema) ou com um programa de simulação Modbus, por exemplo, o melhor Modbus Master Simulator.
Pode 3, 2019 em 6: 03 am #47386StephenparticipanteTenho um problema com o Toolly na prática, após a autenticação, o comando SpyData responde que não está ativo. Ainda configurei o SpyOn do ModbusMaster FB para TRUE, por quê? Onde estou errado?
Pode 3, 2019 em 6: 05 am #47390Sergio BertanaAdministrador do fórumO ModbusMaster FB foi executado?, Em qual tarefa você colocou a execução lembro que deve existir na tarefa Voltar.
O parâmetro File está definido corretamente, ele se refere a um FILEP válido?Pode 3, 2019 em 8: 45 am #47392StephenparticipanteOk Obrigado, era a localização do programa que não estava no Back. Agora vejo os dados enviados e recebidos ...
Junho 7, 2019 em 6: 43 am #47976RuboxparticipanteEstou experimentando o uso do ModbusMaster FB sem sucesso. Tenho um objeto que aceita comunicações Modbus TCP. A conexão com o objeto foi bem-sucedida, o parâmetro Arquivo de saída não é NULL. Usando o programa Modbus Master Simulator recomendei outro post ... ele me lê os dados corretamente.
Eu defino os parâmetros na conexão TCP e Modbus Master FB da mesma forma que no programa de simulação. Recebo o erro 10007506: Acho que defini incorretamente os dados e quantos registros devo ler ... pode ser?
Os dados que estou tentando ler é um valor no registrador de número 5 definido como inteiro 32 (é uma temperatura).
Eu defino uma variável DINT no LogicLab, defino os outros parâmetros, o endereço menos um, então dou 4, mas sempre recebo esse erro. Tentei definir a variável de uma forma diferente (INT, USINT, etc ...) mas nada.
Sei que estou cometendo um erro trivial porque o objeto se comunica em modbus, mas não entendo onde estou errado.
Junho 7, 2019 em 6: 46 am #47979Sergio BertanaAdministrador do fórumUse espionagem é a solução que permite entender onde você está errado. Nós falamos sobre isso primeiro neste post ou se você está procurando por você vai encontrar muitos tópicos que falam sobre o console espião (Artigo).
Dezembro 3, 2020 em 9: 26 am #58390MarcelloparticipanteAproveito este post novamente para entender a diferença dos erros de tipo 10007500-7. Eu vou explicar. eu tenho um SlimLine Cortex M7 [MPS054B110], através de uma conexão TCP / IP eu consulto um dispositivo modBus que retorna 8 BYTEs para mim em 4 endereços diferentes cada um para compor valores flutuantes (REAL). A solicitação ocorre continuamente e acontece comigo de forma absolutamente aleatória (já verifiquei tudo: tempo, contemporaneidade com outras funções, etc.) que após 2-3 dias ou após 5, a comunicação é interrompida gerando o erro 10007505.
A única maneira de reiniciar a comunicação é reiniciar o SlimLine. Pensando que poderia ser um problema com o aparelho, conectei um PC ao próprio aparelho e com um pequeno programa em Python o monitorei por 2 semanas consecutivas mas a comunicação nunca parou. Em detalhes, o que significa esse erro além do genérico "Erro ao receber quadro de resposta (caractere errado, comprimento errado, CRC)"?. Você consegue pensar em outros testes para fazer?
Dezembro 3, 2020 em 9: 34 am #58393Sergio BertanaAdministrador do fórumO erro que você mencionou aparece se você perder caracteres na string de resposta, pode ser um problema semelhante ao relatado nas últimas postagens de este tema. Útil para entender o problema seria ter um relatório de espionagem de comunicação com o Toolly.
Porque funciona por um tempo e depois congela é muito estranho, claro que usando o ModbusMaster FB que usa o IFTime para dividir os pacotes modbus, é suficiente para o dispositivo escravo, por algum motivo, fragmentar a resposta em vários pacotes TCP para que isso possa gerar o problema.
Conforme recomendado no tópico que vinculei a você, sugiro que você substitua o FB de gerenciamento do Modbus pela nova versão ModbusMaster_v1 que foi totalmente redesenhado, eliminando o controle sobre o tempo entre quadros, o pacote é completamente farejado e verificado tornando-o independente dos tempos.
-
autorPublique
- Você deve estar logado para responder a este tópico.