- Este tema tiene 14 respuestas, 6 participantes y se actualizó por última vez 3 años, hace 4 meses da
.
-
Publicación
-
Con referencia al bloque ModbusMaster, en el manual de programación IEC 61131-3 LogicLab se mencionan los códigos de error que se pueden capturar a través de la función SysGetLastError. En particular, los errores durante la recepción de la trama de respuesta a los mensajes transmitidos por el maestro que se indican como 10007500 ~ 7 (es decir, de 0 a 7) pero sin asociar los diversos casos. En mi caso particular obtengo el error 10007505 pero no entiendo a qué condición se refiere (carácter incorrecto, longitud incorrecta, CRC, etc.).
Por lo que entiendo de la lectura del manual, cada vez que se realiza un ciclo de lectura / escritura, al final del ciclo se genera la salida "Listo", ya sea que la acción sea exitosa o no. Sin embargo, es posible tener indicaciones en este sentido a través de los valores asumidos por las salidas “Ok” y “Fallo”. Pero en caso de que el ciclo falle, ¿el siguiente intento de lectura / escritura lo realiza directamente el bloque ModbusMaster o es necesario realizar una nueva conmutación de la entrada Enable?
Si siempre se debe leer la misma área de memoria en un solo esclavo manteniendo la entrada "Enable" siempre activa, los ciclos de lectura se realizan directamente por el bloque ModbusMaster o se debe implementar siempre la entrada Enable alternando para activar la varios ciclos?
De hecho no hemos reportado todos los errores, generalmente indicando que el error está en la transmisión o recepción del paquete también porque muchas veces el error da una indicación incorrecta de cuál es realmente el problema. En su caso, el error 10007505 indica que está recibiendo una respuesta de un ID de nodo diferente o recibiendo un código de función diferente al solicitado. La mejor manera de entender dónde radica el problema es activar el espionaje (Tema).
En lo que respecta a la lectura consecutiva, la salida de Terminado denegado en la entrada permitir, posiblemente definiendo un tiempo de Retrasar si desea interponer un tiempo entre comandos. El FB ha sido diseñado para permitir cascada y este tema tratemos el tema.
La respuesta a su última pregunta está implícita en la respuesta anterior.
Estoy tratando de configurar un NetlogIII para comunicación en modbus RTU con un convertidor ABB ACS580 conectado al bus de campo RS485. En LogicLab utilicé los bloques Sysfopen y ModBusMaster. La primera pregunta es sobre la numeración de los puertos, no pude encontrar información en los manuales, el bus de campo corresponde a COM2, ¿correcto?
Una vez que se ha cargado el programa, el inversor confirma que la conexión está bien, no hay error e indica que está recibiendo y enviando datos en el modbus correctamente mientras que en el PLC la variable SysGetLastError me da el error 10007506 y desde la consola Telnet Toolly visualizo el error "Marco de respuesta demasiado largo".
Estoy intentando leer una palabra de 16 bits en un registro de memoria. Verifiqué dos veces los cables, la polaridad, la velocidad y el bit de paridad del bus en los dos dispositivos y todo está correcto. No hay otros dispositivos en el bus, la resistencia de terminación está activa tanto en el variador como en el PLC, mientras que la polarización también está activa en el variador.
En XTarget_12 (del firmware SFW184B000) se creó el FB para abrir el puerto serie SysSerialPort que permite, además de abrir, también configurar los parámetros de comunicación. Aunque es correcto utilizar el Sysfopen Le sugiero que utilice el nuevo FB (si es necesario, actualice el firmware en el NetlogIII, Ver preguntas frecuentes). La puerta Fieldbus es el puerto COM2, el error 10007506 que ve como se informa en el manual se refiere a un error en la recepción.10007500~7 Errore in ricezione frame risposta (Carattere errato, lunghezza errata, CRC).Ahora me dices que en Telnet con Toolly ves "Marco de respuesta demasiado largo", por lo que significa que lo has activado SpyOn y está espiando la comunicación Modbus con el variador. Luego, se muestran tanto el marco de solicitud enviado como el marco de respuesta recibido, si marca estos frames siguiendo la especificación Modbus, probablemente verá que se solicitó un cierto número de registros en la solicitud y que se recibieron más datos en la respuesta de los esperados. ¿Por qué sucede esto? Debería ver el informe de espionaje en Toolly, pero en general, está seguro de haber configurado el modo de comunicación correctamente (velocidad en baudios, paridad, bits), está seguro de que está utilizando el código de lectura correcto y el correcto dirección de registro (recuerde el desplazamiento de 1). El ModbusMaster FB dice: "De acuerdo con las especificaciones de Modbus, la dirección enviada en la trama de datos es (Dirección-1)” Esto se debe a que quien cumple con Modbus agrega 1 a la dirección recibida, pero muchos devices no suman, por lo que debe sumar 1 al valor de Dirección pasado al FB. Si me envias un printscreen de la pantalla Toolly tal vez pueda ser más preciso.
Mientras tanto, gracias por la respuesta rápida y completa, ¡soporte excepcional!
Tan pronto como puedo hacer una prueba con el bloque SysSerialPort, en realidad tenía algunas dudas sobre la diferencia entre los dos bloques. En la consola de Toolly, veo que el paquete enviado y recibido coincide:| Tx | 02 04 9 44 00 01 5F BC
| Rx | 02 04 9 44 00 01 5F BC
| Er | Respuesta demasiado largaModBusMaster: Tipo: 0; Nodo: 2; FCode: 16 # 03; Dirección: 40005, Puntos: 1; IFTime: 286; Tiempo de espera: 500; Retardo: 1000.
(Pido disculpas pero no pude encontrar cómo adjuntar las imágenes al foro ...)La dirección no es un problema porque tengo una serie de registros adyacentes, por lo que como mucho debería leer un dato diferente al deseado.
Gracias por los cumplidos ... hoy es un día puente y luego, sin llamadas telefónicas, tiene más tiempo para el foro. La trama modbus enviada no me regresa. El nodo es 02, pero el código de función es 04 no 03 como dice que lo ha configurado. La dirección de registro como puede ver es 9C44 que corresponde a 40004 (Conjunto de direcciones -1), solicite un registro 00 01 y el CRC es 5FBC.
Pero la respuesta es incorrecta, no debe coincidir en absoluto con la solicitud, parecería un eco hecho por el drive que absolutamente no debe suceder, porque el FB espera la respuesta que debe ser del tipo 02 04 02 xx xx CRC. Es decir, solicitó un registro y la unidad responde con 02 bytes seguidos de su valor y el CRC.
Puede intentar espiar con un puerto RS485 en paralelo en la línea de comunicación para ver si después de la trama de solicitud hay una trama de eco y luego en realidad la trama de respuesta. El FB después del primer cuadro recibido lo verifica y si hay un error, aborta esperando el siguiente comando y, por lo tanto, no le muestra el posible cuadro correcto que sigue.
La razón del error es evidente, se esperan 7 bytes de respuesta y en su lugar llegan 8.
Realicé la prueba con el FB SysSerialPort pero sin éxito. El Drive me dice que no hay actividad en el Bus y no intercambia datos, mientras que en el PLC el ModBusMaster FB me da el error 10007010.
Si en cambio lo intento de nuevo con el Sysfopen Vuelvo el intercambio de paquetes con el error ya resaltado. También he comprobado en el manual de la unidad si existe la posibilidad de una respuesta de eco, pero no he encontrado un rastro, por lo que no puedo explicar la respuesta. También lo intenté de nuevo bajando la velocidad del bus a 9600 pero sin éxito, el cable no es el máximo pero considerando que no tiene ni 2 m de largo no creo que haya problemas de interferencia.
¿El error indica que el valor del Archivo no está definido, pero ha pasado el valor del Archivo del SysSerialPort FB al ModbusMaster FB? En longitudes tan cortas el cable normalmente no tiene problemas, ahora para entender el problema, el único es espiar comunicación en RS485 o enviar comandos Modbus desde Toolly (ver la última publicación de este tema) o con un programa de simulación Modbus, por ejemplo, el mejor Simulador maestro Modbus.
Tengo un problema con Toolly en la práctica después de la autenticación con el comando SpyData y responde que no está activo. Sin embargo, he configurado el SpyOn del ModbusMaster FB en TRUE, ¿por qué? Donde me equivoco
¿Se ejecuta el ModbusMaster FB ?, en qué tarea pusiste la ejecución Recuerdo que debe existir en la tarea Atrás.
¿El parámetro Archivo está correctamente configurado? ¿Se refiere a un ARCHIVO válido?Ok Gracias, era la ubicación del programa la que no estaba en Back. Ahora veo los datos enviados y recibidos ...
Estoy experimentando con el uso de ModbusMaster FB sin éxito. Tengo un objeto que acepta comunicaciones Modbus TCP. La conexión con el objeto es correcta, el parámetro de archivo saliente no es NULL. Usando el programa Modbus Master Simulator recomendó otra publicación ... me lee los datos correctamente.
Configuré los parámetros en el FB de conexión TCP y Modbus Master de la misma manera que en el programa de simulación. Recibo el error 10007506: supongo que definí incorrectamente los datos y cuántos registros leer ... ¿puede ser?
Los datos que estoy tratando de leer son un valor en el registro de número 5 definido como entero de bit 32 (es una temperatura).
Defino una variable DINT en LogicLab, defino los otros parámetros, la dirección menos uno, así que le doy 4, pero siempre obtengo ese error. Intenté definir la variable de una manera diferente (INT, USINT, etc ...) pero nada.
Sé que estoy cometiendo un error trivial porque el objeto se comunica en modbus, pero no entiendo dónde me equivoco.
Usar espionaje es la solución que te permite entender dónde te equivocas. Hablamos primero de esto en esta publicación o si estás buscando encontrarás muchos temas que hablan sobre la consola espía (Artículo).
Regresaré a esta publicación para comprender la diferencia entre los errores de tipo 10007500-7. Lo explicaré. tengo uno SlimLine Cortex M7 [MPS054B110], a través de una conexión TCP / IP consulto un dispositivo modBus que me devuelve 8 BYTE en 4 direcciones diferentes cada una para componer valores flotantes (REAL). La solicitud se da de forma continua y me pasa de forma absolutamente aleatoria (he comprobado todo: tiempo, contemporaneidad con otras funciones, etc.) que después de 2-3 días o después de 5, se interrumpe la comunicación generando el error 10007505.
La única forma de reiniciar la comunicación es reiniciar el SlimLine. Pensando que podría ser un problema con el dispositivo, conecté una PC al propio dispositivo y con un pequeño programa en Python lo monitoreé durante 2 semanas consecutivas pero la comunicación nunca se detuvo. En detalle, ¿qué significa este error además del genérico "Error al recibir la trama de respuesta (carácter incorrecto, longitud incorrecta, CRC)"? ¿Se le ocurren otras pruebas para realizar?
El error que mencionas aparece si pierdes caracteres en la cadena de respuesta, podría ser un problema similar al reportado en las últimas publicaciones de este tema. Sería útil para comprender el problema tener un informe de espionaje de comunicación con Toolly.
Porque funciona por un tiempo y luego se congela es muy extraño, por supuesto usar el ModbusMaster FB que usa el IFTime para dividir los paquetes modbus, es suficiente que el dispositivo esclavo por alguna razón fragmente la respuesta en múltiples paquetes TCP que esto podría generar el problema.
Como se recomienda en el tema que le vinculé, le sugiero que reemplace el FB de administración de Modbus con la nueva versión ModbusMaster_v1 que ha sido completamente rediseñado, eliminando el control sobre el tiempo entre cuadros, el paquete es completamente olfateado y verificado haciéndolo independiente de los tiempos.
- Debe iniciar sesión para responder a este tema.