Hola a todos.
Estoy haciendo un programa para un estabilizador y quisiera determinar que salida de un autotransformador debe activarse.
El control de la tension de entrada lo estoy haciendo con el canal analogico 0 del PIC para hacer los cortes por subtension o sobretension. Esta parte funciona correctamente(170V a 268V).
El problema se me presenta al intentar hacer las conmutaciones con base en la lectura de la tension de salida mediante el canal analogico1.
Mi programa usa una interrupcion por cambio de nivel en uno de los pines del PIC. Al producirse la interrupcion se activa la salida correspondiente del autotransformador y se lee por el canal 1 la tension de salida. Los valores leidos para cada salida del autotransformador los estoy guardando en la EEPROM del PIC. Estos valores son muy cercanos a 220V.
Esto es porque para cada salida, la conmutacion se hace cuando en la entrada tengo un nivel de tension tal que a la salida correspondiente tenga 220V.
Pensaba usar esas lecturas equivalentes a 220V y hacer las conmutaciones restando 4V y sumando 13V para que la salida se mantenga
entre 216V y 233V pero no lo he podido hacer bien.
RC2,RC3,RC4 y RC5 se activan pero en los intervalos incorrectos y solo al encender el equipo. Si voy variando la tension llega un punto en el cual se desactivan y los demas se activan secuencialmente hasta que se apaga y ya no hace nada. RC0 y RC1 nunca se activan.
Dejo el fragmento del programa por si lo pueden checar y hacerme las correcciones de las cosas que estan mal. Gracias.
combinacion=0b00000001;
PORTC = combinacion; // Habilitar pin RC0
Control:
obtenerPico(0); // Leer tension de entrada
if(valorPico<310 || valorPico>496) //310 a 170V y 496 a 268V
{
goto InhibirTriacs; //Si el voltaje de entrada esta fuera de rango se inhiben los triacs.
}
else if( valorPico > 325 && valorPico < 449) // Si la tension de entrada esta dentro del rango medir la tension de salida
{
for(direccion=10;direccion>=0;direccion-=2)
{
obtenerPico(1); // Leer tension de retroalimentacion del canal 1
lecturaAlmacenada = EEPROM_Read_Int(direccion); // Leer EEPROM en la direccion actual y asignar valor a
// lecturaAlmacenada
if(valorPico > (lecturaAlmacenada-13) && valorPico < (lecturaAlmacenada+45)) // 13 es equivalente a 4V y 45 a 13V
{
break;
}
else
{
combinacion<<=1;
PORTC=combinacion; // habilitar siguiente combinacion
}
} // for
} // else if
goto Control;
Con un canal del ADC leo la entrada y controle que este entre 170V y 268V. Aquí no tengo problema.
Lo que no se es como controlar que triac activar para que la tension de Salida este entre 212V y 229V. Es un estabilizador de lazo cerrado ya que la muestra para el control de Los triacs la tomo de la salida una vez conectado el triac.
He visto que hay otros que con las muestras de entrada controlan los triacs pero yo necesito uno que lo haga tomando muestras de la salida. La muestra de entrada la uso solo para controlar subtension o sobretension.
No tiene ningún sentido monitorear la salida cuando tenes un autotransformador.
La relacion es fija y por lo tanto para no hacer mas cálculos de los necesarios, es mejor solo controlar la entrada.
Sabiendo que si esta dentro de ciertos rangos la tension, activar o desactivar los reles. En los estabilizadores mas simples esto se realiza con unos AO
2 Reles y tenes tu selector de 3 a 1
Y estaria faltando tambien una salida al autotrasformador que es la salida de alimentación del circuito de control.
Hola a todos gracias por su tiempo.
El circuito de control esta alimentado con otra salida del autotransformador.
Hice un Sistema que me mida la tension en la carga porque lei que esto lo hace mas robusto si cambia la carga. Segun averigué leyendo solo la tension de entrada podría tener problemas si la carga cambia.
Logre que regule pero cuando se apaga por subtension y subo el voltaje para que vuelva a regular ya no vuelve a encender y se queda apagado aunque debiera estar regulando. Solo pasa en el corte por subtension; del corte por sobretension si retorna con normalidad. No sé si falte mejorar la regulacion.
Hola, no entiendo muy bien el problema, pero lo que si te recomiendo es no usar 'goto' en lenguaje C.
El tema del GOTO arranca el día que a Dijkstra se le ocurrió escribir "Go To Statement Considered Harmful". A partir de ahí un ejército de adoradores rechazó el GOTO con argumentos falaces como que genera un código espagueti ilegible mientras que con programación estructurada son mas legibles. Vamos! que un código espagueti es tan ilegible como uno estructurado donde las llaves que se abren se cierran dos páginas después, por bien indentado que esté.
La ilegibilidad no la dá el goto sino su abuso y las etiquetas poco descriptivas, y lo mismo pasa con el anidamiento excesivo de if, whiles, etc.
El problema de los GOTO no es que fallen o que dejen de funcionar, la pega es que para entender un programa diseñado así hay que rastrear los saltos y, si no está muy bien hecho, es fácil perderse.
Con programación estructurada, como se propone en lenguajes como C o Pascal, todo el flujo de funcionamiento queda mucho más ordenado.
Pero para gustos, los colores. Puedes seguir usando el GOTO si lo prefieres.
Supongo que depende de la complejidad del programa, encontrar en una libreria un goto seria ya el colmo porque una libreria se compone de bastantes funciones que es facil evitar un goto porque son muy pocas lineas de pogramacion para cada funcion, pero imaginate un programa de 32k o 64k, la de programacion que hay ahi metida, seria de bastante logica que se usen gotos.
Supongo que depende de la complejidad del programa, encontrar en una libreria un goto seria ya el colmo porque una libreria se compone de bastantes funciones que es facil evitar un goto porque son muy pocas lineas de pogramacion para cada funcion, pero imaginate un programa de 32k o 64k, la de programacion que hay ahi metida, seria de bastante logica que se usen gotos.
Uso Basic después de dejar el ensamblador y la verdad es que Basic me permitió hacer todo lo que antes no podía hacer. Exactamente uso PROTON IDE y es genial, no perfecto pero si bastante bueno y fácil de aprender ... me sorprende que poca gente lo use.
Uso Basic después de dejar el ensamblador y la verdad es que Basic me permitió hacer todo lo que antes no podía hacer. Exactamente uso PROTON IDE y es genial, no perfecto pero si bastante bueno y fácil de aprender ... me sorprende que poca gente lo use.
Yo ya no lo uso tanto por 2 temas, realmente no he dejado de usarlo, pero hay que evolucionar aunque sea tarde, 1º por un simple tema de velocidad, todas las funciones rutinas o lo que tengas en un programa en Basic, con el mismo programa en C se ejecuta bastante mas rapido, pero bastante.
Y 2º por la cantidad de usuarios que usan uno u otro, decir que esta mas muerto que el sumerio es evidente que es una exageracion de la realidad pero es algo que sucede dia a dia, cada dia son menos los que usan Basic y mas los que usan C, y en la facilidad de usar Basic te doy toda la razon, es de una simpleza tan sorprendente que es raro que no se haya impuesto al resto, pero bueno, en nuestro mundo es asi, cuanto mas facil, menos interesa.
Yo aconsejo leer este libro para aprender a desarrollar código mantenible y legible.
A mí me encantó leerlo y releerlo. Es bastante práctico y la mayoría del texto sirve para cualquier lenguaje.
- Tienes que ingresar para ver archivos adjuntos -
https://www.amazon.es/C%C3%B3digo-Limpio-desarrollo-software-Programaci%C3%B3n/dp/8441532109/
(También existe versión "digital")
Edito: Comentario de Amazon
"Cada año, se invierten innumerables horas y se pierden numerosos recursos debido a código mal escrito, ralentizando el desarrollo, disminuyendo la productividad, generando graves fallos e incluso pudiendo acabar con la organización o empresa. El reconocido experto de software Robert C. Martin, junto con sus colegas de Object Mentor, nos presentan sus óptimas técnicas y metodologías ágiles para limpiar el código sobre la marcha y crearlo de forma correcta, de este modo mejorará como programador. Esta obra se divide en tres partes. La primera describe los principios, patrones y prácticas para crear código limpio. La segunda incluye varios casos de estudio cuya complejidad va aumentando. Cada ejemplo es un ejercicio de limpieza y transformación de código con problemas. La tercera parte del libro contiene una lista de heurística y síntomas de código erróneo (smells) confeccionada al crear los casos prácticos. El resultado es una base de conocimientos que describe cómo pensamos cuando creamos, leemos y limpiamos código. Imprescindible para cualquier desarrollador, ingeniero de software, director de proyectos, jefe de equipo o analista de sistemas interesado en crear código de mejor calidad. ¡El libro que todo programador debe leer!"