Bucle de no mediciones

[JoanAmaya]

Cuando se ejecutan mediciones pesadas en tempico software haciendo uso de fetch eventualmente llega a un bucle en el que el dispositivo deja de registrar mediciones, se pensaba en un inicio que era debido a que una medida no estaba siendo abortada sin embargo, a pesar de que se hace el abort no esta funcionando de forma correcta:

originalConsole=sys.stdout
sys.stdout=io.StringIO()
measure=self.device.measure()
printedDeviceCommunication=sys.stdout.getvalue()
sys.stdout=originalConsole
finishedMeasurement=False
if "Timeout reached" in printedDeviceCommunication:
while not finishedMeasurement:
time.sleep(1)
newFetch=self.device.fetch()
if (newFetch==measure):
finishedMeasurement=True
measure=newFetch
self.device.abort()
print("Entra al abort de la medicion")
else:
measure=newFetch
print(measure)
if not measure:
self.device.abort()

[JoanAmaya]

Error replicado en fragmento de codigo cuando el tempico se le hacen muchas peticiones de readIdnFromDevice (peticiones que pertenencen al flujo de tempico software ya que este comando es la verficación de conexión cuando no se toma medición) y posteriormente se realizan mediciones normales luego de la segunda o tercera medición el dispositivo deja de registrar mediciones a pesar de que debería registrar starts de acuerdo a los pulsos que emite el teensy:

[JoanAmaya]

import io
import sys
import pyTempico as tempico
import time

Redirigir stdout temporalmente

tempicoDevice = tempico.TempicoDevice("COM5")
tempicoDevice.open()
tempicoDevice.setNumberOfRuns(1000)
tempicoDevice.ch1.enableChannel()
tempicoDevice.ch2.enableChannel()
tempicoDevice.ch1.setNumberOfStops(5)
tempicoDevice.ch2.setNumberOfStops(5)
tempicoDevice.ch3.disableChannel()
tempicoDevice.ch4.disableChannel()
for i in range(200):
tempicoDevice.readIdnFromDevice()
tempicoDevice.setDateTime()
while True:
measure = tempicoDevice.measure()
print(measure)

[daguzman35]

tiempo abort y reset

Resumen

Pruebas en hardware Tempico de tiempo de ejecución de comandos abort y reset

• Tiempo necesario para aplicar reset: 16.8ms
• Tiempo necesario para aplicar abort: 8.5ms

Recomiendo en consecuencia, por software,

• esperar al menos 20ms tras un reset
• esperar al menos 10ms tras un abort

Detalle

Cronometro el tiempo de ejecución desde el momento en que Tempico interpreta ha recibido un comando "*RST" (o un comando "ABORt"), pasando cada canal de TDC por el estado de 'reset' (o 'abort') en máquina de estados, hasta que llega a uno de los canales en estado de 'espera inicial'.

Prueba 1: tiempo reset y abort total

En este ejemplo, encuentro que Tempico tarda 16737us en aplicar los 4 reset, y en total 16761us si se incluye el tiempo en el que el sistema llega en canal 1 al estado 'espera inicial'. Para el caso de aplicar 4 abort tarda 8421us; en total 8445us hasta llegar a 'espera inicial'.

Prueba 2: tiempo abort por canal

En prueba adicional, cronometro cuánto tarda cada canal en ejecutar un comando "ABORt"; se encuentra que cada canal tarda aproximadamente un cuarto del tiempo total, como es esperado. Tarda unos 2100us por canal.

Prueba 3: nruns=1000

Asigno number of runs = 1000, hago solicitud de "MEASure", espero 2 segundos, y luego si realizo solicitud de "*RST" (o de "ABORt").

###Prueba de RESET
print('sending a measure request to device, wait 2 seconds, and then reset')
data = my_device.measure()   #starts a measurement, and saves response in 'data'
time.sleep(2)
my_device.reset()
#read serial port messages
m = my_device.readMessage()
print(m)

Resultado similar al de escenario anterior con number of runs = 1. Se concluye no hay diferencia en tiempo de procesamiento entre escenarios con alto o bajo number of runs.

[JoanAmaya]

Aparentemente el tiempo esta funcionando relativamente. Realizando una prueba en tempico software se encuentra que muchas veces se fuerza a la estrategia de reset luego de muchos aborts y no es hasta que salen los datos corruptos en la terminal que continua la medición de lo contrario no lo hace