permanezca un tiempo y en todo caso para que esta sea la ultima notificacion u quede en pantalla hasta que el vehiculo abandone la bascula.
Eliminamos de la pantalla el mensaje Acerque QR o Tarjeta en caso de recibir una lista de menu. Esto lo hacemos en el nodo "check json".
En el nodo "Envio de Mensajes" (linea 65) eliminamos las notificaciones que haya al final del movimiento (final de pesada) salvo si la notificacion es de Ubicacion.
Se hicieron cambios en index.html y en index.js del uibuilder /totem/ para incluir en el menu de Tipo de Configuracion un boton (LISTA DE PARAMETROS) que nos permita visualizar todos los parametros que podemos incluir en cualquiera de los tipos de configuracion
Se introdujo un chequeo en el nodo "QR/RFID" en la linea 37 para eliminar el boton de salida (simular que fue pulsado) cuando se recibe un QR valido durante el movimiento final. Lo mismo hacemos mas abajo en la recepcion de RFID.
En la parte RFID dado que luego de recibir la tarjeta validada en BD todavia necesitamos validar si la matricula asociada a la tarjeta tiene vehiculo en transito, esto hace que el estado movimiento = inicial puede permanecer por mas tiempo (mientras se chequea si hay transito) por lo tanto en el chequeo
tenemos que meter la variable "matricula_revisada" como requisito para avanzar ya que es quien nos indica si el estado del movimiento ya es definitivo. Recordemos que este chequeo solo lo queremos hacer durante el movimiento final, es decir cuando el vehiculo esta cerrando toda la pesada.
- Dado que puede darse el caso que la camara de contexto no responda en un determinado momento a la solicitud de imagen, se han introducido unas condiciones para tratar de obtener
la imagen de contexto en caso de fallo temporal. El metodo resumido es el siguiente: Cuando estamos seguros que el vehiculo esta correctamente posicionado
en la bascula (peso estable) hacemos una solicitud y marcamos un estado ("waiting1"), esperamos por la imagen un tiempo definido en la variable ("camara_contexto_delay1")
encaso de no llegar hacemos una segunda solicitud y marcamos el estado ("waiting2") y esperamos por la imagen un tiempo definido en la variable ("camara_contexto_delay2").
Mientras tanto el semaforo esta en rojo esperando la imagen de contexto, suponiendo que todo lo demas esta ok. Al cabo del ultimo tiempo, marcamos el nuevo estado
en funcion de lo sucedido, "ok" si recibimos la imagen "fail" si no la hemos recibido. En cualquiera de los dos casos el semaforo pasa a verde y se continua con la pesada
En caso de no tener imagen de contexto, el nombre de la imagen ira vacio ("") al igual que la imagen.
habilitada en la configuracion tomara una imagen en el momento en que el camion este completamente en la bascula, para ello hemos introducido un codigo en el nodo
"estable" que es donde se hace la deteccion del camion completamente en la bascula. Posteriormente en el nodo "Analisis del modo de Operacion" es
donde verificamos que la imagen fue tomada y la colocamos en el registro que se esta haciendo para generar el movimiento correspondiente. El Grupo
"CAMARA CONTEXTO" posee los nodos de solicitud de imagen y de recepcion de la misma. La configuracion de IP de la camara se hace en la pantalla
de configuracion al igual que su habilitacion en el sistema.
- Como herramienta de ayuda para saber si el Totem esta en capacidad de solicitar y de recibir la imagen de contexto enviada por la camara
se ha incluido una funcion en el menu de configuracion -> Pruebas del sistema -> Pedir Snapshot de contexto de forma que el usuario pueda visualizar
la imagen actual que la camara esta enviando y pueda de esa forma confirmar el correcto funcionamiento de la conexión y de los equipos.
- Hemos colocado un codigo de dos lineas para eliminar el boton del menu activo "COMPLETAR INFO" en caso que se presente una tarjeta o un codigo QR.
Esto lo hicimos en el nodo "Analisis del modo de Operacion" en la linea 70 donde chequeamos si estamos en movimiento inicial.
- Corregido un "error" que no permitia cerrar el movimiento inicial cuando se pasaba una tarjeta si teniamos el menu activo y la firma obligatoria.
Se agrego una condicion ("ID_verificado") en la condicion global para llamar a la firma. Esto es en el nodo "Analisis de Operacion" en las primeras lineas
if (flow.get("firma_obligatoria") && !flow.get("firma_flag") && !flow.get("firma_ok_flag") && !flow.get("supervisor") && (!flow.get("menu_activo") || (flow.get("menu_activo") && (flow.get("menu_seleccionado_flag") || ID_verificado))))
Con esto permite continuar con la firma en caso que tengamos menu_activo y firma obligatoria y entremos con tarjeta o con codigo QR.
**Version 1.3.1**
- Hemos colocado una opcion mas en el menu de configuración en "Pruebas del Sistema" -> "Probar Sensor". Esto permite visualizar la salida del valor
de la distancia que esta midiendo el sensor cada segundo. Para que el medidor no este continuamente inundando el configurador con el dato de distancia
hemos colocado un switch el cual solo deja pasar ese dato cuando se activa el menu, lo inhabilita cuando se sale del menu.
- Hemos puesto el flag flow.set("RFID_ok_flag", false) cuando leemos un QR y flow.set("QR_ok_flag", false) cuando leemos una tarjeta, esto permite
que se utilice un QR aunque primero hayamos metido una tarjeta invalida y viceversa. Se hizo en el nodo "envio QR/RFID".
y por lo tanto no deberiamos guardar en contexto flow o global ya que esos contextos estan previstos para objetos serializables (estados, valores, arrays, json...)
transporta. Esta notificacion se muestra una vez que hayan cumplido todos los requisitos de entrada y antes de poner el semaforo en verde.
Para esta funcionalidad hemos introducido un codigo en el nodo "Analisis del modo de Operacion" (lineas 76 a 112) y en el nodo "check json content"
en las lineas 44 a 50 bajo el titulo "RESPUESTA DE LA REVISION DE LA UBICACION INTERNA EN BD". Si recibimos respuesta positiva de la BD es decir que si
tiene ubicacion interna el residuo presentado entonces sacamos notificacion con lo que dice el campo de descripcion encontrado en la tabla, en caso contrario
el mensaje que aparece en pantalla es diciendo que no hay ubicacion para ese residuo.
hasta que el vehiculo abandone la bascula. Se agrego un nodo para mantener el aviso de salir de la bascula en caso de PMA, si el usuario pulsa OK.
Corregido en el nodo "check JSON content" la recepcion de la matricula asociada a una tarjeta. Hemos activado los flags correspondientes para que el nodo
"matricula 2" pueda hacer el chequeo de la matricula respecto a si esta o no en transito.
En el nodo "Analisis del modo de operacion" hemos puesto una condicion para no mostrar el boton de salida cuando el usuario utiliza una tarjerta valida.
enviando matricula si se recibe sin que haya vehiculo en bascula. Esto no evita que se reciban matriculas automaticas antes de entrar el vehiculo en la bascula.
Estas ultimas fotos se conservan en memoria hasta que el vehiculo entre en la bascula y pueden ser utilizadas como foto principal en caso de fallo en la solicitud.
Hemos eliminado en la linea 156 del nodo matricula2 la condicion de "qr_revisado" para eximirlo de disponer de matricula debido a que ahora el codigo qr puede estar asociado a varias matriculas.
y por lo tanto sera necesario disponer de una matricula a pesar de tener el codigo de autorizacio (solo indica residuo).
Hemos inicializado la matricula [flow.set("matricula", "Sin Matricula")] tambien en el momento en que el peso supera a pmin por primera vez (es decir entrando en la bascula).
Se agrego en la salida de la edicion de matricula [flow.set("matriculacheck_solicitada", false)] para permitir que se busque nuevamente la matricula en BD.
dos campos es para disponer de la identificaciob utilizada en salida en caso de hacerlo. Para ello en el nodo "Analisis del modo de Operacion" se evalua
si estamos en el movimiento inicial o final para ver cual campo es el que tenemos que rellenar. Est se hace el la linea nº 100
Se ha moviso la inicializacion flow.set("distance_flag_SET", false) al momento donde la bascula pasa de peso < pmin por primera vez.
Antes se inicializaba cada vez que el peso que llegaba era menor que pmin. Esto podia ocasionar un error ya que el nodo detector perdia el control
de este flag al ser inicializado cada vez que el peso < pmin.
En caso de que la matricula leida sea diferente a la matricula obtenida en la BD se toma la matricula leida de la BD
version 1.0. Este codigo de Bascula Autonoma sale a partir del Totem Autonomo. Todo el codigo relativo a la gestion de BAse de Datos se traslada al RPI Supervisor
En este RPi solo queda lo relativo a la gestion de sensores, camaras, lectores de Identioficacion, semaforo, barrera y la pantalla para que el usuario
pueda interactuar con el sistema como por ejemplo hacer seleccion del residuo a traves de un menu de seleccion.
En esta version se ha introducido el termino PMA(Peso Maximo Autorizado. Este es un valor que el Totem recibe cuando el Supervisor le envia la autorizacion
de la matricula junto con la tara- El Totem revisa el peso estable del vehiculo con el PMA recibidoy en caso de ser superior se envia un aviso en la pantalla
indicandole al conductor que debe retroceder ya que supera el peso admitido.
Otra función que contiene esta version es el chequeo de la Tara. Si el valor recibido de la Tara es superior a cero entonces el movimiento inicial recinbido por el supervisor
es enviado como movimiento cerrado al Servidor.Realmente para el Totem es transparente. La gestion de la Tara en efecto la hace el Supervisor una vez que recibe
el movimiento inicial que envia el Totem.
yamaray