"Miguel Gimenez" <me***privacy.net> escribió en el mensaje
news:fuhthc$fij$1***aioe.org...
>
> ¿Estás dejando tiempos muertos al conmutar el L298? Si no lo haces habrá
> un cortocircuito de unas décimas de us cada vez que cambie de estado, que
> provocará un salto de tensión (primero hacia abajo y después hacia arriba)
> en la fuente y llegará directamente al micro (los 7805 no responden
> demasiado bién a escalones). Añade (o aumenta) los tiempos muertos y pon
> un condensador de 100 nF directamente en los bornes de alimentación del
> L298.
>

pues no dejo tiempos muertos, no. Miraré de ponerlos ahora. El condensador
sí que está puesto.

Muchas gracias

"Pepitof" <jose.mgg***terra.es> escribió en el mensaje
news:673c4sF2n9rajU1***mid.individual.net...
> Pues si quitando motores sigue reseteándose, la respuesta viene a ser la
> de
> siempre.
>
> 1º. Problema software. Como el reseteo es aleatorio, y suponiendo que el
> programa lo has escrito en C, habrá que suponer que no es un timer
> contando
> sin control, ni un salto a la página incorrecta, ni nada parecido, pero sí
> podría ser por ejemplo que hayas configurado una patilla de reset y no la
> hayas conectado. En ese caso, cuando reciba un pico de ruido
> suficientemente
> grande (por radio), reseteará. También podría pasar algo parecido si
> tienes
> un timer configurado por error con un clock externo.
>

me repasaré a fondo el código, ya que estoy reutilizando algo que alguien
creó en su día

> 2º. Problema hardware. Lo que te han dicho, ruido en la alimentación, es
> la
> causa más común. La solución, separar alimentaciones de potencia y lógica,
> sobredimensionar condensadores de filtro, añadir un condensadore de filtro
> de 100nF a la alimentación del PIC, lo más cerca posible de él, asegurar
> que
> las pistas de alimentación y masa están correctamente dimensionadas y
> trazadas, y que no sean compartidas por el circuito de potencia y el
> lógico.
>

ahora estoy rediseñando la placa para separar circuitos.

> Luego ya podría haber problemas más sutiles, como un acoplamiento
> incorrecto
> entre el PIC y otros chips (una resistencia en cada puerto utilizado que
> limite la corriente máxima a 15mA puede hacer milagros).
>
> Otro problema típico con control de motores mediante puentes H es no dejar
> tiempo suficiente para la conmutación en cada rama de la H, con lo que
> puedes tener corrientes instantáneas muy altas, cercanas a cortocircuito,
> que echen abajo la alimentación (esto además seguiría pasando aunque
> quitaras los motores).
>

lo que comenta Miguel. Lo miraré

> En fin, ya nos dirás.
>

muchas gracias a los dos

"Pepitof" <jose.mgg***terra.es> escribió en el mensaje
news:673c4sF2n9rajU1***mid.individual.net...
> Pues si quitando motores sigue reseteándose, la respuesta viene a ser la
> de
> siempre.
>
> 1º. Problema software. Como el reseteo es aleatorio, y suponiendo que el
> programa lo has escrito en C, habrá que suponer que no es un timer
> contando
> sin control, ni un salto a la página incorrecta, ni nada parecido, pero sí
> podría ser por ejemplo que hayas configurado una patilla de reset y no la
> hayas conectado. En ese caso, cuando reciba un pico de ruido
> suficientemente
> grande (por radio), reseteará. También podría pasar algo parecido si
> tienes
> un timer configurado por error con un clock externo.
>

me repasaré a fondo el código, ya que estoy reutilizando algo que alguien
creó en su día

> 2º. Problema hardware. Lo que te han dicho, ruido en la alimentación, es
> la
> causa más común. La solución, separar alimentaciones de potencia y lógica,
> sobredimensionar condensadores de filtro, añadir un condensadore de filtro
> de 100nF a la alimentación del PIC, lo más cerca posible de él, asegurar
> que
> las pistas de alimentación y masa están correctamente dimensionadas y
> trazadas, y que no sean compartidas por el circuito de potencia y el
> lógico.
>

ahora estoy rediseñando la placa para separar circuitos.

> Luego ya podría haber problemas más sutiles, como un acoplamiento
> incorrecto
> entre el PIC y otros chips (una resistencia en cada puerto utilizado que
> limite la corriente máxima a 15mA puede hacer milagros).
>
> Otro problema típico con control de motores mediante puentes H es no dejar
> tiempo suficiente para la conmutación en cada rama de la H, con lo que
> puedes tener corrientes instantáneas muy altas, cercanas a cortocircuito,
> que echen abajo la alimentación (esto además seguiría pasando aunque
> quitaras los motores).
>

lo que comenta Miguel. Lo miraré

> En fin, ya nos dirás.
>

muchas gracias a los dos

Bueno, poniendo tiempos muertos en las conmutaciones del L298 mejora algo.
En la placa antigua, ha llegado a fallar un par de veces en bastante tiempo.

En la placa nueva ha seguido fallando, si están los motores conectados.
Desconectando uno o los dos motores, ha dejado de reiniciarse.

La placa nueva de la antigua se diferencia en que la nueva integra toda la
circuitería en una única placa, mientras que la antigua es una placa para la
alimentación, PIC y motores y después conectores para la electrónica de
sensores, comunicaciones y demás.

A ver si hago la prueba separando circuitos a ver qué pasa



"jugator EChMotor#140" <jugator***gmail.com> escribió en el mensaje
news:fuhqir$hvv$1***localhost.localdomain...
> en concreto un PIC18F452.
>[...]

Bueno, poniendo tiempos muertos en las conmutaciones del L298 mejora algo.
En la placa antigua, ha llegado a fallar un par de veces en bastante tiempo.

En la placa nueva ha seguido fallando, si están los motores conectados.
Desconectando uno o los dos motores, ha dejado de reiniciarse.

La placa nueva de la antigua se diferencia en que la nueva integra toda la
circuitería en una única placa, mientras que la antigua es una placa para la
alimentación, PIC y motores y después conectores para la electrónica de
sensores, comunicaciones y demás.

A ver si hago la prueba separando circuitos a ver qué pasa



"jugator EChMotor#140" <jugator***gmail.com> escribió en el mensaje
news:fuhqir$hvv$1***localhost.localdomain...
> en concreto un PIC18F452.
>[...]

Pienso que puede ser por el consumo de los motores, que mete un pico en la
alimentación.
Las masas de los distintos circuitos, motores y baterias deberian ir a un
punto (gordo)único y la alimentación (positivo) de la bateria y del L298 y
los motores desacoplarlos con una pequeña bobinita toroidal y un par de
condensadores formando un filtro paso bajo en "pi". Esto es lo que se me
ocurre. Yo tengo un robot con un pic 16F876 y lo tengo montado así.

"jugator EChMotor#140" <jugator***gmail.com> wrote in message
news:fuial2$pga$1***localhost.localdomain...
> Bueno, poniendo tiempos muertos en las conmutaciones del L298 mejora algo.
> En la placa antigua, ha llegado a fallar un par de veces en bastante
tiempo.
>
> En la placa nueva ha seguido fallando, si están los motores conectados.
> Desconectando uno o los dos motores, ha dejado de reiniciarse.
>
> La placa nueva de la antigua se diferencia en que la nueva integra toda la
> circuitería en una única placa, mientras que la antigua es una placa para
la
> alimentación, PIC y motores y después conectores para la electrónica de
> sensores, comunicaciones y demás.
>
> A ver si hago la prueba separando circuitos a ver qué pasa
>
>
>
> "jugator EChMotor#140" <jugator***gmail.com> escribió en el mensaje
> news:fuhqir$hvv$1***localhost.localdomain...
> > en concreto un PIC18F452.
> >[...]
>
>

Pienso que puede ser por el consumo de los motores, que mete un pico en la
alimentación.
Las masas de los distintos circuitos, motores y baterias deberian ir a un
punto (gordo)único y la alimentación (positivo) de la bateria y del L298 y
los motores desacoplarlos con una pequeña bobinita toroidal y un par de
condensadores formando un filtro paso bajo en "pi". Esto es lo que se me
ocurre. Yo tengo un robot con un pic 16F876 y lo tengo montado así.

"jugator EChMotor#140" <jugator***gmail.com> wrote in message
news:fuial2$pga$1***localhost.localdomain...
> Bueno, poniendo tiempos muertos en las conmutaciones del L298 mejora algo.
> En la placa antigua, ha llegado a fallar un par de veces en bastante
tiempo.
>
> En la placa nueva ha seguido fallando, si están los motores conectados.
> Desconectando uno o los dos motores, ha dejado de reiniciarse.
>
> La placa nueva de la antigua se diferencia en que la nueva integra toda la
> circuitería en una única placa, mientras que la antigua es una placa para
la
> alimentación, PIC y motores y después conectores para la electrónica de
> sensores, comunicaciones y demás.
>
> A ver si hago la prueba separando circuitos a ver qué pasa
>
>
>
> "jugator EChMotor#140" <jugator***gmail.com> escribió en el mensaje
> news:fuhqir$hvv$1***localhost.localdomain...
> > en concreto un PIC18F452.
> >[...]
>
>

bueno, pues por ahora el tema se ha solucionado soldando unos condensadores
ceramicos justo en los pines de alimentación del PIC. Los que hay en la
placa son de poliéster, y el diseño que hice como que no favorece demasiado
que el camino sea el mas corto posible entre condensadores y pins de los
integrados.

Así que ahora a modificar el diseño y ale, a funcionar.

gracias!

"jugator EChMotor#140" <jugator***gmail.com> escribió en el mensaje
news:fuhqir$hvv$1***localhost.localdomain...
> en concreto un PIC18F452.
>
> El tema es que lo tengo montado para controlar un pequeño robot. Algo
> sencillo, un sensor de colisión, dos sensores de temperatura sobre I2C,
> dos motores de contínua con un L298, comunicación por RS232 y poca cosa
> más.
>
> Hasta ahora funcionaba bien (o eso creía). El tema es que ahora le estoy
> haciendo que su comportamiento lo marque una máquina de estados finitos
> (FSM), y he visto que cada tanto el PIC se reinicia (iba a decir que sólo,
> pero no, si se reinicia es que hay un fallo de diseño en el circuito, en
> la programación o yo qué sé), por lo que a tomar la FSM.
>
> Por cierto, los reinicios son aleatorios, no pasan cada un cierto tiempo
> determinado, y suceden en dos placas diferentes en diseño físico
> (distribución de elementos y pistas) pero iguales en diseño lógico.
>
> La pregunta es, qué puede provocar que un PIC se reinicie?
>

bueno, pues por ahora el tema se ha solucionado soldando unos condensadores
ceramicos justo en los pines de alimentación del PIC. Los que hay en la
placa son de poliéster, y el diseño que hice como que no favorece demasiado
que el camino sea el mas corto posible entre condensadores y pins de los
integrados.

Así que ahora a modificar el diseño y ale, a funcionar.

gracias!

"jugator EChMotor#140" <jugator***gmail.com> escribió en el mensaje
news:fuhqir$hvv$1***localhost.localdomain...
> en concreto un PIC18F452.
>
> El tema es que lo tengo montado para controlar un pequeño robot. Algo
> sencillo, un sensor de colisión, dos sensores de temperatura sobre I2C,
> dos motores de contínua con un L298, comunicación por RS232 y poca cosa
> más.
>
> Hasta ahora funcionaba bien (o eso creía). El tema es que ahora le estoy
> haciendo que su comportamiento lo marque una máquina de estados finitos
> (FSM), y he visto que cada tanto el PIC se reinicia (iba a decir que sólo,
> pero no, si se reinicia es que hay un fallo de diseño en el circuito, en
> la programación o yo qué sé), por lo que a tomar la FSM.
>
> Por cierto, los reinicios son aleatorios, no pasan cada un cierto tiempo
> determinado, y suceden en dos placas diferentes en diseño físico
> (distribución de elementos y pistas) pero iguales en diseño lógico.
>
> La pregunta es, qué puede provocar que un PIC se reinicie?
>

"Observer" <xx***yyzz.es> escribió en el mensaje
news:Nq5Pj.44282$zi5.30489***news.ono.com...
> Pienso que puede ser por el consumo de los motores, que mete un pico en la
> alimentación.
> Las masas de los distintos circuitos, motores y baterias deberian ir a un
> punto (gordo)único y la alimentación (positivo) de la bateria y del L298 y
> los motores desacoplarlos con una pequeña bobinita toroidal y un par de
> condensadores formando un filtro paso bajo en "pi". Esto es lo que se me
> ocurre. Yo tengo un robot con un pic 16F876 y lo tengo montado así.
>

se me había pasado este mensaje. En principio parece estar solucionado, pero
tomo nota por si finalmente los problemas persisten.

gracias