Generación de código de aplicación
El código de aplicación es el código de máquina que ejecuta un PLC cuando inicia una aplicación.
CODESYS genera automáticamente el código de la aplicación a partir del código fuente que se escribió en el sistema de desarrollo. Esto se hace automáticamente antes de descargar la aplicación al controlador. Antes de que se genere el código de la aplicación, se realiza una prueba para verificar las asignaciones, los tipos de datos y la disponibilidad de las bibliotecas. Además, las direcciones de memoria se asignan cuando se genera el código de la aplicación.
Puedes hacer clic para ejecutar explícitamente este comando. Esto es útil para detectar cualquier error en su código fuente, incluso cuando el PLC aún no está conectado. Los errores se muestran en la vista de mensajes en la categoría "Generar".
Importante
Si ha cifrado la aplicación, tenga en cuenta la siguiente información: Si se genera una (nueva) aplicación de arranque a petición después de un cambio en línea, entonces la aplicación de arranque se forma en la RAM con el código actual que no está cifrado.
Generación explícita del código de la aplicación
Requisito: La aplicación se puede compilar sin ningún error.
Hacer clic .
Se genera el código de la aplicación. La información detallada sobre la asignación de memoria se emite en la vista de mensajes.
Para más información, ver: Creación de una aplicación de arranque
Mensajes al generar el código de la aplicación
Cuando genera el código de la aplicación, CODESYS emite información sobre la asignación de memoria en la vista de mensajes. Se forman espacios en la memoria porque la reasignación es solo para POU y variables nuevas y modificadas debido a la creación de memoria incremental. Los cambios en línea tienen el mismo efecto. Esta fragmentación reduce la cantidad de memoria disponible. Sin embargo, puede reasignar completamente la memoria haciendo clic en Limpio y por lo tanto aumentar la cantidad de memoria libre.
Errores de sintaxis y bugs que CODESYS detecta durante la generación de código y la asignación de memoria también se muestran en la vista de mensajes (Construir categoría).
Información de salida sobre la asignación de memoria:
Tamaño del código generado (en bytes): suma de todos los segmentos de código
Tamaño de los datos globales (en bytes): Memoria total utilizada por las variables globales. Las entradas y salidas no se incluyen a menos que las entradas o salidas estén mapeadas en el área de las variables globales.
Tamaño total de memoria asignada para código y datos (en bytes): la memoria total asignada se compone de las áreas de memoria ya utilizadas más la memoria reservada y aún no utilizada para compilaciones incrementales y cambios en línea. Después de la primera compilación, la memoria ya utilizada es aproximadamente igual a la dirección utilizada más alta (ver más abajo). La brecha de memoria contigua más grande (ver más abajo) aún corresponde aproximadamente a la diferencia con la memoria total asignada. Sin embargo, a medida que aumenta la cantidad de compilaciones incrementales y cambios en línea, también aumenta la cantidad de brechas de memoria y la brecha de memoria contigua más grande se vuelve más pequeña.
Área de memoria <n>: Contenido de las áreas de memoria reservadas individuales:
Antecedentes: Depende del PLC qué datos y códigos se almacenan en qué áreas de memoria. Por ejemplo, el código y los datos se encuentran en la misma área en el CODESYS Control Win. Para las direcciones
%I,%M, y%Q, la memoria siempre está reservada, incluso cuando una variable no está asignada a una dirección. Después de "limpiar" la aplicación, la memoria se reasigna por completo. En este caso, pequeños espacios podrían resultar de la "alineación" predefinida (normalmente 8). Los espacios más grandes resultan de cambiar una fecha sin "limpiar", por ejemplo, al aumentar un área de matriz. En este caso, solo se vuelven a compilar las POU afectadas. Además, en el caso de un cambio en línea, la memoria se usa solo para nuevas variables y nuevo código. La memoria que estaba previamente reservada por las variables eliminadas y el código vuelve a estar disponible. Como resultado, la fragmentación de la memoria puede ocurrir después de muchas compilaciones incrementales y cambios en línea. Esto crea muchas brechas pequeñas que podrían no ser útiles en algunos casos. Para aclarar cuánta memoria está disponible de forma segura, la "brecha de memoria contigua más grande" del área de memoria se genera durante la generación de código.Dirección más usada (Byte): esta es la dirección reservada más alta en toda el área de memoria asignada. Durante la primera compilación después de una operación de "limpieza", las direcciones de memoria se envían a variables en orden ascendente, teniendo en cuenta la alineación (generalmente 8 bytes). Como resultado, la dirección más alta utilizada en este momento corresponde aproximadamente a la cantidad de memoria utilizada. El resto del área de memoria asignada todavía está completamente disponible para compilaciones incrementales y cambios en línea.
La brecha de memoria contigua más grande (en bytes): este es el tamaño de la memoria que está disponible para la copia de seguridad.
Las lagunas resultantes en la memoria asignada se reutilizan siempre que sea posible para otros cambios. Cuando, por ejemplo, una variable global de tipo
Bytese suma, se coloca en el primer byte libre de la memoria. Incluso solo una pequeña brecha es suficiente para esto. Sin embargo, una instancia de FB, una variable del tipo estructura o matriz, o el código para una POU debe almacenarse de forma contigua y, por lo tanto, ocupa más memoria en consecuencia. Como resultado, solo se pueden asignar al área de memoria contigua más grande. Esta es la razón por la que durante la generación de código se genera la "brecha de memoria contigua más grande" que está disponible de forma segura (en bytes), así como su porcentaje de la memoria total.
Para esto, ver también: Opciones para generar aplicaciones
Cifrado del código de la aplicación
Para más información, ver: Cifrar aplicación