Muy buenas de nuevo.
Al final he tenido que utilizar el protocolo Modbus RTU Extend(Zero-based addressing) para poder utilizar los bits y palabras. Con ese mismo protocolo he conectado también un PLC de Schneider de las series TSX.
Estoy contento con las posibilidades de diseño de este HMI, aunque no me gusta mucho la gestión de las alarmas y eventos.
Muchas gracias por su ayuda.
Si necesitan mas información sobre la conexión con PLCs Schneider no duden en preguntar.

Muy buenas.
Ya tengo mi primer HMI Kinco!!!
He conseguido comunicarlo con un PLC Schneider Modicon utilizando la conexion "Schneider M Series" por el COM0 y RS485.
Puedo leer y escribir variables tipo MW pero tengo un problemilla con los bits.
No soy capaz de leer y escribir variables tipo BOOL del PLC (bits).
En el manual de Kinco encontre un listado de variables pero no las que me aparecen como opción.
Hay unas "internas" del HMI que por supuesto no probé, pero si que lo hice con las otras y no funciona.
¿Sabeis que tipo de variable he de seleccionar en la programacion de la pantalla HMI?
Un saludo y gracias.

Buenas tardes.

Vuelvo a postear para decir que logramos implementar la alternativa con PAWN (tal como nos recomendó, fusionando PAWN con LADDER) y fue la solución definitiva que estabamos buscando. Logramos el mejor control de la PWM desde que empezamos este proyecto.

Muchas gracias por el tiempo.
Saludos.

Buenas tardes,

Le consulto para comprender, ¿necesita generar una señal PWM que este presente por "x" tiempo, y no obtiene exactamente tiempo "x"?.

¿Cómo sería conceptualmente la secuencia que utiliza para "prender/apagar" el PWM?.

Por ejemplo:

1) SET DUTY CYCLE = 50% (PRENDE PWM)
2) Espera "x" tiempo
3) SET DUTY CYCLE = 0% (APAGA PWM)

¿La medición entre puntos (1) y (3) no es "x"?.
¿Qué frecuencia de PWM está utilizando?.

La realidad es que estamos un poco perdidos respecto a esto, y quisieramos entender si es posible lograr señales de PWM con una duración ajustable a la unidad de ms, o si el scan cycle del PLC nos va a pisar siempre esto, llevándonos al múltiplo de 18ms más cercano. Y sumado a esto, porque es que el conmutador parece tener un tiempo de actualización desfasado con el final de la PWM (segunda imagen).

En el diagrama "Principal", desde que da la orden de "prender PWM", hasta que da la orden de "apagar PWM" (utilizando un temporizador por ejemplo), pueden pasar uno o más SCAN CYCLES, y cada SCAN CYCLE tiene código que se ejecuta (por ejemplo envío de datos, llamadas a otras funciones, etc). Por lo que un retardo tendrá, el valor mínimo, depende de la cantidad de código que ejecute en cada SCAN CYCLE.

Una forma de hacer más rápido el SCAN CYCLE, es agrupar código dentro de funciones que solo se ejecuta si se da una condición válida, por lo tanto, en cada SCAN CYCLE no se procesará todo el código de Principal, sino por fragmentos.

Por ejemplo, en el caso que use un Temporizador Ladder con valor de 1 mS (para prender/apagar el PWM), si el SCAN CYCLE tarda 15 mS, el temporizador en cada SCAN CYCLE habrá expirado, y sería equivalente a utilizar una resolución de 15 mS. En este caso se puede utilizar funciones para agrupar código y bajar el tiempo del SCAN CYCLE, pero requiere experimentar, y le recomiendo mejor la segunda o tercera alternativa a continuación.

Una segunda alternativa, es crear un evento OnTimer2 que se llame cada 1 mS (ver Temporizadores por Evento), y desde allí prender y apagar el PWM, contabilizando el tiempo desde el propio evento utilizando un contador por ejemplo. Esto podría mejorar los retardos a un punto aceptable.

Finalmente, existe una tercera alternativa para el PWM, hay una función en lenguaje Pawn, (que podría utilizarse en Ladder si se inserta código Pawn) que permite generar un tren de "x" pulsos PWM. Esto se hace en segundo plano, independiente del SCAN CYCLE, por lo que desde que da la orden, se generan "x" pulsos, y luego se apaga. Si establece la frecuencia a un valor determinado, puede lograr un tiempo fijo de acuerdo a la cantidad de pulsos, y este tiempo sería lo más exacto posible.

Ver función PwmTrainStart(Channel, DutyCycle, Pulses) en página 84 del manual:

www.slicetex.com/hw/stx8xxx/docs/STX8XXX-MP-PLC.pdf

Ejemplo:

// Generar 10 pulsos en salida PWM1 con un DutyCycle del 50.0%.
PwmTrainStart(PWM1, 500, 10)

Si la frecuencia es "30 Hz":

Tiempo total = Pulsos * 1 / FrecuenciaPWM = 10 * 1/30 = 333 mS

Tiene dos variables para variar el tiempo final, la cantidad de pulsos y la frecuencia. La frecuencia la puede dejar fija, y variar el tiempo total con la cantidad de pulsos.

Si le interesa el "tren de pulsos" le puedo hacer un ejemplo de uso en Ladder.

Buen fin de semana.

Saludos!.

Buenos días Ariel,

Hola boris, soy ariel,  te quería hacer una consulta, tengo un problema con los display de los plc, se apagan, los cambie y hacen lo mismo, esta andando y como que se les borra lo escrito, en este caso es el peso, esta funcionando lo más bien, cambie de plc, cambie el display (compre uno nuevo me fije que fuera el mismo integrado) le puse los capa como dice el instructivo que esta en la página, pero lo mismo esta andando lo mas bien y pierde el display, que puede ser?

Se puede estar introduciendo un ruido, por ejemplo al conmutar una salida con un rele/contactor/electroválvula. El modelo STX8081 es susceptible en el display a ese tipo de ruido en algunas ocasiones. Te recomendaría, si estás comandando relés/contactor/electroválvula, colocarles un diodo en paralelo, o capacitor + resistencia (100 nF + 100 Ohms) a esos elementos. Si tenés relés de estado sólido para colocar entre el PLC y esos elementos, mejor.

Te adjunto en archivo ZIP el mismo proyecto, pero cada 1 segundo desde el diagrama principal fuerza a re-inicializar el display LCD, fíjate si eso corrige la falla.

Saludos!