Conferencia de expertos "Exploración de los principios de comunicación PLC" serie de videos: https://www.ad.siemens.com.cn/service/elearning/series/288.html
Serialización Parte 2: [Explorando los secretos de los principios de comunicación PLC] Un estudio preliminar de los huevos detrás de escena en la sala de conferencias
Número de serie tres: [Exploración de los principios de comunicación del PLC] El fracaso de los huevos detrás de escena en la sala de conferencias
Número de serie cuatro: [Exploración de los principios de comunicación del PLC] El amanecer de los huevos detrás de la gran sala de conferencias
Número de serie cinco: [Exploración de los principios de comunicación del PLC] La oscuridad de los huevos detrás de la gran sala de conferencias
Número de serie 6: [Exploración del principio de comunicación PLC] La ruptura de los huevos detrás de escena en la sala de conferencias
Séptima parte en serie: [Explorando los principios de la comunicación PLC] La vela de los huevos detrás de escena en la sala de conferencias
Número de serie ocho: [Exploración de los principios de comunicación del PLC] La sombra de los huevos detrás de la gran sala de conferencias
Número de serie nueve: [Exploración de los principios de comunicación del PLC] La flor brillante del huevo detrás de la gran sala de conferencias
La aplicación de Wireshark me permite ver claramente la estructura del mensaje de datos y comprender completamente el papel y el significado del modelo de referencia ISO / OSI. Recuerdo haber aprendido Profibus antes y usar el software Amprolyzer para capturar paquetes en Profibus para ver la estructura del mensaje, pero en ese momento no lo entendía de ninguna manera, así que rara vez utilicé este software. Realmente piense en ello ahora. Este software definitivamente no es más débil que el uso de un osciloscopio para detectar fallas de Profibus, pero ahora hay cada vez menos oportunidades para usar Profibus, porque Profibus realmente ha entrado en la etapa de puesta de sol. ¡Y ahora es la era de Ethernet!
Además, cuando usa Profibus para configurar la comunicación S7, siempre puede ver el término TSAP. Aunque está representado por dos números en el Paso 7, también es un desastre cuando aprende la comunicación Profibus. No sé cuál es el papel de este parámetro. O cómo explicar este parámetro. Recuerdo que no le presté atención en ese momento, ya que tanto la configuración como la programación no tienen nada que ver con este parámetro, parece jugar un papel de visualización.
Cuando entendí Ethernet en profundidad y estudié el modelo de referencia ISO / OSI, este parámetro apareció nuevamente, lo que me obligó a enfrentarlo nuevamente. Resulta que las capas del modelo de referencia ISO / OSI dependen de SAP y Service Access Point para comunicarse, lo que significa que la comunicación entre capas depende de SAP. Por ejemplo, TSAP se encuentra entre la capa de transporte y la capa de sesión. La primera letra T y SAP de la capa de transporte de la capa 4 se utilizan para nombrar, y el SAP entre otras capas se implementa de acuerdo con este método de denominación. Al aprender buscando información en Internet, descubrí que el TSAP del modelo de referencia ISO / OSI es el puerto en el modelo TCP / IP. Entonces, todo esto es fácil de entender, y luego mire la comunicación Profubus S7, que utiliza el modelo de referencia ISO / OSI, por lo que solo puede ver TSAP.
Volviendo a los paquetes S7 capturados por Wireshark, descubrí que el tamaño de la PDU S7 es 240B, y el tamaño de los datos debe ser inferior a 240B, porque la PDU S7 también contiene el encabezado S7, este encabezado del paquete S7 también ocupa algunos bytes . Esto es fácil de entender, pero leí el manual, incluido el tamaño de consistencia de datos antes mencionado de la comunicación PUT / GET del S7-300 es 240B, luego comencé a dudar de que el tamaño de la consistencia de los datos de comunicación sea 240B y S7 PDU También es 240B, por lo que los datos de comunicación reales deben ser inferiores a 240B. Si es como se describe en el manual, 240B debe estar compuesto de datos S7 en dos cuadros. Dado que son dos cuadros, no son los datos enviados al mismo tiempo, entonces los datos ¿Cómo asegurar la consistencia? A través de la ayuda en línea de Step7, puede ver que al usar el S7-300 con interfaz PN integrada, la consistencia de datos de PUT / GET es 212B, 222B, y luego combinada con Wireshark, los datos de S7 en el marco de PUT y GET son consistentes con los datos de ayuda en línea En este momento, me sentí repentinamente brillante, como siempre. También muestra que la descripción del tamaño de la consistencia de datos 240B en el manual de 300CPU no es precisa.
De hecho, el primer concepto de exposición a la consistencia de los datos provino de PII / PIQ, porque el manual decía que los datos de PII / PIQ permanecen sin cambios durante un ciclo de CPU. De hecho, esta no es una dirección determinada, sino toda el área de direcciones PII / PIQ. Por ejemplo: el tamaño del área de imagen del proceso en S7-300 es 256B por defecto. La comprensión del concepto de consistencia de datos se limitó a esto en ese momento, pero sentí que este concepto era muy importante al programar. Recuerde hacer el proyecto del laminador en el pasado. La fórmula de cálculo del diámetro de la bobina autoescrita requiere algunos parámetros. Los datos de comunicación del controlador los requieren. Los datos deben ser consistentes, porque solo de esta manera se puede calcular la fórmula correctamente. Esto también muestra que comprender este concepto es definitivamente instructivo para la programación de proyectos de ingeniería.
Entonces, ¿es la consistencia de datos de BSEND / BRECV 240B como se describe en el manual? Lea siempre el manual, S7-300PLC puede llevar a cabo un máximo de comunicación de 32k S7, S7-400PLC puede llevar a cabo un máximo de comunicación de 64k S7, S7-300PLC puede garantizar una consistencia de datos de 240B, si desea mantener consistentes los datos en toda el área de datos de comunicación Sexo, necesita usar la señal Done / NDR.
Después de capturar paquetes a través de Wireshark, veo que el tamaño de la PDU S7 sigue siendo de 240 B. ¿Entonces la consistencia de datos de 240 B en el manual requiere dos paquetes para sintetizar datos de 240 B S7? Si es así, ¿es complicado el PLC? ¿Cómo se puede garantizar internamente? ¿O la consistencia de los datos no es 240B? Aunque Wireshark captura paquetes y puede ver el tamaño real de los datos S7, por ejemplo, la longitud del primer paquete de datos de la comunicación S7 es 204B, ¿es este el tamaño real de la consistencia de los datos? ¿Cómo probarlo?
De hecho, este es un problema difícil. Siento que acabo de partir, y que he quedado varado aquí, y siento que debe resolverse.
