Cómo dibujar un cronograma — La interfaz común entre personas y código, y entre personas

Última actualización: 2026-09-25 / Categoría: Diseño de control, PLC

Un cronograma (diagrama de tiempos) entrega al programador el «orden de movimientos» que el diseñador mecánico tiene en la cabeza. Esta guía es para quien tiene que escribir un programa solo con los planos y la lista de cableado, y para el diseñador mecánico que quiere transmitir la secuencia a la otra parte.

1. Los planos no llevan secuencia. Este diagrama es el que la entrega

Mirando la máquina no se sabe cómo se pretendía moverla. En los planos solo están las posiciones de los cilindros y los sensores, no la secuencia «cerrar la pinza después de que se alcance el final de avance».

El programador que no conoce la secuencia solo puede escribir a base de suposiciones. Si acierta, funciona; si falla, se para en la puesta en marcha. El cronograma saca esa secuencia fuera de los planos y la coloca entre el hardware y el software. Las formas de onda y las flechas son solo la apariencia; el contenido son las tres cosas siguientes.

2. El diagrama contiene tres cosas

① Cortar el movimiento continuo en estados

Lo primero es cortar en «estados» un movimiento que no tiene cortes. El vástago se mueve de forma continua y el motor sigue girando. El software no puede manejar nada sin límites, así que se corta en algún punto: «avanzando hasta que el final de avance pasa a ON», «avanzado cuando ya está en ON».

Cronograma con 1 Step = 100 ms. De arriba abajo: bFwdCmd (orden de avance, PLC→cilindro), nRodPos (posición del vástago, cilindro→PLC, una forma de onda que sube en rampa de 0 a 100 mm), bFwdLS (final de carrera de avance, ON en S7 cuando la posición llega a 100) y el interno sState (estado) como bloques de valor «Retraído», «Avanzando», «Avanzado». Hay flechas desde el flanco de subida de la orden hasta «Avanzando» y desde el flanco de subida del final de carrera hasta «Avanzado».
Las dos filas de arriba son el lado máquina (la orden y el movimiento sin cortes del vástago); las dos de abajo, el lado software (el final de carrera que marca el corte y los estados resultantes). La posición de las flechas es la decisión de dónde cortar.

Por qué hace falta — Porque solo el diseñador mecánico sabe dónde cortar. La posición de un sensor y la posición que el diseñador mecánico llama «completado» no siempre coinciden. Si el corte no está en el diagrama, el programador toma el ON del sensor directamente como completado.

② Sincronizar equipos con ciclos distintos

Lo segundo es el procedimiento para acompasar equipos que funcionan con ciclos independientes. El PLC hace un scan cada 10 ms, el robot tiene su propio ciclo y la máquina de al lado funciona con otro PLC. Ninguno conoce el ciclo del otro. Si solo se lanza una señal, puede desaparecer antes de que la otra parte la mire, o captarse dos veces cuando se quería una.

Cronograma con 1 Step = 10 ms. De arriba abajo: bReq (petición, PLC A→PLC B), el interno bReqRead (la petición tal como la lee B, que lee cada 50 ms) y bAck (respuesta, PLC B→PLC A). En la primera mitad, la petición que A pone en ON solo durante el Step S1 no aparece en lo que lee B. En la segunda mitad, A mantiene la petición desde S6; B la lee en S10 y la respuesta pasa a ON; A ve la respuesta y retira la petición en S11; B ve caer la petición y retira la respuesta en S13. Hay tres flechas.
Primera mitad: solo lanzar la señal (desaparece entre los ciclos de B). Segunda mitad: esperar la respuesta de la otra parte (se capta seguro sin conocer el ciclo).

Por qué hace falta — Porque cada equipo puede estar bien hecho por separado y aun así romperse en el punto de unión. Los cuatro cambios petición ON → respuesta ON → petición OFF → respuesta OFF (el handshake) no son un truco. Son el procedimiento mínimo con el que dos equipos asíncronos acuerdan un estado de forma fiable. Si se omite un paso, las dos implementaciones divergen justo ahí.

③ Fijar el límite de responsabilidad entre equipos como un contrato

Lo tercero es el compromiso entre un equipo y otro. Se decide incluyendo las condiciones de tiempo, como «dejar al menos 500 ms entre Servo Ready ON y la petición de movimiento». El tiempo de espera se dibuja como la forma de onda del temporizador que medimos nosotros, y qué activa la otra parte y cuándo activamos lo nuestro se separan por filas. A quién pertenece cada fila es lo que hace visible el límite en el diagrama.

Cronograma con 1 Step = 100 ms. La fila superior es bServoReady (Servo Ready, servoamplificador→PLC), ON en S3. La fila central es el interno tReadyWait (tiempo desde Ready), una forma de onda que sube 0, 100, … 500 ms desde el flanco de subida de Ready. La fila inferior es bRunReq (petición de movimiento, PLC→servoamplificador), ON en S8 cuando la forma de onda llega a 500. Hay flechas desde el flanco de subida de Ready al inicio de la forma de onda, y desde el 500 de la forma de onda al flanco de subida de la petición.
Arriba, la responsabilidad de la otra parte (activar Ready). Abajo, la nuestra (ver Ready, esperar 500 ms y activar la petición). La forma de onda del centro es el tiempo que medimos nosotros. El tipo de compromiso que está escrito en el manual.

Por qué hace falta — Porque, una vez acordado esto, cada uno puede construir su interior con libertad. Haga lo que haga el amplificador por dentro, el lado del PLC no cambia mientras se respeten Ready y los 500 ms. Sin el acuerdo, ambos lados construyen suponiendo el interior del otro, y la puesta en marcha acaba en «tu lado es lento» y «tu lado la quitó antes».

3. Así se dibuja en el diagrama

4. Orden de dibujo

  1. Alinear los equipos y las señales que se intercambian en el límite Agrupe las filas por equipo y añada a cada señal el nombre de variable y el dispositivo, p. ej. petición de entrada bLoadReq / Y020.
  2. Dibujar un ciclo normal cortando en cada límite de estado Desde el arranque hasta el final, coloque los flancos en orden y únalos con flechas. Un flanco que no se puede unir es un corte aún sin decidir.
  3. Añadir en números las condiciones de tiempo de los límites Tiempos de espera y plazos de respuesta, junto al flanco o en el comentario de la fila.
  4. Dibujar los fallos y la recuperación en diagramas aparte Mismas filas, otro guion. Decida dónde se para, qué señales caen y cómo se vuelve a la posición de origen.

5. Donde se tropieza

6. Después de dibujar

Las flechas pasan a ser directamente las decisiones del diagrama de flujo (las condiciones para avanzar), y las filas, las variables del mapa de direcciones.

Las herramientas con las que se hicieron las figuras de este artículo

Todas las figuras de este artículo se dibujaron en el Timing Chart Editor y se exportaron a SVG.

  • Timing Chart Editor — Ordene las filas por el lado que genera la señal (M / S), trace flechas de cambio a cambio y anote tiempos de espera y comentarios.
  • Flowchart Editor — Convierte las flechas del cronograma en decisiones y esperas y monta el diagrama de flujo.
  • Address Map Editor — Asigna dispositivos del PLC a las señales del cronograma.

Sin instalación ni registro. Funcionan solo con el navegador.

Artículos relacionados

yk.builds