Este tipo de problema (donde tiene dos "canales" supuestamente idénticos y uno está funcionando pero el otro no está funcionando) es fácil de resolver cuando tiene el Equipo en tus manos. Encuentre la (s) diferencia (es). Debe haber diferencia (es) entre los dos canales, ¡de lo contrario su comportamiento sería realmente idéntico!
Vale la pena señalar que las diferencias pueden estar ocultas debido a una suposición errónea. Por ejemplo, en su caso, está asumiendo que los motores tienen especificaciones idénticas y, por lo tanto, son idénticos. De hecho, un motor podría ser diferente al otro, p. Ej. etiquetado incorrecto, fabricación defectuosa, dañado por el uso anterior, etc. Así que siempre verifique y haga una lista de sus supuestos .
Dos enfoques para encontrar diferencias que son muy adecuados para principiantes incluyen:
-
Mueva los dispositivos / módulos, uno a la vez , del canal "defectuoso" al canal "operativo" y compruebe si:
(a) el problema persiste con el canal original que "falla" (entonces el problema es no el componente que movió al otro canal), o
(b) el problema se mueve con el componente al otro canal (entonces el problema está relacionado con el componente que movió, aunque podría no ser el componente sí mismo , pero conectores, cableado, etc. que estaban relacionados con el traslado).
Un riesgo para este enfoque es que al alterar las conexiones eléctricas para mover componentes entre canales, puede cambiar el problema, o puede desaparecer, sin que sepa por qué (por ejemplo, puede arreglar una conexión de alta resistencia cuando mueve un alambre).
O:
-
Realice mediciones relevantes entre los dos canales, para encontrar dónde está la diferencia. En su caso, esto incluiría mediciones con DMM y 'alcance para ver si las señales PWM supuestamente idénticas que se envían para impulsar los dos motores son realmente idénticas. Si no, puede usar mediciones adicionales para reducir no importa si la causa es hardware o software (generación PWM).
Este enfoque tiene menos riesgo de perturbar la causa del problema que la opción 1 anterior (es una mala noticia si el problema "desaparece" sin que usted sepa por qué, ¡porque podría volver en el futuro!) pero requiere equipo de prueba y capacidad de interpretar las medidas.
La resolución de problemas no se enseña lo suficiente en muchos cursos de ingeniería. Aprenda técnicas de localización de fallas en cada oportunidad y agréguelas a su biblioteca personal para usarlas más adelante. Algunas buenas técnicas formales son enseñadas por Kepner-Tregoe y otros. He simplificado (sobre) su enfoque en mi ejemplo anterior. Esas técnicas simplificadas a menudo no serían apropiadas en casos más complejos.
Un ejemplo (no oficial) del enfoque Kepner-Tregoe "IS / IS NOT" está disponible aquí: enlace Si bien es un ejemplo de software (TI), puede ver cómo se prueban las causas posible para ver si coinciden con la descripción del problema y otros datos.