[Antonio Castro]

Tienes razón, me he confundido.

La última publicada es la 1.2.1. La 1.2.2 no tiene más que cambios en los comentarios para mejorar la legibilidad de los fuentes con vistas a publicar esa versión junto a una segunda edición del libro de CAO1. Aunque no he tocado nada importante, la 1.2.2 es una ALFA porque no está probada.

He tenido que abandonar un poco CAO1 porque no doy a basto. Con la salida del nuevo IDE 1.6.7 se pusieron de manifiesto un montón de warnings y paré todo el tema de la nueva edición del libro y de la version 1.2.2, porque quiero decidir que hacer sobre los warnings con calma.

Entre tanto, tuve que desarrollar una nueva librería RTC y el programador básico. Ahora estoy con un tema que quizás no interese a tanta gente, pero que para mí es urgente. Me refiero al cambiador de agua para el acuario que también llevaba atascado un buen tiempo. No voy a tener mucho tiempo para CAO1 porque despus de todo eso, lo siguiente será continuar con CaoBT.

Me he repasado el código de las funciones avanzadas de la botonera con repetición de tecla que son las que dan problemas y no he visto nada sospechoso en el código.

La función GetButton(...) es un tanto liosa. Tiene cinco bucles while, Algunos unos dentro de otros y maneja varios estados. En uno de ellos parece que se queda enganchado.

Dices que en las pruebas iniciales sí conectaba un sensor de temperatura y funcionaba, y ahora no tenía conectado ninguno y no funciona.

Es raro, pero hay que comprobar si tiene algo que ver porque puede ser un dato importante. Ante eso, yo lo que haría para perseguir el problema es, volver a conectar el sensor y si vuelve a funcionar bien buscaría la parte del código que está marcando la diferencia. Lo haría desactivando o activando partes del código y empezaría por la llamada a la lectura de la temperatura. Para ello en la función GetTempAcu() colocaría un return 55; para evitar que entre en GetTempAddr(...); y a ver que pasa. Son solo sugerencias.

Código:

// *****************************
int GetTempAcu(){
    return ds18x20.GetTempAddr(ADDR_DS18X20_TEMP_ACUA);
}

[Agamenon]

Tienes razón, me he confundido.

La última publicada es la 1.2.1. La 1.2.2 no tiene más que cambios en los comentarios para mejorar la legibilidad de los fuentes con vistas a publicar esa versión junto a una segunda edición del libro de CAO1. Aunque no he tocado nada importante, la 1.2.2 es una ALFA porque no está probada.

He tenido que abandonar un poco CAO1 porque no doy a basto. Con la salida del nuevo IDE 1.6.7 se pusieron de manifiesto un montón de warnings y paré todo el tema de la nueva edición del libro y de la version 1.2.2, porque quiero decidir que hacer sobre los warnings con calma.

Entre tanto, tuve que desarrollar una nueva librería RTC y el programador básico. Ahora estoy con un tema que quizás no interese a tanta gente, pero que para mí es urgente. Me refiero al cambiador de agua para el acuario que también llevaba atascado un buen tiempo. No voy a tener mucho tiempo para CAO1 porque despus de todo eso, lo siguiente será continuar con CaoBT.

Me he repasado el código de las funciones avanzadas de la botonera con repetición de tecla que son las que dan problemas y no he visto nada sospechoso en el código.

La función GetButton(...) es un tanto liosa. Tiene cinco bucles while, Algunos unos dentro de otros y maneja varios estados. En uno de ellos parece que se queda enganchado.

Dices que en las pruebas iniciales sí conectaba un sensor de temperatura y funcionaba, y ahora no tenía conectado ninguno y no funciona.

Es raro, pero hay que comprobar si tiene algo que ver porque puede ser un dato importante. Ante eso, yo lo que haría para perseguir el problema es, volver a conectar el sensor y si vuelve a funcionar bien buscaría la parte del código que está marcando la diferencia. Lo haría desactivando o activando partes del código y empezaría por la llamada a la lectura de la temperatura. Para ello en la función GetTempAcu() colocaría un return 55; para evitar que entre en GetTempAddr(...); y a ver que pasa. Son solo sugerencias.

Código:

// *****************************
int GetTempAcu(){
    return ds18x20.GetTempAddr(ADDR_DS18X20_TEMP_ACUA);
}

Bueno, problema detectado y solucionado.

El problema ocurría porque no detectaba correctamente el estado de ningún botón pulsado (NULL).

Esto se debía a que al rehacer algunas soldaduras y conexiones de la botonera tras el montaje final, el estado NULL en vez de ser 0 oscilaba entre 2 y 6. Lo mismo pasa con los otros botones claro, que el valor leído oscila ligeramente.

La botonera de CAO está hecha admitiendo cierto PORCENTAJE de tolerancia, de forma que una oscilación pequeña en las lecturas aproxima al valor válido más cercano, haciendo que si lees un botón a 690 por defecto, las lecturas de 680 y de 700 te sigue dando el botón como válido.

Pero el problema está que el valor NULL es 0, por tanto un porcentaje sobre 0 sigue siendo 0. Por tanto mientras que en el resto de botones la tolerancia funciona perfectamente, en el valor NULL no funcionaba ningún tipo de rango de tolerancia, y una variación mínima ya daba lecturas incorrectas.

Lo que he hecho es modificar el método Cao1_Botonera5Puls en el fichero Cao1_Botonera5Puls.cpp para que los valores muy bajos también tengan cierto rango de tolerancia. Para los valores menores de 10, en vez de aplicar la tolerancia en porcentaje, la aplico en valor absoluto de forma que lecturas de 4, 3, 6 serían válidas para un valor NULL fijado por defecto en 0.

Código:

boolean Cao1_Botonera5Puls::_ValProximo(int Vinp, int Vref){
    if (Vinp < 10) {
        return ( (Vinp >= (Vref-TOLERANCIA)) && (Vinp <=  (Vref+TOLERANCIA) ) );
    } else {
        return ((Vinp >= (Vref - (Vref * TOLERANCIA) / 100)) && (Vinp <= (Vref + (Vref * TOLERANCIA) / 100)));
    }
}

[Antonio Castro]

En realidad, una entrada con un pull-down, debería dar cero sin margen de error. El porcentaje de error lo consideré proporcional al valor de la lectura en base a los motivos que intentaba prevenir.

1) Oscilación de la lectura por radiofrecuencias.
2) Variaciones por tolerancia de las resistencias.

Consideré que el desvío de los valores esperados en estos casos sería proporcional al valor leído. Un nuevo chequeo de hardware tras retocar las soldaduras habría detectado el problema y yo cuento con que esa prueba ha de ser obligada, pero admito que lo más normal es dar por hecho que si funcionó antes funcionará después.

Personalmente suelo poner bastante atención a las soldaduras. Uso gafas especiales de gran aumento mientras suelto y presto la máxima atención al aspecto de la soldadura. Suelo mantener la punta del soldador unos tres segundos calentando la misma una vez que parece que ya está terminada para impedir una soldadura fría. Con las soldaduras con cables procuro asegurarme de que la soldadura no va a sufrir tensión mecánica ni vibraciones y en caso necesario la sujeto abrazándola con un tubo termoretractil.

Toda esa paranoya a la hora de soldar es porque los fallos derivados de malos contactos pueden tener un comportamiento desconcertante y dar muchísima lata.

Una soldadura defectuosa puede originar valores muy próximos a los esperados o alejados. Además el desvío no es fijo, puede aparecer desaparecer o puede ir variando paulatinamente si se genera calor en el falso contacto por el paso de la corriente.

Personalmente considero poco práctico intentar preveer en el software todos los fallos de hardware relacionados con soldaduras defectuosas, pero si este fallo me hubiera pasado a mí creo que habría reaccionado casi exactamente igual que tú.

Por rizar el rizo. Vinp nunca será negativo y el concepto porcentaje de tolerancia tampoco sería aplicable así que quizás yo habría hecho algo del tipo...

Código:

boolean Cao1_Botonera5Puls::_ValProximo(int Vinp, int Vref){
    if (Vinp < 5) {
        return (true);
    } else {
        return ((Vinp >= (Vref - (Vref * TOLERANCIA) / 100)) && (Vinp <= (Vref + (Vref * TOLERANCIA) / 100)));
    }
}

Tú información ha resultado bastante útil. Me alegro que ahora todo funcione correctamente.

[Agamenon]

En realidad, una entrada con un pull-down, debería dar cero sin margen de error. El porcentaje de error lo consideré proporcional al valor de la lectura en base a los motivos que intentaba prevenir.

1) Oscilación de la lectura por radiofrecuencias.
2) Variaciones por tolerancia de las resistencias.

Consideré que el desvío de los valores esperados en estos casos sería proporcional al valor leído. Un nuevo chequeo de hardware tras retocar las soldaduras habría detectado el problema y yo cuento con que esa prueba ha de ser obligada, pero admito que lo más normal es dar por hecho que si funcionó antes funcionará después.

Personalmente suelo poner bastante atención a las soldaduras. Uso gafas especiales de gran aumento mientras suelto y presto la máxima atención al aspecto de la soldadura. Suelo mantener la punta del soldador unos tres segundos calentando la misma una vez que parece que ya está terminada para impedir una soldadura fría. Con las soldaduras con cables procuro asegurarme de que la soldadura no va a sufrir tensión mecánica ni vibraciones y en caso necesario la sujeto abrazándola con un tubo termoretractil.

Toda esa paranoya a la hora de soldar es porque los fallos derivados de malos contactos pueden tener un comportamiento desconcertante y dar muchísima lata.

Una soldadura defectuosa puede originar valores muy próximos a los esperados o alejados. Además el desvío no es fijo, puede aparecer desaparecer o puede ir variando paulatinamente si se genera calor en el falso contacto por el paso de la corriente.

Personalmente considero poco práctico intentar preveer en el software todos los fallos de hardware relacionados con soldaduras defectuosas, pero si este fallo me hubiera pasado a mí creo que habría reaccionado casi exactamente igual que tú.

Por rizar el rizo. Vinp nunca será negativo y el concepto porcentaje de tolerancia tampoco sería aplicable así que quizás yo habría hecho algo del tipo...

Código:

boolean Cao1_Botonera5Puls::_ValProximo(int Vinp, int Vref){
    if (Vinp < 5) {
        return (true);
    } else {
        return ((Vinp >= (Vref - (Vref * TOLERANCIA) / 100)) && (Vinp <= (Vref + (Vref * TOLERANCIA) / 100)));
    }
}

Tú información ha resultado bastante útil. Me alegro que ahora todo funcione correctamente.

Perfecto Antonio, gracias por la explicación.

Tengo otra duda respecto a sensores y incrementadores/decrementadores. Esta vez he variado la conexiones en los relés y he conectado unos a normalmente abierto y otros a normalmente cerrado. Pero claro, en CAO algunos están funcionando al revés. Estoy mirando pero no encuentro si en el código en el módulo de sensores hay alguna forma de definir cada incrementador/decrementador si se activa a HIGH o LOW. La única forma que he visto es hacerlo globalmente, es decir, invertir todos los incrementos y decrementos.

Hay alguna forma en la inicialización de cada sensor (temp acuario, temp led) definir para el incrementador y el decrementador, si se activan a HIGH o LOW???

[Agamenon]

Como no veo forma de configurar cada pin, he hecho una pequeña modificación para contemplarlo.

Los métodos de inicialización de Cao1_Sensor los he ampliado con dos parámetros booleanos: increaseHIGH y decreaseHIGH. Estos indicarán respectivamente si el incrementador o el decrementador se activan a HIGH (true) o a LOW (false).

Código:

void Ini( int PosFirstParm, char *StrId, int PinIncr, int PinDecr,
                boolean DoIncreaseDefault, boolean DoDecreaseDefault, boolean increaseHIGH, boolean decreaseHIGH,
                int (* FuncRead)(), void (* ProcHandAnalogSensorsPins)(int Pin, int Val),
                int Dec, char *StrUnit, boolean Ok);
        void IniBroken(int PosFirstParm, char *StrId, int PinIncr, int PinDecr,
                boolean DoIncreaseDefault, boolean DoDecreaseDefault, boolean increaseHIGH, boolean decreaseHIGH);

Declaro dos atributos privados booleanos denominados _increaseHIGH y _decreaseHIGH y almaceno el valor recibido para ya tenerlo disponible en el objeto.

A su vez obviamente los valores default para el modo seguro cambia su lógica, hay que hacer un XOR con los valores recibidos para determinar cómo se activa o desactiva.

Código:

_DoIncreaseDefault = DoIncreaseDefault == increaseHIGH;
    _DoDecreaseDefault = DoDecreaseDefault == decreaseHIGH;

Y luego ya modificar los métodos de UpdateIncrement y UpdateDecrement para aplicar la lógica

Código:

void Cao1_Sensor::_UpdateDecrement(){
        if (_PinDecr<=0){   // Si el Pin NO viene con un valor positivo no hay decrementador
                            // asociado al sensor.  implementar acciones por defecto (safe mode)
            digitalWrite(_PinDecr, _DoDecreaseDefault);
            return;
        }
        // Tratamiento de de dimeo de decrementadores analógicos (ejemplo ventilación regulable)
        if (Pin_PWM_Motor(_PinDecr) ){
            _HandAnalogSensorsPins(_PinDecr, _Val);
            return;
        }
        // Conectar decrementador cuando sea necesario
        if (_Val > GetP_High()+GetP_Hist()){ // Superior al máximo recomendable
            digitalWrite(_PinDecr, _decreaseHIGH ? HIGH : LOW);
            return;
        }
        // Desconectar decrementador cuando ya no sea necesario
        if (_Val < GetP_High()-GetP_Hist()){ // Deja de estar por encima de lo recomendable
            digitalWrite(_PinDecr, _decreaseHIGH ? LOW : HIGH);
            return;
        }
}


// *******************************************************************************************
// Tratamiento sobre el incrementador asociado al sensor si tal fuera el caso
// *******************************************************************************************
void Cao1_Sensor::_UpdateIncrement(){
        if (_PinIncr<=0){   // Si el Pin NO viene con un valor positivo no hay incrementador
                            // asociado al sensor.  implementar acciones por defecto (safe mode)
            digitalWrite(_PinIncr, _DoIncreaseDefault);
            return;
        }
        // Tratamiento de de dimeo de incrementadores analógicos
        if (Pin_PWM_Motor(_PinIncr) ){ // Actualmente no se contemplan increment analógicos pero por si acaso
            _HandAnalogSensorsPins(_PinIncr, _Val);
            return;
        }
        // Conectar incrementador cuando sea necesario
        if (_Val <GetP_Low()-GetP_Hist()){ // Inferior al minimo recomendable
            digitalWrite(_PinIncr, _increaseHIGH ? HIGH : LOW);
            return;
        }
        // Desconectar incrementador cuando ya no sea necesario (hemos invertido la lógica, desconectamos a alta)
        if (_Val >GetP_Low()+GetP_Hist()){ // Deja de estar por debajo de lo recomendable
            digitalWrite(_PinIncr, _increaseHIGH ? LOW : HIGH);
            return;
        }
}

Y ya solo queda configurar apropiadamente cada activador en el .ino según queramos.

En mi caso quedaría así

Código:

// *** Controlador Temperatura acuario *********************
    if (PosSensTempAcua==-1){
        LCD.PrintLn_Ser(SerFmt.Fmt(F("NO Sens.Temp.Acuario")));
        SensTempAcua.IniBroken(EP_MIN_TMP_ACU, "TAc", Pin_ReleCalefAcua, PinDecrTempAcua, true, false, true, false);
    }
    else{
        LCD.PrintLn_Ser(SerFmt.Fmt(F("OK Sens.Temp.Acuario")));
        LCD.PrintLn_Ser(ADDR_DS18X20_TEMP_ACUA);
        NumSensTemp--; // descontar 1 sensor de temp localizado
        SensTempAcua.Ini(EP_MIN_TMP_ACU, "TAc", Pin_ReleCalefAcua, PinDecrTempAcua, true, false, true, false,
                GetTempAcu, HandDecrTempAcua, 1, StrUnitSensor, true);
    }
    // *** Controlador temperatura LEDs **********************
    if (PosSensTempLEDs==-1){
        LCD.PrintLn_Ser(SerFmt.Fmt(F("NO Sens.Temp.LEDs")));
        SensTempLeds.IniBroken( EP_MIN_TMP_LED, "TLd", 0, PinDecrTempLeds, false, true, false, false);
    }
    else{
        LCD.PrintLn_Ser(SerFmt.Fmt(F("OK Sens.Temp.LEDs")));
        LCD.PrintLn_Ser(ADDR_DS18X20_TEMP_LEDS);
        NumSensTemp--; // descontar 1 sensor de temp localizado
        SensTempLeds.Ini( EP_MIN_TMP_LED, "TLd",  0, PinDecrTempLeds, false, true, false, false,
                GetTempLeds, HandDecrTempLeds, 1, StrUnitSensor, true);
    }

Ya ya está, así puedo tener el calentador en normalmente cerrado y si se jode arduino y se apaga, o la fuente de alimentación, el calentador seguiría funcionando con su propio termostato tradicional.

[Antonio Castro]

Como no veo forma de configurar cada pin, he hecho una pequeña modificación para contemplarlo.

Los métodos de inicialización de Cao1_Sensor los he ampliado con dos parámetros booleanos: increaseHIGH y decreaseHIGH. Estos indicarán respectivamente si el incrementador o el decrementador se activan a HIGH (true) o a LOW (false).

[...]

No digo que sea mejor, pero hay soluciones hardware. Los actuadores digitales (controlados por niveles lógicos HIGH/LOW para conectarlos/desconectarlos), pueden ser controlados por relés y en ellos puedes tomar la salida activa con el bobinado en reposo o con el bobinado activo. También puedes añadir un inversor TTL de la serie 74xx a la salida del pin.

El modo SAFE (seguro) puede ser HIGH o LOW. Por ejemplo para el sensor de temperatura de los LEDS de iluminación lo seguro es el refrigerador activado.

En cualquier caso, tener una necesidad concreta y solucionarlo personalizando el software me parece perfecto y compartirlo con los demás mejor aún.

Ya me contarás que tal te va con esa modificación software.

[Agamenon]

Como no veo forma de configurar cada pin, he hecho una pequeña modificación para contemplarlo.

Los métodos de inicialización de Cao1_Sensor los he ampliado con dos parámetros booleanos: increaseHIGH y decreaseHIGH. Estos indicarán respectivamente si el incrementador o el decrementador se activan a HIGH (true) o a LOW (false).

[...]

No digo que sea mejor, pero hay soluciones hardware. Los actuadores digitales (controlados por niveles lógicos HIGH/LOW para conectarlos/desconectarlos), pueden ser controlados por relés y en ellos puedes tomar la salida activa con el bobinado en reposo o con el bobinado activo. También puedes añadir un inversor TTL de la serie 74xx a la salida del pin.

El modo SAFE (seguro) puede ser HIGH o LOW. Por ejemplo para el sensor de temperatura de los LEDS de iluminación lo seguro es el refrigerador activado.

En cualquier caso, tener una necesidad concreta y solucionarlo personalizando el software me parece perfecto y compartirlo con los demás mejor aún.

Ya me contarás que tal te va con esa modificación software.

Hombre a mi personalmente me parecía más cómodo añadir ese pequeño cambio en el software para soportar personalizar si se activa a alta o a baja cada activador antes que meterme en más componentes hardware... que demasiados tengo ya en el sistema.

Compartir las modificaciones con los demás creo que es la filosofía de una licencia CC, así cualquiera puede elegir con qué versión y qué cambios se queda para su proyecto.

De hecho, lo ideal sería que estuviese versionado en una herramiento tipo GitHub. Nunca te lo has planteado Antonio? así cualquiera podría instalarse tu versión normal, o hacer un fork con sus propios cambios, y todas las versiones serían públicas y clonables desde git.

[Antonio Castro]

Compartir las modificaciones con los demás creo que es la filosofía de una licencia CC, así cualquiera puede elegir con qué versión y qué cambios se queda para su proyecto.

De hecho, lo ideal sería que estuviese versionado en una herramiento tipo GitHub. Nunca te lo has planteado Antonio? así cualquiera podría instalarse tu versión normal, o hacer un fork con sus propios cambios, y todas las versiones serían públicas y clonables desde git.

Ya tuvimos esta conversación no solo sobre Github sino sobre Eclipse. Mi forma de trabajar es la que me va mejor a mí, pero tampoco es cuestión de ponerme a dar lecciones a nadie. Cada cual es libre de elegir las herramientas que quiera y de compartir su trabajo o no en la forma que prefiera.

Cada persona o grupo de personas que use mi software es libre de trabajarlo como quiera y la forma en que yo trabaje es cosa mía. Lo digo así porque no es fácil de explicar. Mi forma de trabajar no tiene que ver solo con la parte del código que es donde menos esfuerzo tengo que hacer últimamente. Dentro de una semana publicaré un vídeo que ilustra mi forma de trabajar en estos proyectos y quizás se entienda mejor lo que acabo de decir.

Aquí no estamos trabajando con algoritmos complicados, y una vez que se tiene claro lo que quieres hacer y como lo quieres hacer, la codificación suele ser relativamente sencilla.

[Agamenon]

Vamos, gestiona tu proyecto como quieras. Pero el control de versiones a día de hoy es algo muy recomendable para cualquier proyecto, sea más o menos complejo. Y GitHub para proyectos públicos es gratuito. Es sencillo para cualquiera hacerse un clone del repositorio y crearse un fork para meter sus propios cambios. El control de versiones además permite volver atrás en caso de generar algún error, comprobar diferencias de código entre ramas, y un largo etc.

Yo de hecho tengo CAO en un git local para poder trabajar de forma más ágil con él y sus cambios. Mi sugerencia iba a que si lo ponías en GitHub sería más sencillo para todo el mundo.

Parece que te sientas atacado Antonio cada vez que se te sugiere algo, y nada más lejos de la realidad. Los que vivimos en el mundo del desarrollo software sabemos que es nuestra obligación estar actualizándonos continuamente y que la forma de trabajar que hoy damos por buena mañana ya está obsoleta. Nadie me habría dicho hace unos años que prestaría tanta atención a los patrones de diseño, y hoy en día SOLID y sus principios se ha convertido en una religión, es ley de vida.

[Antonio Castro]

Vamos, gestiona tu proyecto como quieras. Pero el control de versiones a día de hoy es algo muy recomendable para cualquier proyecto, sea más o menos complejo. Y GitHub para proyectos públicos es gratuito. Es sencillo para cualquiera hacerse un clone del repositorio y crearse un fork para meter sus propios cambios. El control de versiones además permite volver atrás en caso de generar algún error, comprobar diferencias de código entre ramas, y un largo etc.

Yo de hecho tengo CAO en un git local para poder trabajar de forma más ágil con él y sus cambios. Mi sugerencia iba a que si lo ponías en GitHub sería más sencillo para todo el mundo.

Parece que te sientas atacado Antonio cada vez que se te sugiere algo, y nada más lejos de la realidad. Los que vivimos en el mundo del desarrollo software sabemos que es nuestra obligación estar actualizándonos continuamente y que la forma de trabajar que hoy damos por buena mañana ya está obsoleta. Nadie me habría dicho hace unos años que prestaría tanta atención a los patrones de diseño, y hoy en día SOLID y sus principios se ha convertido en una religión, es ley de vida.

Esta conversación ya la hemos tenido antes y ya te dije que he trabajado con subversión. Conozco algo el tema y aunque Git sea mejor, tengo mismo motivos para organizarme a mi manera y un no me apetece debería bastarte. Esta insistencia tuya no la entiendo. Espera una semana y quizás entiendas donde se me van las horas de esfuerzo.

[bokeron_84]

buenas antonio llevo leido 50 paginas del post, es super interesante. Estoy empezando con el mundo arduino. Antonio si sigues por aqui me gustaria hacerte una pregunta, el programa del CAO se podria modificar para una pantalla de Leds dimeada con tip141 una sonda de temperatura con 4 ventiladores y dos reles para temporizar unos tubos? con una pantalla LCD de 20x04

[Antonio Castro]

buenas antonio llevo leído 50 paginas del post, es super interesante. Estoy empezando con el mundo arduino. Antonio si sigues por aqui me gustaria hacerte una pregunta, el programa del CAO se podria modificar para una pantalla de Leds dimeada con tip141 una sonda de temperatura con 4 ventiladores y dos reles para temporizar unos tubos? con una pantalla LCD de 20x04

Para el programa da lo mismo usar transistores TIP141 (que son los que se mencionan en la documentación de CAO) o alguna opción mejor como transistores MOSFET.

Las modificaciones a la programación de CAO, claro que se pueden hacer todas las que quieras y las puedes luego publicar donde quieras. Es software libre.

Lo que actualmente no está contemplado es la programación de tubos con relés en función del fotoperiodo. Lo más fácil sería usar lo que hay ahora programando los tubos como una tarea a una hora fija.

Existen toda una serie de mejoras que fueros surgiendo puntualmente sobre la versión 1.1.x pero no existe una versión estable porque lo que tengo para la versión 1.2.x origina muchos Warnings usando los IDEs actuales. Corregir esos avisos molestos del compilador no es difícil. El problema es que después de hacer tantas correcciones sobre algo que ya usa bastante gente,habría que volver hacer muchas pruebas intensivas sobre toda la aplicación.

A mí no me importa que a nivel particular la gente trabaje sobre mi software haciendo mejoras, todo lo contrario, pero ahora mi forma de ver el control de acuarios es diferente. Veo más interesante hacer controladores independientes y especializados y no quiero desviarme de mis nuevos objetivos porque aunque van algo lentos, pero van bastante bien.

Hasta aquí la contestación a las cuestiones concretas que me preguntas, pero voy a aprovechar para explicar ciertos cambios en mi disponibilidad para ayudas.

Si has leído 50 páginas, habrás visto la forma en que me he volcado en toda clase de ayudas particulares con todo el que lo ha necesitado. Mi tiempo disponible para todo ello ha disminuido porque necesito hacer avanzar más mis proyectos.

Por ello la cuestión es si tú tienes la capacidad para hacer las mejoras, o si necesitas ayuda, porque la programación es algo que consume bastante tiempo y en este momento lo único que yo podría hacer, sería orientarte lo mejor que pueda resolviendo dudas y cosas así, pero programar a la carta para cubrir las necesidades particulares de alguien, ya no.

Eso es algo que me ha supuesto un tipo de carga que por desgracia ya no me puedo permitir (con una excepción para una persona que me ha aportado muchísimo). Por desgracia esto es así. Yo disfruto mucho la interactividad recibida que siempre me porta ideas, pero he hecho balance de mi trabajo el los últimos meses.

Valorando la cantidad de trabajo que he hecho para los demás y la cantidad de trabajo que he hecho para mí mismo me doy cuenta de que me tengo que centrar un poco más en mis propias metas porque me he dispersado demasiado últimamente y eso me ha perjudicado en mi productividad. Creí que podía con varios proyectos en marcha, pero se ve que para eso me estoy haciendo mayor.

Trabajo de forma mucho más eficiente cuando me centro en uno o dos proyectos nada más.

[bokeron_84]

Antonio ante todo muchísimas por responder y por el pedazo de curro que te has dado. Si he visto que hacías todo por la gente y me parece totalmente lícito que tu tiempo lo inviertas en ti y en tus proyectos, faltaría más.
Yo no tengo conocimientos de programación por eso te preguntaba si se podía hacer pero claro de una manera sencilla. Pues a lo mejor eliminando módulos en el sketch completo o algo así para evitar programar.
Gracias un saludo

[Antonio Castro]

Antonio ante todo muchísimas por responder y por el pedazo de curro que te has dado. Si he visto que hacías todo por la gente y me parece totalmente lícito que tu tiempo lo inviertas en ti y en tus proyectos, faltaría más.
Yo no tengo conocimientos de programación por eso te preguntaba si se podía hacer pero claro de una manera sencilla. Pues a lo mejor eliminando módulos en el sketch completo o algo así para evitar programar.
Gracias un saludo

Me parece una estupenda forma de adaptar un software a lo que cada uno necesite.

Hay una serie de módulos que intervienen en el interfaz de la aplicación y que no se pueden eliminar. Otros módulos tienen dependencia de otros, pero algunos simplemente dan soporte a un tipo de elementos que quizás no te interesen.

Haz una lista con los módulos que tu crees que no necesitas y yo te diré si puedes prescindir de ellos.

Una vez que prescindas de ellos obtendrás algunos errores cuando CAO intente usarlos en alguna parte, pero seguramente con eso te está diciendo el compilador donde están las lineas de código que ya no necesitas y que se han quedado..., digamos huérfanas.

También existirán algunos menús que no necesitarás.

Con la aplicación simplificada te será más fácil manejarte con ella, pero más allá del corta y pega, algo de programación vas a necesitar.

Por lo que que dijiste antes no parece que necesites mucho. La funcionalidad de añadir un relé quizás se pueda apañar incluso con alguna chapucilla en el código que usara algunos de los canales de dimeado. Por ejemplo usar un pinficticio para el dimeado de cierto canal y luego usar un criterio de comparación para activar el relé en otro pin, por encima de cierto valor de dimeado.

Atrévete y date un tiempo. No pierdes nada con intentarlo.

[edzvlogs]

Hola buenas noches compañeros, quisiera preguntar y saber si alguien tiene el diagrama completo de todas las conexiones del CAO1 de Don Antonio Castro o el Dimmer1, estoy pensando en hacer una placa totalmente completa.

Saludos