Informe de viaje a Alemania, junio de 1982

Título: Informe de viaje FPS DIS MTU

Reparto de personajes

Personal de FPS USA:
Robert Wallace, héroe
Dan Gorton, ingeniero de soporte de campo
Dave Borer, ingeniero de aplicaciones de software

Personal de FPS Alemania:
Reinhardt Albrecht, gerente de soporte de hardware
Otros variados

Personal de la MTU:
Dr. Gerhard Sieger, contacto del cliente (responsable de la aplicación mediante el sistema DIS)
Lutz Koegler, programador responsable de la codificación del sistema DIS
Klaus Schedl, jefe del Dr. Siegers

Personal de traducción de datos:
Walt Bastow, ingeniero principal a cargo del DIS
Dan Sulivan, jefe alternativo de Bastows y familiarizado con algunos de los equipos DIS
Fred Molinari, presidente de Data Translation

Equipo:
AP120B y un DIS con:

• ADC
• DAC
• QBT
• ADC DPM
• DAC DPM

PDP 11/34 funcionando con RSX 11M rev 3.2

Sinopsis:

Se trata básicamente de la historia de un ingeniero de software de diagnóstico desprevenido que es enviado a Munich, Alemania, para ayudar en la instalación de un nuevo y emocionante producto FPS (el DIS). Narra las aventuras y los contratiempos que ocurren y, con suerte, desarrolla una moraleja.

Acto 1, La primera semana

Escena 1, Portland

Lunes 26 de abril de 1982.

Esta escena comienza con nuestro héroe, yo mismo, acostado en la cama con un resfriado terrible. Recibo una llamada de mi jefe, Rich Watson. Me pregunta si me gustaría ir a Alemania. Le pregunto cuándo. Responde: "¿Hoy?".

Le respondo: “Creo que no”. Él pregunta: “¿Mañana?”

Tras pensarlo mucho, decido hacer el sacrificio. Me levanto de la cama y empiezo a organizar el viaje.

Tengo dos cintas grabadas con el software de diagnóstico actual del DIS. Compré mis billetes de avión. Inicialmente, mi ausencia estaba prevista para una semana aproximadamente. (El problema que informa Dan Gorton es que DISVER, un programa de prueba del sistema creado por el grupo de aplicaciones, siempre muestra ceros en lugar de los voltajes de entrada convertidos de analógico a digital).

Surge la cuestión del dinero. Tuve una tarjeta VISA de empresa, pero tuve que devolverla en una purga. Dado que planeo estar ausente por un corto tiempo, la cantidad de 500 dólares me parece adecuada. El presentimiento de un desastre inminente me impulsa a duplicar la cifra a 1000 dólares.

Martes 27 de abril de 1982

Salgo del Aeropuerto Internacional de Portland con destino a Múnich y la gloria. El viaje transcurre sin incidentes, salvo por un pequeño incidente en Nueva York. Como desconozco los rigores de la aduana alemana, decidí actuar conforme a las normas y llevar las dos cintas magnéticas que tenía. En Portland, el personal de tráfico de la FPS me entregó la documentación que declaraba que las cintas eran solo para fines educativos y que las traería conmigo de vuelta a Estados Unidos. Al consultar con la aduana de Nueva York, descubro que se trata de la burocracia federal. Parece que los documentos que tengo no son los formularios correctos, así que tengo que rellenar otros. También me informan de que si no devuelvo los formularios a la aduana a mi regreso, me multarán.

Escena 2, Múnich

Miércoles 28 de abril de 1982

Llegué a Múnich a las 9:00. Naturalmente, a la aduana alemana no le interesaba en absoluto nada de lo que trajera al país. Me esperaban en el aeropuerto Dan Gorton y Reinhardt Albrecht. Decidí que no tenía sentido ir al hotel de inmediato, así que nos dirigimos a la sede del cliente. Para llegar, tuve que pedirle al personal de seguridad que nos emitiera credenciales y un pase para el coche. Ninguno de los guardias de seguridad hablaba inglés. (Antes de irme a casa, me recibirían con una sonrisa y un "¡Ay...! ¡Puaj!").

Me llevan de vuelta al laboratorio de ingeniería donde se encuentra el hardware. El entorno de trabajo es bastante deficiente. La sala es estrecha, con un largo banco de trabajo a lo largo de una pared. Al otro lado de la sala, junto a la ventana, se encuentran el AP120 y el DIS en un rack. Junto al 120 hay un rack con el 11/34 y dos unidades de disco RLOL. El sistema no tiene unidad de cinta. Junto al 11/34 hay dos Decwriters. Frente al AP, en el banco de trabajo, hay un terminal tipo VT100. Los dos aspectos destacables del laboratorio son la escasez de espacio, especialmente cerca del DIS, y la falta de aire acondicionado.

Me presentan al Dr. Sieger y a Lutz Koegler. Pasé la mañana con Dan Gorton, quien me puso al día sobre el problema. Mi primera impresión fue que probablemente el problema estaba relacionado con el hardware. El software que estaban ejecutando se había ejecutado en Portland. Los síntomas de ceros en la pantalla parecían indicar que la conversión no se iniciaba o no terminaba, generando la interrupción que descargaba los datos del DPM del ADC a los datos principales del AP120. Mi primera suposición fue que el problema podría ser un PLA defectuoso en el ADC.

Jueves 29 de abril de 1982

Pasé el día probando las tarjetas ADC, DPM y QBT intentando comprender qué debía hacer el hardware. Una dificultad residía en los esquemas que teníamos. No estaban diseñados al estilo FPS estándar, sino que eran similares a los esquemas DEC. Esto dificultaba mucho su uso y comprensión. No había referencias directas ni inversas entre las señales, y era difícil saber exactamente de dónde provenía una señal ni adónde iba. Durante este tiempo, las placas se conectaban a un extensor y se desconectaban. (Nota: ¡El cliente nos suministró una tarjeta extensora y nos FABRICÓ un cable extensor! No se envió nada con la unidad. No se enviaron esquemas con la unidad. Los esquemas que estábamos usando fueron traídos a Múnich por Dan Gorton. No todos los esquemas coincidían con los niveles de revoluciones de las placas. Un gran problema al usar los esquemas del ADC era que los esquemas referenciaban las piezas en la placa con un sistema de números de letra 'U', es decir, U37. Sin embargo, la serigrafía en la placa usaba un sistema de filas y columnas, es decir, BS).

Viernes 30 de abril de 1982

Durante el análisis de las placas y el uso de GPDBUG, descubrí que el código IOCAL se bloqueaba a menudo en una posición incorrecta. Al obtener listados del código IOCAL y del DIOR, y al usar GPDBUG, descubrí que el DIOR se bloqueaba en una instrucción de giro. Esta instrucción se ejecuta durante la búsqueda de la siguiente instrucción IOCAL por parte del DIOR. Un análisis más detallado muestra que el bloqueo se produce en la instrucción siguiente a la instrucción IOCAL VECTOR. Para comprobar esta hipótesis, sustituí la instrucción vector por el código equivalente a cuatro instrucciones MOV y ejecuté el programa. ¡Funciona!

Sábado 1 de mayo de 1982

Visité el Museo Alemán con Dan.

Domingo 2 de mayo de 1982

Visitó el campo de concentración en DachauUn lugar muy deprimente. Después visitamos el palacio de Nymphenburg Para animar.

Lunes 3 de mayo de 1982

DISVER seguía ejecutándose. Reemplacé las cuatro instrucciones MOV con la instrucción VECTOR y el programa falló con los mismos síntomas que antes. Al reinstalar los movimientos, se solucionó el problema. El Dr. Sieger y Lutz Koegler nos lo demostraron.

El cliente nos mostró el código de su aplicación. El código se había ensamblado en APAL sin errores, pero el código objeto ensamblado contenía instrucciones de salto que no se habían ensamblado con las direcciones correctas. Analicé el código y el ensamblador y descubrí que el problema se debía al uso de una instrucción FSUB como impulso para el sumador. El problema se solucionó usando FADD para los impulsos. Llamé a Portland y hablé con Mark Haverkamp, quien me comentó que él también había tenido este problema y que se había escrito una solicitud de acción técnica (TAR) al respecto.

El problema final que el cliente quería que analizáramos era un programa de prueba que Lutz Koegler había escrito para verificar que la tarjeta de reloj programable funcionaría en el modo en que querían usarla. El programa consistía en un FORTRAN Línea principal que iniciaba una rutina IOCAL que configuraba e iniciaba el reloj programable. El síntoma era que el reloj arrancaba pero luego se detenía. El problema radicaba en que la línea principal de FORTRAN no esperaba a que el GPIOP terminara de ejecutarse, sino que FORTRAN simplemente iniciaba el GPIOP procesando el código IOCAL y luego salía al sistema operativo. Sospeché que, al regresar FORTRAN al sistema operativo, se estaba reiniciando el AP (¿quizás desasignándolo?). El reinicio detenía el GPIOP. Coloqué una instrucción de pausa de FORTRAN antes de la salida del programa y el reloj programable funcionó correctamente.

Martes 4 de mayo de 1982

Volé a París de vacaciones. Pasé una semana allí, alojándome en el apartamento de Michel y Viannette Rouillard. Fue una semana muy agradable que pasé explorando París a pie. Michel me invitó a pasar otra semana en un velero de 11 metros con él y cuatro de sus amigos. Dudé, pues sabía que el deber me llamaba de vuelta en Estados Unidos. Esta vacilación duró unos veintitrés nanosegundos, luego recuperé la cordura y dije que sí. La semana siguiente fue una de las más agradables de mi vida. Por suerte, durante ese tiempo no sabía qué me depararía el futuro en Múnich.

Fin del acto 1

Acto 2, Múnich de nuevo

Escena 1, Algo sale mal

Sábado 15 de mayo de 1982

Al llegar a París, me esperaba un montón de mensajes preguntándome dónde estaba. En resumen, decían que MTU no funcionaba y que el cliente no estaba satisfecho. Me preparé para volar de vuelta a Múnich.

Lunes 17 de mayo de 1982

Volé de regreso a Múnich por la tarde. El alojamiento lo gestiona la oficina alemana del FPS con el hotel Hilton.

Martes 18 de mayo de 1982

Primero hablo con Reinhardt Albrecht, quien está muy preocupado por la situación. Me informa que el cliente está muy enfadado y ha estado acusando a FPS de manipular el software para que pareciera que se ejecutaba la prueba de aceptación.

Fuimos al sitio y hablamos con el cliente. Lutz Koegler me mostró una lista de DISVER (la prueba del sistema ADC) y me informó sobre los errores de código que encontró. Examiné el código y verifiqué que contenía errores de programación. La naturaleza de los errores era tal que no se detectarían al ejecutar el programa. Lutz los descubrió al intentar usar DISVER como ejemplo de programación del DIS. (Obviamente, no tenía experiencia previa con software FPS; de lo contrario, probablemente no habría usado ese enfoque).

Había dos errores importantes en el código. Uno era que el código debía precargar el multiplexor para la primera transferencia A/D en modo cadena. El comentario indicaba que esto ocurría, pero el código no lo hacía. El segundo error se encontraba al calcular las ubicaciones iniciales del búfer en el DPM. La forma en que DISVER calculaba el segundo búfer provocaba que este se superpusiera con una parte del primero. Esto no era evidente al ejecutar DISVER, ya que los datos del primer y segundo búfer eran siempre los mismos (proporcionados por el dispositivo de prueba). Consideré que estos errores no eran graves y que el programa seguía indicando que el ADC funcionaba.

El problema era que, tras corregir estos errores y con las modificaciones del código realizadas por los clientes, el programa no generaba los resultados correctos. Con ocho canales diferentes muestreados y distintos voltajes en cada uno, la salida parecía indicar que el primer canal se muestreaba dos veces o que los canales estaban desviados. Dedicamos más tiempo a revisar el código línea por línea en busca de más errores de software. No encontramos ninguno más.

Pasé el día probando las placas con el osciloscopio y el analizador lógico. Descubrí que dos de las señales de protocolo de enlace del DPM del ADC que iban al ADC no terminaban en este. Como ingeniero de software versátil, saqué un soldador del bolsillo (de hecho, el cliente me proporcionó un soldador digital bastante sofisticado) y conecté los dos cables necesarios a la placa del ADC. Esto limpió las señales, pero no afectó los síntomas originales. Cuanto más investigaba, más me convencía de que estaba ante un problema de hardware real y que probablemente estaba fuera de mi alcance (sin doble sentido). Llamé a Wayne Matterson en Portland para informarle y sugerí que llamaran a Data Translation.

Miércoles 19 de mayo de 1982

Hablé con Portland y me dijeron que Traducción de Datos enviaría a Dan Sulivan a otro sitio y que saldría de Boston temprano para visitar la MTU y evaluar la situación. De ser necesario, Walt Bastow también se preparaba para venir. Pasé el día probando las placas y escribiendo programas de prueba para los modos de escaneo, ráfaga y PIO.

Jueves 20 de mayo de 1982

Vacaciones en Alemania. El Dr. Sieger me llevó de paseo por los Alpes.

Esta noche descubro que el Hilton no sabe que la oficina alemana del FPS se hace cargo de la factura. Parece que quieren dinero. Intento explicarles que no tengo dinero. Esto parece molestarlos. Prometo que mañana me encargaré de la factura.

Viernes 21 de mayo de 1982

Lo primero que hago es contactar con la oficina alemana para comunicarles mi problema con el hotel. Me dicen que habían enviado un télex al Hilton indicando que les facturaran, así que no sabían qué pasaba. Pero me aseguraron que se encargarían del asunto.

Llegó Dan Sulivan. Él y yo continuamos revisando las placas y aislamos el problema en el DPM del ADC. El problema estaba relacionado con la sincronización del contador de direcciones en el modo de escaneo del ADC. Dan primero intentó ajustar la sincronización añadiendo una línea de retardo hecha con condensadores y resistencias. Desistimos de la línea de retardo al ver que no obteníamos suficiente retardo. Esa noche, al analizar el problema en papel, Dan decidió que el problema no era que la señal necesitara retardo, sino que se sincronizaba en el flanco incorrecto y que para solucionarlo solo era necesario invertir la señal.

Sábado 22 de mayo de 1982

Logramos trabajar medio día en la obra. Esto fue difícil debido a los problemas con los sindicatos. Dan implementó su solución con un parche al hardware y el software de prueba pareció funcionar.

Para celebrarlo, Dan y yo fuimos a Salzburgo. De camino, recogimos a dos mujeres que hacían autostop. Eran monjas. Eran encantadoras; la mayor (de unos 63 años) hablaba un poco de inglés. La otra solo hablaba alemán. Las llevamos a la residencia donde viven con otras cuatro hermanas de su orden. Vivían cerca de la frontera con Austria. Tomamos un café y Dan y yo seguimos hasta Salzburgo.

Domingo 23 de mayo de 1982

Llegó Walt Bastow. Dan y yo lo recogimos en el aeropuerto y pasamos la tarde analizando diferentes soluciones al problema del DPM del ADC que Dan había solucionado.

Lunes 24 de mayo de 1982

Walt eliminó los parches e implementó una solución permanente. Esto solucionó el problema del ADC en modo de escaneo. Esperábamos que la solución también solucionara cualquier problema con el DAC. Empezamos a revisar el DAC funcionando en modo de escaneo. Trabajé en añadir el código del DAC al programa de prueba. Las cosas no pintaban bien. El DAC no funcionaba. La actitud de los clientes empezó a cambiar de esperanza a algo menos que eso.

Tengo que dejar el Hilton y mudarme al Sheriton, donde se hospeda Walt. Me comunico con la oficina alemana de FPS para que se encarguen de la factura.

Martes 25 de mayo de 1982

Walt y yo seguimos analizando el problema. Parece estar relacionado con el chip secuenciador. Walt observa que el chip secuenciador de la placa del cliente no tiene el nivel de revoluciones actual. No cree que eso explique el problema, pero como tenemos un secuenciador de repuesto con el nuevo nivel de revoluciones, decidimos probarlo. El nuevo secuenciador tampoco funcionó, pero cambió algunos aspectos que estábamos analizando.

Miércoles 26 de mayo de 1982

Seguimos solucionando el problema. Llegamos esta mañana y nada funcionaba igual que cuando nos fuimos anoche. Pasamos el día intentando restaurar el sistema a los mismos síntomas que experimentábamos. La confianza de los clientes está desplomándose.

Creo que ese fue el día en que Fred Molinari llegó con un módulo ADC de repuesto. El ADC original del cliente se había averiado antes de mi llegada y lo habían reemplazado por uno de repuesto de la oficina alemana. El módulo original era de entrada diferencial, mientras que el de repuesto era de un solo extremo. Fred Molinari trajo lo que se creía que era un módulo de entrada diferencial, pero cuando lo recibimos resultó ser otro de un solo extremo.

Jueves 27 de mayo de 1982

Logramos que el sistema se comportara de forma similar al martes. Pasamos la mayor parte del día trabajando con el nuevo secuenciador de revoluciones. Finalmente, decidimos que el nuevo secuenciador estaba defectuoso (un fallo en un componente). Volvimos al secuenciador antiguo. Walt llamó a Traducción de Datos y les pidió que enviaran un secuenciador de reemplazo. Conectamos las 32 líneas del analizador lógico al chip del secuenciador antiguo y a las señales relacionadas, y comenzamos a intentar determinar qué estaba haciendo el secuenciador antiguo. (Más tarde, el Dr. Sieger me confiesa que cuando vio el analizador conectado así a un circuito integrado, perdió toda confianza en que el sistema funcionara).

Viernes 28 de mayo de 1982

Walt está convencido de que el problema reside en la lógica del secuenciador. Pasamos la mayor parte del día revisando manualmente los estados del secuenciador. Finalmente, descubrimos un estado lógico defectuoso. Walt cree que puede solucionarlo in situ, ya que solo requiere fundir un fusible dentro del secuenciador. Llamamos a Portland para averiguar el procedimiento y descubrimos que es demasiado difícil de intentar. Walt llamó a Data Translation y mandó fabricar un nuevo chip secuenciador con la solución. El Dr. Sieger nos invita a Walt y a mí a su casa en Colonia. Viaja los fines de semana entre Colonia y Múnich, una distancia de unos 480 kilómetros. Los Sieger viven en un pequeño pueblo a unos 15 kilómetros de Colonia, cerca de una extensa zona boscosa. Pasamos un fin de semana agradable con el Dr. Sieger, su esposa e hijos. El sábado por la tarde caminamos unos cuatro kilómetros por el bosque hasta la catedral de Attenberg.

Domingo 30 de mayo de 1982

Margot (la esposa del Dr. Sieger) está en Holanda tomando clases de vela. El Dr. Sieger, Walt y yo visitamos la famosa catedral de Colonia. También visitamos el museo romano junto a la catedral. Colonia es una de las ciudades más antiguas de Alemania, construida por los romanos. Luego fuimos en coche a Holanda para encontrarnos con Margot y cenar. (Es curioso ver que el Dr. Sieger tiene los mismos problemas con el idioma con los holandeses que nosotros con los alemanes).

Lunes 31 de mayo de 1982

Hoy es otro día festivo en Alemania. Damos un paseo por el bosque hasta un pequeño restaurante a unos diez kilómetros de su casa. Para nuestra sorpresa, encontramos una banda de Dixie Land tocando en la terraza del restaurante. Más tarde esa noche, regresamos a Múnich.

Escena 2, Munich, otra semana

Martes 1 de junio de 1982

Recibimos el primer chip secuenciador de repuesto solicitado. Sin embargo, no nos sirve de nada, ya que descubrimos la mala programación del chip. Pasamos el día trabajando en PIO. Encontramos un error extraño en IOCAL. La salida del código de la aplicación del cliente tiene dos etiquetas diferentes con el mismo valor asignado. Todas las demás etiquetas, anteriores y posteriores, son correctas. Probamos el ensamblaje en otro sistema en una habitación más fría para verificar que no haya un problema de memoria o hardware en el PDP 11/34 y ocurre lo mismo.

Observo que hay una gran cantidad de símbolos y los cuento. El error ocurre en el símbolo número 100. [Obtengo el código fuente de IOCAL de la cinta de instalación y descubro que una de las matrices de la tabla de símbolos no está correctamente dimensionada. Lo corrijo, recompilo y ejecuto la tarea de compilación de IOCAL, y el error se soluciona.]

Walt y yo analizamos la sincronización PIO del DAC y descubrimos que no se puede usar una instrucción CBX para realizar una transferencia de varias palabras al DAC en modo PIO. El problema parece ser que, aunque el DIOR comprueba la disponibilidad de los datos en el QBT, este puede enviar datos al DAC a una velocidad superior a la que este puede procesar, y el DIOR no comprueba la disponibilidad de la tarjeta DAC.

Decido que esto es algo que puedo examinar a mi regreso a Portland (aunque en ese momento dudaba seriamente que volviera a ver mi tierra natal). Recodifico el programa IOCAL para que, en lugar de intentar hacer un CBX de varias palabras, haga un CBX de una sola palabra dentro de un bucle. Esto reduce considerablemente la eficiencia de la transferencia. (Medimos una configuración de 50 microsegundos en cada CBX). Mientras Lutz responde preguntas.

Miércoles 2 de junio de 1982

Llega el nuevo secuenciador y mejora los síntomas con la transferencia en modo escaneo. Seguimos analizando el problema y descubrimos que la placa DPM necesitará otro cambio para que gestione correctamente los datos del DAC. Walt realiza el cambio de hardware y, ¡gloria aleluya!, todo parece funcionar. Walt documentó todos los cambios que ha realizado.

Creo que ese fue el día en que finalmente recibimos un ADC de entrada diferencial de Data Translation. Walt lo instaló y verificó que era diferencial y funcionaba.

Jueves 3 de junio de 1982

Analizo detenidamente todos los programas en los que hemos trabajado y descubro que el programa que creía que funcionaba en modo ráfaga estaba en realidad programado para el modo de escaneo. Modifico el código y lo reconstruyo. Por supuesto, no funcionó. Walt y yo lo analizamos y descubrimos que, en modo ráfaga, si el tamaño del búfer es demasiado pequeño, el punto de acceso no tendrá tiempo de vaciar los datos del DPM antes de que el siguiente búfer empiece a sobrescribirlo. El punto de acceso puede vaciar el búfer el doble de rápido que el ADC o el DAC. Pero antes de que el punto de acceso arranque, hay una sobrecarga de software. Medimos la sobrecarga y probamos búferes de diferentes tamaños para determinar el tamaño mínimo necesario. Descubrimos que un búfer de 64 bits funciona.

El Sheriton me pide que pague la cuenta. Parece que no saben que la oficina alemana del Servicio de Protección Fronteriza (FPS) se encarga de ella. Parece que quieren dinero. Intento explicarles que no tengo dinero. Esto parece molestarlos. Prometo que mañana me encargaré de la cuenta.

Viernes 4 de junio de 1982

Lo primero que hago es contactar a la oficina alemana para comunicarles mi problema con el hotel. Me dicen que habían enviado una carta al Sheriton indicando que les facturaran, así que no sabían qué pasaba. Pero me aseguraron que se encargarían del asunto.

Dediqué tiempo a verificar que los programas de prueba siguieran funcionando. Luego trabajé con Lutz ayudándolo con el código de su aplicación. (La aplicación era muy interesante: el primer programa modelaba un motor a reacción, el segundo también lo hacía, pero con más detalle). Le mostré a Lutz algunas técnicas para acortar su código APAL y escribir un algoritmo para un aspecto del segundo modelo, para luego codificarlo en APAL. Walt conversó con el Dr. Sieger sobre cómo usar el DIS en futuras aplicaciones que requieran un alto rendimiento. El cliente parece satisfecho con el funcionamiento del sistema. Walt decide regresar a Boston mañana para asistir a la fiesta de cumpleaños de su hijo.

Sábado 5 de junio de 1982

Llevo a Walt al aeropuerto y me despido. Paso el día conduciendo por el campo, subiendo a los Alpes hasta Innsbruck. Me atormenta todo el día la sensación de que debería seguir por Austria y buscar asilo en Suiza. Regreso a Múnich al anochecer.

Domingo 6 de junio de 1982

Trabajé en mis notas para el informe de viaje.

Escena 3, La Gran Depresión

Lunes 7 de junio de 1982

Llegué al lugar con la intención de verificar que el sistema todavía estuviera en funcionamiento y despedirme de la gente allí.

Al entrar al laboratorio, vi al Dr. Sieger, Herr Schedl y Lutz reunidos alrededor del DIS, observando el osciloscopio. El Dr. Sieger me respondió con un "¿Has comprobado alguna vez los formatos de codificación del DAC?". Sentí una trampa y sospeché que ya sabía la respuesta. Efectivamente, los formatos de codificación (complemento a dos y desplazamiento binario) no funcionaban correctamente. Maldije en silencio a Walt Bastow por dejarme con la culpa.

Reabro el DIS y comienzo a analizar el problema. Los síntomas indicaban que, en formato de complemento a dos, si se introducía +n voltios, el DAC emitía -n voltios. En formato binario offset, una entrada de voltaje cero generaba +10 voltios y una salida de -10. Más nueve se asignaba a +1, más ocho a +2. Lo mismo ocurre con voltajes negativos.

Lo primero que descubrí fue que la documentación del bit usado para seleccionar el formato de codificación estaba al revés. Indicaba que, si el bit estaba activado, el formato era desfase binario. El desfase era complemento a dos. Debería haberse activado para complemento a dos y el desfase binario para desfase. Al descifrarlo, se hizo evidente que algo estaba invirtiendo los datos. Como no podía llamar a Traducción de Datos hasta las 14:00, conecté el osciloscopio y el analizador lógico y comencé a buscar algo incorrecto. Investigué para verificar que el circuito para gestionar el complemento a dos y el desfase binario fuera correcto, pero no encontré nada incorrecto en el DAC. A las 14:00 llamé a Walt de Traducción de Datos. Walt me devolvió la llamada y, durante las siguientes seis horas y media, me convertí en su guía telefónica.

A las 20:30, Traducción de Datos informó que había un problema. Dijeron que necesitaban revisarlo y que me contactarían al día siguiente. Huelga decir que el cliente estaba un poco molesto. (Sobre todo teniendo en cuenta que el fallo fue descubierto por el Sr. Schedl cuando el Dr. Sieger fue a demostrar que el sistema funcionaba). Supuse que, al revisar los niveles de voltaje en el osciloscopio, este se invirtió accidentalmente y nadie se dio cuenta. Lutz ideó el fallo en su software.

Martes 8 de junio de 1982

Llegué al sitio y encontré al Dr. Sieger hablando con su jefe, Klaus Schedl. Tras la partida de Schedl, el Dr. Sieger me contó que su jefe estaba muy disgustado por todo lo sucedido y que planeaba enviar un télex a la oficina alemana para expresar su opinión. Mientras esperaba noticias de Traducción de Datos, dediqué un tiempo a limpiar los controladores FORTRAN de los programas de prueba. Conecté las placas a extensores y conecté cables a varias señales clave para poder medir la velocidad del sistema. Los resultados se aproximaron bastante a lo que el Dr. Sieger había predicho basándose en la documentación del sistema.

A las 14:30 recibí una llamada de Walt Bastow. Descubrieron que habían usado transceptores de bus normales en lugar de inversores en el DAC (para la ruta del DPM al DAC). El Dr. Sieger comprobó que podíamos conseguir las piezas aquí, así que decidimos intentar reemplazarlas mañana.

Para completar mi día, Lutz me mostró que el IOCAL devolvía periódicamente un código de error "1". Esto fue interesante porque ese código de error nunca se usa en ninguna parte del sistema. Él y yo lo probamos y descubrimos que el código de error devuelto coincidía con el número de palabras del parámetro de lectura en la lista de llamadas. Es decir, si la llamada a APGET (en FORTRAN) solicitaba solo una palabra del AP, periódicamente no leíamos el código de error real (que siempre era cero), sino que recibíamos un "1" de APGET. Si se solicitaba una transferencia de dos o tres palabras, periódicamente el código de error se devolvía como un "2" o "3".

Obtuve la fuente de APGET y RUNDMA (que es llamado por APGET y los examiné pero no pude ver nada malo. Reemplacé la llamada a APGET con una llamada directa a RUNDMA y encontré que el error aún ocurría. Esto indicó que el problema estaba en RUNDMA.

Le dije al cliente que lo revisaría en Portland. (Empezaba a pensar que si tenía que solucionar todos los problemas que el cliente encontraba con un producto FPS, me quedaría allí para siempre. Claro que, si el cliente encontraba otro problema, quizá no habría sido mucho más).

Miércoles 9 de junio de 1982

El Dr. Sieger y el Sr. Schedl decidieron no arriesgarse a reemplazar los transceptores de bus. Consideraron que reemplazar dos circuitos integrados de veinte pines en una placa de grabado de seis capas era demasiado propenso a provocar otras fallas. Continuarán programando para solucionar el problema hasta que lleguen las nuevas placas. Le pedí a Lutz que grabara dos cintas de los UFD que contienen todo el código de prueba con el que hemos estado trabajando. El cliente me solicita que me quede hasta el lunes para asegurarme de que el sistema siga funcionando la próxima semana.

Jueves 10 de junio de 1982

Otro día festivo. Le pregunto al Dr. Sieger sobre sus vacaciones y su calendario de festivos. Me dice que la mayoría de la gente tiene treinta días de vacaciones y quince festivos al año. Si un festivo cae en jueves, el viernes también es festivo. Le digo que en EE. UU. a eso le llamamos desempleo. El Dr. Sieger me sugiere que me vaya del Sheriton y me mude con él. Tiene un bonito piso cerca de la Universidad de Michigan en Dachau. Acepto su oferta y me voy del Sheriton. Regresamos a Colonia para pasar el fin de semana con su familia.

Viernes 11 de junio de 1982

Pasemos el día caminando por el bosque hasta llegar a varios pequeños restaurantes. Regresamos a su casa y cenamos con algunos de sus amigos.

Sábado 12 de junio de 1982

Otro día en Colonia. Nos encontramos con los mismos amigos de la noche anterior y salimos a un pequeño teatro a ver a dos pantomimas francesas. Después cenamos en casa de los amigos.

Domingo 13 de junio de 1982

Pasé el día descansando. Cenamos agradablemente y después fuimos a escuchar un concierto del hijo de Sieger. Después, el Dr. Sieger y yo emprendimos el viaje de regreso a Múnich.

Lunes 14 de junio de 1982

Reviso el sistema y veo que sigue funcionando. El cliente parece satisfecho de que la aplicación se ejecutará. (Tenga en cuenta que esa frase es diferente de «El cliente está satisfecho y el sistema funciona correctamente»). Me dirijo a la oficina alemana y le informo a Reinhardt Albrecht que el cliente me estaba liberando de la esclavitud y que planeaba irme a casa.

Martes 15 de junio de 1982

Desayuno con el Dr. Sieger y luego me despido. Mi vuelo sale de Múnich a las 11:00. Voy temprano al aeropuerto para verificar mis billetes y descubro que las tarifas han subido a partir de hoy. Volver a casa costará otros 157,67 chelines. Un final perfecto. Por suerte, tengo suficiente efectivo y pago. Las siguientes 20 horas las paso en aviones y aeropuertos hasta que finalmente, a las 23:30, llego a Portland.

Fin del acto 2

Descanso

La siguiente lista de cambios a la
Las placas base de MTU están a la venta en
el vestíbulo. También en venta, a un precio ligeramente
El precio más bajo es la lista de ECO que
Proporcionar soluciones permanentes.

Acto 3, Reflexiones

Este acto consta de escenas ambientadas en escenarios oníricos y surrealistas. Cada escena contiene un tema único.

Escena 1, Las consecuencias en el lugar

Esta escena presenta un entorno desolado y estéril, quizás un escenario vacío con una iluminación nítida. Una voz computarizada en off procede a detallar los problemas pendientes que deben resolverse en el sitio.

Computadora:

Los siguientes problemas deben resolverse en MTU:

1) Es necesario conectar transceptores de bus inversor al DAC. (Es posible que Walt Bastow haya regresado al sitio para hacerlo).

2) GPDBUG se bloquea al intentar ejecutar el código de la aplicación del cliente desde el depurador.

3) APGET/RUNDMA devuelve intermitentemente un valor incorrecto.

4) El FSUB no puede usarse como impulso en el sumador flotante. Esto se debe a un problema con el ensamblador APAL.

5) FMUL;LDDA;DB=valor tiene un conflicto de campo no detectado por el ensamblador APAL. Por lo tanto, no se ejecuta FMUL.

6) La instrucción VECTOR en DIOR provoca un bloqueo en la siguiente instrucción. Aparentemente, esto se debe a un problema de sincronización de hardware en el GPIOP.

7) Las placas DAC, ADC y DPM deben reemplazarse por las nuevas placas tan pronto como estén disponibles las nuevas placas con las correcciones permanentes.

8) Es necesario instalar el nuevo software FPS. Este software consta principalmente del conjunto completo de diagnósticos para el DIS, un nuevo DACVER y DISVER con las correcciones, y nuevas pruebas del sistema para los modos de operación no probados.

Escena 2, Reflexiones sobre el DIS

En esta escena, el escenario está oscuro y la niebla se arremolina alrededor. Una sola luz ilumina un podio donde hay un hombre de pie. El podio está de frente al público.

Hombre:

Creo que cuando se verifica el diseño del hardware, la filosofía de intercambio de placas funcionará. Los requisitos de diseño de los diagnósticos no consistían en verificar y depurar el diseño del hardware, sino en aislar las fallas de hardware a nivel de placa. En MTU no contábamos con un conjunto completo de diagnósticos. Incluso si lo hubiéramos tenido, la situación no habría cambiado. Los diagnósticos habrían fallado incluso después de intercambiar las placas debido a fallas de diseño del hardware. La naturaleza de los diagnósticos (aislamiento a nivel de placa) y la naturaleza de las fallas de diseño eran tales que el proceso de depuración de las placas habría sido el mismo.

La situación en MTU podría haberse evitado si Data Translations hubiera verificado el diseño del hardware antes de enviarlo a FPS. También se habría evitado si FPS hubiera tenido más tiempo con el hardware antes de enviar las primeras unidades. El personal que trabajaba en el software (diagnóstico y aplicaciones) comenzaba a descubrir algunos problemas de diseño. Desafortunadamente, esto ocurrió después del envío de las primeras unidades, y los problemas se diagnosticaron inicialmente como dificultades para comprender cómo programar el DIS debido a la falta de documentación clara.

Tres aspectos del producto DIS.

a. Funcionalidad.

Tras trabajar con el DIS en campo con un cliente, considero que la funcionalidad del hardware es excelente. El Dr. Sieger comentó en varias ocasiones (incluso en los momentos más difíciles) que creía que si alguna vez lográbamos que las unidades funcionaran, se convertirían en uno de nuestros mejores productos. El Dr. Sieger, Walt Bastow y yo hablamos sobre sus aplicaciones para las unidades y quedó claro que el DIS es un sistema de adquisición de datos muy versátil. La única desventaja de esta versatilidad es la complejidad del hardware.

b. Usabilidad.

La complejidad del hardware y la falta de buena documentación dificultan enormemente el uso de este producto. Esto demuestra la habilidad de Lutz Koegler para programar el DIS, especialmente cuando no funcionaba correctamente. El principal problema con el DIS es que el hardware no puede ser invisible. Idealmente, el usuario debería simplemente iniciar una conversión A/D o D/A, y el hardware lo haría. En el DIS, el usuario debe realizar diferentes pasos según la dirección y el modo de transferencia de datos. Esto requiere conocer la función del hardware. Esto requiere documentación y ejemplos mucho mejores que los que existen actualmente.

Otro aspecto de la usabilidad es la falta de visibilidad del hardware real para el usuario. Al ayudar al Dr. Sieger con el código de su aplicación, se hizo evidente la importancia de poder ver en un osciloscopio o analizador lógico el hardware que realiza las funciones. Esto es especialmente cierto en problemas de adquisición de datos en tiempo real, donde el usuario necesita saber exactamente cuánto tiempo se está utilizando para la adquisición de datos y cuánto tiempo queda para el procesamiento. El Dr. Sieger mencionó que otros sistemas que ha visto cuentan con LED en el panel frontal o conexiones de osciloscopio para permitir esto. Logramos esta capacidad conectando cables a algunas señales y colgándolos del borde de las placas, donde se puede conectar un analizador lógico. (Una vez finalizado, se retiraron los cables). Si se están regrabando las placas, sugeriría que se examine la posibilidad de llevar algunas señales clave al borde de cada placa a algún tipo de conector y luego tener una opción en el panel frontal con LED y conexiones de osciloscopio.

c. Capacidad de prueba.

La capacidad de prueba del DIS es muy deficiente. Las placas ofrecen poca visibilidad de diagnóstico. Gran parte del hardware depende del modo, lo que significa que las unidades básicas de hardware actuarán de forma diferente según el modo de operación en el que esté configurada la unidad. Creo que, para garantizar la detección de fallos y proporcionar mejores ejemplos de programación del DIS, es necesario desarrollar una biblioteca de pruebas de sistema que se aproxime a las aplicaciones de usuario. Estas pruebas dependerán de la configuración específica del DIS bajo prueba. Por ejemplo, una prueba podría ser similar a los programas utilizados en MTU, que requieren una configuración de hardware que incluya un PCG, un ADC con DPM y un DAC con DPM. Obviamente, esta prueba de sistema solo podría ejecutarse en un sistema con la configuración de hardware adecuada.

Escena 3, Actitudes del cliente

En esta escena, el protagonista camina lentamente por el escenario y habla con el público. Detrás de él, se ven ampliaciones de los folletos de marketing del DIS. Sus últimas líneas se pronuncian justo después de salir del escenario.

Nuestro principal contacto con el cliente fue a través del Dr. Sieger, quien gestionaba el proyecto de desarrollo que utilizaba el sistema AP. Su actitud hacia FPS Alemania era de irritación. Me comentó que la oficina alemana le había informado de que ya había muchas unidades DIS en uso, tanto en EE. UU. como en Europa. Obviamente, no era así. Parecía haber una mala relación entre el equipo de ventas de la oficina alemana y el cliente. Aunque hablé con el vendedor por teléfono varias veces, nunca lo vi en las instalaciones. El Dr. Sieger comentó que la única vez que el vendedor venía a MTU era para firmar el contrato de compraventa de equipos. (El Dr. Sieger también comentó que el personal de soporte técnico con el que tenía experiencia parecía ser muy bueno).

El Dr. Sieger fue de gran ayuda en la resolución de problemas del sistema. No solo nos proporcionó equipos de prueba y repuestos (circuitos integrados, cables, analizadores lógicos, etc.), sino que también intentó no presionarnos. Expresó su confianza en Walt y en mis capacidades y nos dejó solos para hacer el trabajo. (Su confianza se vio afectada cuando Walt y yo intentábamos depurar dentro del chip secuenciador). Sin embargo, pude ver su preocupación cuando las cosas no pintaban bien. Había comprometido su proyecto con el AP120 y el DIS, y si no lográbamos que funcionara, iba a tener problemas.

Lo que fue muy agradable fue que se interesó mucho por Walt y por mí. Nos llevó a su casa en Colonia. Nos invitó a comer y a cenar muchas veces. La actitud de sus jefes era un poco difícil de determinar debido a la filtración que hacía el Dr. Sieger. Por algunas cosas que dijo, era evidente que el Sr. Schedl no le daba mucha importancia a la situación y consideraba muy injusto que la FPS vendiera equipo en el estado del DIS.

Escena 4, Comentarios varios

1) Existen dificultades mecánicas con la holgura de las tablas y la fuerza necesaria para asentarlas. Al retirar o insertar tablas, se puede oír cómo rozan entre sí (muy desconcertante). La fuerza necesaria para asentarlas a veces hace que se doblen y deformen.

2) Todos los cables y conectores del sistema deben estar etiquetados y tener llaves para evitar que se inserten incorrectamente. (Incluso Walt insertó un cable al revés una vez).

3) El panel frontal está diseñado para que, al abrirse, cuelgue en un ángulo de noventa grados, con todos los conectores en la parte inferior. En MTU, esto generaba irritación, ya que teníamos que intentar quitar e instalar los cables a tientas, o mover las sillas y tumbarnos boca arriba para instalar un cable. Recomiendo que, además de la forma en que está diseñado actualmente el panel frontal, se lo haga verticalmente, con los conectores frontales orientados hacia adelante. (Cuélguelo de los conectores superiores normales en las clavijas inferiores del rack).

4) Se necesita documentación más completa con ejemplos de programación para cada tipo de modo. Además, se deben incluir diagramas de tiempos en la documentación.

5) Sería valioso poder observar las transferencias de datos reales en el panel frontal. Esto requeriría seleccionar señales en cada placa y llevarlas al borde de la misma. Desde allí, se conectarían a un panel frontal. Sugiero que el panel frontal tenga LED y conexiones para osciloscopio, de modo que si el sistema se bloquea, esto sea evidente a través de los LED, y las conexiones para osciloscopio permitan al cliente medir la eficiencia de su sistema (incluido su software).

6) Es necesario aumentar las pruebas de diagnóstico para incluir pruebas a nivel de sistema (que también podrían servir como ejemplos) como DISVER.

7) IOCAL en el sitio tenía varios problemas. El tamaño del módulo de carga era demasiado pequeño para el cliente, así que lo aumenté. Tenía una matriz (SYMVL) dimensionada a la mitad de lo que debería haber sido. Además, el comentario sobre la estructura de la tabla de símbolos era incorrecto (N)6+3 por el tamaño debería haber sido N7+3) Los arreglé y escribiré un TAR para entonces.

8) La tarjeta QBT tenía todos sus circuitos integrados invertidos en comparación con las demás tarjetas del DIS. El pin 1 de cada circuito integrado de la QBT estaba en la esquina superior izquierda, al observar la placa. En un extensor, sin embargo, en las demás tarjetas, los circuitos integrados estaban dispuestos de forma que el pin 1 estuviera en la esquina inferior derecha. (Puede que lo tenga al revés, pero no importa).

Acto 4, Epílogo

Escena 1, Resumen

Esta es la escena final. El protagonista está sentado al borde del escenario con las piernas colgando.

El plan original de FPS para las unidades prototipo era crear diagnósticos para la tarjeta QBT y basarse en las pruebas de Traducción de Datos para las demás placas. Se suponía que estas placas eran productos estándar de Traducción de Datos y que funcionarían correctamente. Para que FPS tuviera cierta confianza en el sistema, el grupo de aplicaciones creó una prueba de sistema para el ADC y su DPM, así como para el DAC y su DPM. (Desafortunadamente, las pruebas utilizaron los modos de operación que funcionaban).

Durante el desarrollo de los diagnósticos del QBT (antes del envío de los prototipos), acudí a Traducción de Datos para activarlos. Teníamos problemas con ellos, que atribuí a nuestra falta de comprensión de las placas y a la falta de documentación adecuada. Durante nuestra estancia en Traducción de Datos, Walt Bastow y yo descubrimos algunos pequeños fallos de diseño del QBT, relacionados principalmente con la inicialización de la placa. Estos se solucionaron y todas las pruebas del QBT se revisaron mediante una simple inserción de fallos. Posteriormente, tras el envío de los prototipos, durante el desarrollo de las pruebas de diagnóstico restantes, decidí que necesitaba volver a Traducción de Datos para finalizar el resto de las pruebas.

Experimentamos las mismas dificultades con las demás pruebas que con las pruebas QBT. Desafortunadamente, había planeado estar en Traducción de Datos solo una semana. Después de un día y medio, me enviaron a General Electric para ayudarlos a instalar su prototipo DIS. Esto me llevó el resto del tiempo planeado. (Walt y yo encontramos algunos errores menores durante el día y medio. También aprendí mucho sobre la programación del DIS y corregí muchos errores de código).

Todos los problemas de hardware detectados en MTU deberían haberse detectado en Traducción de Datos. Si no se detectaron en Traducción de Datos, deberían haberse detectado en FPS. La dificultad para FPS residía en la falta de tiempo previo al envío, la falta de documentación adecuada y que el sistema prototipo de ingeniería ni siquiera era idéntico a los sistemas prototipo enviados.

Dado que FPS asumió que las placas habían sido verificadas por diseño, asumimos que muchas de las dificultades que estábamos experimentando se debían a errores de software debidos a la falta de comprensión del sistema. En retrospectiva, se demuestra que se debería haber desarrollado un conjunto completo de software de verificación de diseño antes del envío y que se debería haber dedicado tiempo a dicha actividad.

Esto debería seguir haciéndose, y creo que cuando FPS vuelva a funcionar internamente, se debería realizar la inserción de fallos para verificar los diagnósticos. Quizás Walt Bastow debería venir a Portland para ayudar en la verificación de los diagnósticos. Todo esto indica que se realizó poca verificación de diseño en el sistema DIS en Data Translation.

Creo que otro problema durante el proyecto de FPS fue la escasa participación del Servicio de Atención al Cliente. Creo que, especialmente en este tipo de proyectos, el Servicio de Atención al Cliente debería haber actuado como un organismo de control de calidad. Cuando se enviaron las unidades, nadie en el Servicio de Atención al Cliente sabía nada sobre el hardware ni el software de diagnóstico. Al parecer, se basaban en una filosofía de intercambio de placas. Si bien esta filosofía es viable en un diseño depurado, sigo creyendo que si FPS vende el producto, el Servicio de Atención al Cliente debería contar con expertos en el producto.

En el futuro, si se inicia otro proyecto como el DIS, recomendaría establecer una relación de ingeniería mucho más estrecha entre la empresa contratada y FPS para garantizar que el producto y su documentación cumplan con los estándares de FPS. También considero que contratar a otra empresa para el desarrollo del producto no debería implicar una reducción significativa del tiempo del proyecto para FPS. De hecho, creo que contratar a otra empresa puede ahorrar mano de obra, pero podría aumentar el plazo del proyecto debido a los problemas de comunicación entre ellas.

Fin del acto 4