APUNTES AMPROLYZER

1. Introduccin.
Este documento contiene breves apuntes relativos al curso de diagnstico de Profibus, especificando el manejo del programa Amprolyzer. Se complementa con un caso prctico realizado en el ICL07A en el que se tomaron las tramas de la lnea asociada al PER04. Indicar, por ltimo, que estos apuntes no son 100% fiables, puesto que en el curso apenas se habl de esto y lo que se presenta est ms o menos sacado por observacin.

2. Modo de funcionamiento.
Se arranca el programa Amprolyzer 'ocupando' el interface Profibus de nuestra PG. Es decir liberamos el interface que tendramos asociado al STEP7 para emplearlo en el programa Amprolyzer. Para ello pulsamos en Add_Bus

Una vez que aadimos el Bus nos muestra la pantalla principal con las distintas opciones que disponemos. Cabe destacar que el programa saca por si mismo informacin de la tarjeta de Profibus que tenemos en nuestra PG, mostrando entre otras cosas las limitaciones de RamSyze que afectan al nmero de tramas o mensajes capaz de almacenar. En nuestro caso observamos dicha limitacin en 995 full mensajes. Vemos tres opciones en su manejo: Show BusState Nos muestra informacin grfica mediante colores del estado del bus en funcin los distintos eventos que se produzcan. Record (Simplex) Realiza una grabacin de las tramas de forma manual. Dicha grabacin recoge todas las tramas desde que pulsamos hasta el lmite de tramas marcado por las caractersticas de nuestra tarjeta Profibus. Record (Complex) Realiza una grabacin de las tramas de forma personalizada pudiendo filtrar los mensajes por esclavos, activacin por eventos, etc. Es la opcin ms verstil y til. Recordar que una vez finalizado el manejo del Amprolyzer, hemos de devolver el interface para poder ser usado por el Step7. Para ello pulsaramos en Remove Bus.

3. Caso prctico. ICL 07A.

Vamos a documentar los apuntes con un caso prctico asociado al ICL07A. Se han observado distintos fallos de Profibus en el ICL07075 e ICL07077 entre otros. Primeramente veamos el HW de la lnea que nos ocupa:

Vemos que tras la Y-LINK disponemos de 4 IMs, 10 INDRIVEs y 8 SEWs. Lo primero de todo es ver el estado del Bus. Pulsemos ShowBusState

Vemos todos los esclavos con la Y-LINK. Creo que la direccin de la Y-LINK la toma como 125. El semforo en color verde indica que el bus se encuentra activo y no se han producido muchos eventos de Req. Repeat ni de peticin de diagnstico. En la pestaa de Events observamos el contador de eventos. Vemos que no se han registrado eventos y por tanto se mantiene el color verde del semforo indicativo de estado del bus. En estas condiciones en que el bus se encuentra en un estado correcto podemos analizar las tramas del bus, por ejemplo desde la opcin Record (Simplex). Bsicamente en este modo Record (Simplex) y con el bus sin problemas, recogeramos 995 tramas o mensajes (lmite de tramas asociadas a nuestra tarjeta Profibus) con comunicacin normal entre el maestro (en este caso sera la Y-LINK como pasarela respecto a la CPU-400) y el resto de esclavos. Veramos los mensajes en orden de tipo SD2 (formato de longitud variable de datos). Si analizamos el campo DATA de la hoja Excel que muestra al pulsar Show podramos cotejar a nivel

bit la informacin de la palabras de entrada y salida de cada esclavo con el maestro.

En las imgenes de arriba podemos ver como los esclavos del 7 al 16 intercambian 12bytes (6 palabras) coincidiendo con los INDRIVEs y esclavos del 17 al 12 intercambian 6bytes (3 palabras) coincidiendo con los SEWs. A continuacin vamos a dejar al Amprolyzer trabajando para que 'recoga' una cada de un esclavo. Cmo lo detectaramos? Pues utilizando el modo Record (Complex) combinando la activacin de grabacin con Triggers o disparos. En concreto utilizamos para el filtrado el SAP 61. (Service Acces Points). La funcin SAP 61 Set_Prm Telegram es usada para fijar los parametros a un esclavo tras un rearranque o ante un reset del sistema. Posiblemente lo podemos asociar a un breve corte de Profibus y tampoco tiene porque tirar el bus, aunque en nuestro caso lo tir. Bien el caso es que queremos detectar cuando se produce un SAP 61 en algn esclavo del bus para posteriormente activar la grabacin de las tramas. Nos vamos a Record (Complex) y elegimos la pestaa Msg_Trigger. Tenemos la posibilidad de meter hasta 4 condiciones y realizar una serie de acciones tras la activacin de 1, 2 o ms de esas condiciones.

En nuestro caso introducimos la siguiente condicin: SSAP/DSAP dec 62/61

y metemos

Nota: SSAP (Source Service Access Point) va asociado al SA (Source Address) y el DSAP (Destination Service Access Point) va asociado al DA (Destination Address).

Cuando se produzca un SAP 61 estaremos realizando un Set_Prm al esclavo afectado, posteriormente el esclavo devolver un telegrama SAP 60 (Diag_Data) respondiendo a peticiones de diagnstico. Parece que esta situacin contina hasta que en el SAP 60 el esclavo reconoce al maestro. Tambin se observan en las tramas telegramas SAP 62 (Chk_Cfg) que chequea la configuracin que fue enviada comparando la informacin de las entradas que vienen configuradas originalmente en el GSD de los proyectos1. Bien, veamos las tramas que se han guardado tras la activacin de grabacin tras producirse un la condicin SSAP/DSAP 62/61.

Lo primero y ms importante es que detectamos que el evento se ha producido en el esclavo 12 (en el campo Adr. se observa). En el campo DATA (en modo binario) vemos 7 bytes asociados al SAP 61. Al parecer 7 bytes es el nmero mnimo de bytes que indica la norma2. Desglosemos estos bytes del SAP 61: 1 Byte. Station_Status

1 2

Habra que comprobar si esto es realmente as. Segn la norma Profibus

11111000 En este caso parametriza para que el esclavo est desbloqueado (bit 7 y bit 6), que opere en modo sncrono (bit 5 Sync_Req), en Freeze mode (bit 4) y activa el Watchdog (WD_ON, bit3). 2 Byte y 3 Byte. Factores para el clculo del tiempo de WathDog El tiempo de WatchDog TWD se clcula en funcin de estos 2 bytes como TWD= 10ms x WD_Fact byte2 x WD_Fact byte3. Este tiempo esta comprendido entre 10ms y 650 segundos. 4 Byte. Tiempo SRD (Slave Reaction Time) 5 Byte y 6 Byte. Ident_Number del esclavo

A continuacin, unas tramas ms abajo, vemos que llega una peticin de diagnstico por parte de SAP 60 una p

Desglosemos estos bytes del SAP 60:

00010 Activado bit1 de Station_Status_1. Esclavo no preparado para transferencia de datos. 00000101 Activado bit0 de Station_Status_2. El esclavo necesita de nuevo ser parametrizado.

4 Byte. Diag.Master_Add 11111111 Aqu, si todo va bien, estara la direccin del maestro. En caso de FFhex quiere decir que no reconoce a ningn maestro, en definitiva que no est parametrizado. 5 Byte y 6 Byte. Manufacturer Identification Number 00000000 11100011 Supuestamente sera el nmero asignado por el estandar Profibus a la marca del mdulo de comunicacin Profibus de los INDRIVEs

De nuevo continuamos unas tramas ms abajo, recordemos que se envin un SAP61 para parametrizar y respondi con un SAP60 indicando que no fue parametrizado, solicitando de nuevo ser parametrizado. Por tanto, tendramos que esperarnos unas tramas despus otro envo de SAP61. Efectivamente, encontramos de nuevo el SAP61. La diferencia con el primero la encontramos en el 1 Byte, vemos ahora que en la parametrizacin que introduce bloquea el esclavo a otros maestros3. Sigamos analizando las tramas. Se entiende que a continuacin deberamos de encontrarnos con un SAP60, sin embargo nos aparece un SAP62 (Chk_Cfg).

Esto desconozco exactamente que hace o deja de hacer.

Segn la documentacin, en este telegrama SAP62 indicaramos la longitud de los datos del esclavo que supuestamente habra de coincidir con su GSD en el proyecto

del HW del Step7. 11110011 palabras 11110001 Indicara consistencia en la longitud, tipo Word, entradas/salidas y 4 Lo mismo pero 2 palabras.

Podemos deducir, no con cierto miedo, que seran 6 palabras para un esclavo INDRIVE. Puede ser que cuadre tanto en el HW del Step7 como en una trama del DATA.

Si continuamos el anlisis de las tramas, nos encontramos de nuevo un SAP60 (Diagnostic Request).

En este caso, a diferencia del anterior, vemos que el 1 Byte de Station_Status est todo a cero y en el 2 Byte de Station_Status vemos que se activo el indicador del WatchDog. Por tanto podemos entender que el esclavo est activo. Adems, si observamos vemos que el 4 Byte (Master Address) es 01111101 corresponde en decimal a la direccin 125, es decir el maestro. Por tanto ya le ha reconocido. Finalmente, observamos que el esclavo 12, el INDRIVE afectado, entra en la dinmica de envo normal de datos conjuntamente con el resto de los esclavos.

Resumiendo4: Parece ser que cuando cae un esclavo se produce un evento DSAP 61, a continuacin responde con un DSAP 60 indicando si se levant o si no est preparado. Dependiendo del resultado del DSAP 60 se volvera a enviar un SAP 61 para parametrizar. As hasta que llegamos a un DSAP 60 en que responde con todo OK y reconociendo la direccin del Maestro, en este caso la 125 (como se indic en el principio)

4. Conclusiones.
Simplificando, pienso que lo ms importante es meter en el Record (Complex) un trigger condicionado a que salte un DSAPdec 61 y ver que esclavo ha sido el que produjo el SAP 61. Si durante un rato que estemos conectados vemos que el primer esclavo que activa el trigger con la condicin SAP 61 es siempre el mismo podemos pensar que por ah van los tiros.

Habra que cerciorarse si esto es siempre as.