Hola,
Bueno después de colocar un poco los bloques de la rutina que se te ve afectada por el hecho que mencionas, tengo que decirte que no veo nada que pueda afectar a que el tiempo vaya más deprisa.
Sin entrar a comprender todo el proyecto, ni saber que hace, ni como funciona, por lo que veo tienes creada una base de tiempos con el contador interno TMR0 y algún registro auxiliar. De forma que con el TMR0 se incrementa cada 100msg, cuando alcanza el valor de 10 incrementadas un registro auxiliar (tiempo) y a la vez otro llamado (tiempo_t1). Esta ultima acción no entiendo por que se realiza sin haber comprobado que "tiempo" haya alcanzado un valor determinado. Pero en fin si te funciona me supongo que tiene su utilidad dentro del programa.
La rutina de trabajo que has indicado que es la que te origina el efecto descrito, solamente tiene un bloque de comprobación del estado de la entrada "PIN,ent_1_det_eslabon". A partir de ahí si el valor es=1 ejecuta la rutina "p_imp_engrase" que dentro de ella activas un led, me supongo que durante un tiempo y a la vez lees los valores de la eeprom(??). Pero si la entrada es=0 pasas a comprobar otras rutinas, de forma que se realizan un a serie de opciones y al final se regresa al mismo punto (salto1). Esto lo he llamado yo así para la recolocación de los bloques de la rutina. Después, de regreso al salto, la siguiente operación es comprobar si el registro tiempo es >=1 y si se cumple la condición automáticamente reseteas el "contador tiempo"
Mi consejo es que revisases toda esa parte, incluso lo primero que haría seria aumentar el tiempo de la actuación del anti-rebote en la comprobación del estado de la entrada "PIN,ent_1_det_eslabon". Por defecto Niple te pone 20msg; prueba a aumentarle. Te adjunto en un grafico la parte a revisar y/o aumentar el tiempo.
Por otra parte creo que deberías de mejorar las rutinas: ciclo_p_paueslb y ciclo_p_traeslb. Están igual de mal que la que yo te he corregido. Adjunto también el programa con esa corrección. Es muy difícil seguirlas.
F.