Diagnóstico de Sistemas del Motor con Scope, Analizador y Scan Tool

La versión corta — Un scan tool (escáner de diagnóstico) te dice lo que el módulo cree que está pasando a través de PIDs y códigos, pero un scope (osciloscopio) te muestra lo que realmente está pasando eléctricamente, en tiempo real. Tienes que saber cuándo un código o un PID no es suficiente y necesitas ver la forma de onda real.

Scan Tool vs. Scope — Trabajos Diferentes

Un scan tool se comunica con los módulos de control del vehículo a través del data bus (bus de datos). Te muestra PIDs en vivo — lecturas de sensores, valores calculados, comandos a actuadores — y puede sacar o borrar DTCs (códigos de falla) y freeze frame data (datos de cuadro congelado). Muchos scan tools también pueden correr bidirectional tests (pruebas bidireccionales), o sea que puedes comandar un relay, inyector, o actuador para que cicle a demanda en vez de solo observarlo reaccionar.

Pero el scan tool tiene un punto ciego: normalmente te muestra un solo valor promediado o momentáneo, actualizado unas cuantas veces por segundo. Muchos problemas reales pasan más rápido que eso.

Un osciloscopio muestra el voltaje a través del tiempo como una forma de onda (waveform). En vez de un solo número, ves la forma, amplitud, y el timing de la señal. Esto importa porque el switching del inyector, el disparo primario/secundario de encendido, los pulsos del sensor de cigüeñal/árbol de levas (crank/cam sensor), y la comunicación de red pasan demasiado rápido para que un multímetro o el refresh rate de un PID del scan tool te lo muestren claramente. Si solo le echas un vistazo a una lectura del DMM o a un PID del scan tool, puedes pasar por alto completamente un glitch que está causando una queja de manejo (driveability).

Un engine analyzer (analizador de motor) es básicamente un scope hecho para trabajo de motor — combina canales de scope con pickups de encendido y funciones de RPM/timing, permitiéndote evaluar los patrones de encendido primario y secundario y ver la contribución relativa de potencia por cilindro (detección de misfire) en todos los cilindros a la vez.

Leyendo Formas de Onda: Cómo se Ve lo Bueno y lo Malo

Las formas de onda del inyector muestran un pico de voltaje cuando la bobina del inyector se desenergiza — esto es el inductive kick (patada inductiva). La altura y forma de ese pico te dice sobre la condición del devanado, mientras que el on-time (ancho de pulso) refleja cuánto tiempo se está comandando el flujo de combustible. Un pico ausente o irregular apunta a una bobina de inyector abierta o en corto, o a un driver malo en el PCM/módulo.

Los patrones de encendido (primario y secundario) tienen firmas conocidas de falla:

• Una firing line (línea de disparo) baja o errática apunta a una bobina débil o resistencia alta en una bujía o cable de bujía.
• Una spark line (línea de chispa) extendida o inestable apunta a una condición pobre o rica de mezcla, o a un misfire real.

Las pruebas de compresión relativa / forma de onda de cranking usan current ramp (rampa de corriente) o capturas de scope mientras se hace cranking para comparar el patrón de consumo de corriente o voltaje cilindro por cilindro. Esto te deja detectar un cilindro débil o sin compresión sin sacar las bujías — un verdadero ahorro de tiempo en trabajos donde el acceso a las bujías es una lata.

Las señales de network/data bus (como los pares diferenciales de bus usados para la comunicación entre módulos) necesitan revisarse con el scope para verificar niveles de voltaje correctos, simetría de la señal, y ausencia de ruido o reflexiones. Esto importa porque el scan tool por sí solo puede reportar solamente un código genérico de "no communication" (sin comunicación) — no puede mostrarte por qué el bus está fallando. La causa de fondo puede ser un corto en el bus, un circuito abierto, o un módulo atascado en modo de sleep (reposo) o en falla, y solo un scope te revela con cuál de estos estás lidiando.

Cuando el Scan Tool No es Suficiente

Aquí hay una trampa que vale la pena conocer bien: un sensor puede fallar de una manera que produce un valor plausible-pero-incorrecto — una lectura dentro de rango que sigue estando mal. Como el valor nunca sale del rango de voltaje esperado, el módulo no tiene razón para poner un DTC. El scan tool te va a mostrar un número que se ve normal y nada más. La única forma de agarrar esto es cruzar ese PID contra una lectura de osciloscopio o multímetro graficador de la señal real del sensor.

Esto también es por qué el timing importa cuando capturas una forma de onda. Necesitas capturarla bajo la condición que realmente reproduce la queja del cliente — bajo carga, a un RPM específico, en un arranque en frío, lo que sea que lo dispare. Las fallas intermitentes muchas veces se esconden en ralentí (idle) o con la llave en on y el motor apagado, entonces una captura que se ve limpia en ralentí no limpia la pieza; solo significa que probaste la condición equivocada.

Fácil de Confundir

• Firing line baja/errática vs. spark line extendida/inestable — ambas son problemas del secundario de encendido, pero apuntan en direcciones diferentes. Una firing line débil apunta a la bobina o resistencia alta en el camino bujía/cable. Una spark line extendida o inestable apunta a una condición de combustible (pobre/rica) o a un misfire activo. No le eches la culpa a la bobina automáticamente por cada anomalía en el secundario — mira qué parte del patrón está mal.
• DTC de "no communication" vs. falla eléctrica del bus — el código solo te dice que la comunicación falló. No te dice si la causa es un corto, un abierto, o un módulo dormido/fallado. Ese diagnóstico requiere un scope sobre la señal del bus mismo.
• Falla de sensor dentro de rango vs. falla que dispara código — una lectura de sensor que técnicamente está dentro de rango pero está mal no va a poner un DTC. No asumas que "sin códigos" significa que el sensor está bueno; cruza con un scope o multímetro graficador cuando el PID no cuadra con el síntoma.

Verifícate

Pregunta: Un cliente se queja de un stumble (tartamudeo/falla) intermitente bajo carga que nunca aparece cuando escaneas códigos o miras PIDs en ralentí. ¿Cuál es el siguiente paso correcto y por qué?

Captura una forma de onda bajo la condición real que produce la queja — bajo carga, al RPM donde pasa, no en ralentí. Muchas fallas intermitentes simplemente no aparecen en ralentí o con key-on-engine-off, entonces probar bajo la condición equivocada te da un resultado limpio pero sin sentido.

Pregunta: Technician A dice que un DTC de "no communication" siempre significa que el módulo mismo está malo. Technician B dice que el código solo indica una falla de comunicación, y que se necesita un scope en el data bus para averiguar si es un corto, un abierto, o un módulo en modo sleep/falla. ¿Quién tiene la razón?

Technician B tiene la razón. El scan tool solo reporta que la comunicación falló — no revela la causa eléctrica de fondo. Necesitas hacer scope de la señal del bus para chequear niveles de voltaje, simetría, y ruido/reflexiones para determinar la falla real.

Pregunta: ¿Por qué la prueba de compresión relativa no puede decirte la condición del cilindro usando solo un DMM, pero un scope o current ramp sí puede?

Un DMM solo muestra un valor promediado, no la forma del consumo de corriente o voltaje a través del tiempo. La prueba de compresión relativa compara el patrón de consumo de corriente/voltaje de cranking cilindro por cilindro, y se necesita un scope (o current ramp) para ver ese patrón e identificar un cilindro débil o sin compresión sin quitar las bujías.