[pyar] Django y puerto serie.

[Basel Valentin]

personalmente me parece la mejor solución.. tu software servidor (el que
controla el puerto) va a capturar el hardware, los demás clientes solo
pedirán datos o mandaran ordenes, pero no pueden acceder al hardware
directo, lo cual en estos casos es una ventaja... el puerto serie es muy
lento para las velocidades de procesamiento actual, si tenes una aplicación
que esta pidiendo datos mientras otra espera, es posible que la segunda
aplicación tire error por time to live (ttl). de esta forma aprovechas las
ventajas de los socket (tecnología madura y muy probada) e independizas a
los clientes del hardware.

por ejemppo, en el git que puse... los clientes se conectan al server
(clemente) y le piden datos de los puertos analogicos de un micro 18f4550
(8 puertos de 10bits) a traves de usb-bulk..... el servidor son varios
objetos (todos paralelizados). Cuando un cliente pide un dato (por socket),
el server se lo entrega de un array donde tiene el ultimo valor que la
placa entrego... suponiendo que el hardware se cuelga, explota o se resetea
(o que le piden muy rapido las cosas) .... el servidor seguirá entregando
el ultimo valor que recibió, o tirara un flag de desconexion (mientras
tatno, sigue tratando de conectar al hardware cada x segundos)... de esa
forma si se cae el hard, los clientes no se cuelgan y podes hacer codigo
desde el servidor para manejar esos inconvenientes.


carritos de supermercados?... me encantan las fabricas automatizadas! :-P

El 30 de marzo de 2015, 16:29, Bruno Geninatti <brunogeninatti en gmail.com>
escribió:

> Claro. El proyecto de máxima era hacer algo así.
>
> Mi idea era tener, por un lado la aplicación web que maneje el operario
> del hardware en cuestión y por otro lado otra aplicación para monitoreo del
> puerto serie, digamos de "administrador".
> La segunda aplicación sería mas estándar, serviría para todo el (mi)
> hardware.
>
> Ahora, por ejemplo, hay una aplicación web que sirve para programar una
> máquina que suelda carritos de supermercado. Pero cuando hay algún quilombo
> y deja de funcionar (la mayoría de las veces por problemas eléctricos que
> joden las comunicaciones) necesito debuguear un poco, ver los paquetes que
> se mandan y reciben, leer la memoria de los micros, etc. Esto segundo hasta
> ahora lo hago de forma bastante primitiva, pero me gustaría mejorarlo.
>
> Voy a optar por esto que vos planteas, valentin, armar un server que
> maneje el puerto serie y que django o quien lo necesite se comunique via
> sockets.
>
> Muchas gracias a ambos.
>
> El 30 de marzo de 2015, 15:54, Basel Valentin <valentinbasel en gmail.com>
> escribió:
>
>> hola bruno, si te interesa podes ver esto:
>>
>> https://github.com/valentinbasel/icaro/tree/devel/clemente
>>
>> para resolver el tema de que el puerto serie y tu micro controlador (o lo
>> que uses)  son bastante lentos, yo termine haciendo un "server" usando
>> threading y sockets...... este "server" controla el puerto y los demas
>> programas (o django en tu caso) le piden info por socket.
>>
>> no se si es la mejor forma, pero para lo que lo uso, me sirve bastante
>> bien...aunque esto esta echo par trabajar con usb_bulk en ves de serie...
>> pero la idea es la misma.
>>
>> :-D
>>
>>
>>
>> El 30 de marzo de 2015, 15:20, Nahuel Defosse <nahuel.defosse en gmail.com>
>> escribió:
>>
>>> Bruno,
>>> > El 30/3/2015, a las 1:57 p.m., Bruno Geninatti <
>>> brunogeninatti en gmail.com> escribió:
>>> >
>>> > Gracias Nahuel.
>>> >
>>> >  Creo que entiendo lo que planteas. Mantener a mi recurso en un thread
>>> separado de la aplicación.
>>> >  Como me decís, la instancia va a poder acceder al ORM, te consulto:
>>> ¿Los modelos podrán también acceder a esta instancia?.
>>> > Una de las operaciones que tengo que hacer es, por ejemplo, realizar
>>> un request que grabe un programa en mi base de datos y a la vez lo grabe
>>> via puerto serie en un micro del hardware, y asegurar la integridad en
>>> ambos lados (base de datos y micro). Sólo así dar el OK al request.
>>>
>>>
>>> Una forma de realizar esto es usar Celery, dónde podes hacer estas
>>> tareas asincrónicas sin bloquear el el hilo/proceso dónde se atienden los
>>> requests (escribir por puerto serie).
>>> En tu vista podes hacer la grabación en la base de datos, mediante el
>>> ORM y pedirle a Celery que ejecute un management command, pasándole alguna
>>> forma el ID de la fila que contiene el programa.
>>>
>>> Celery se integra con django, mediante celery-django, con el cual podes
>>> obtener por cada tarea que encargues a Celery, una URL dónde podes
>>> monitorear el estado de la tarea.
>>>
>>>
>>> Saludos!
>>> _______________________________________________
>>> pyar mailing list pyar en python.org.ar
>>> http://listas.python.org.ar/listinfo/pyar
>>>
>>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>>
>>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>>> Argentina - http://www.usla.org.ar
>>>
>>
>>
>>
>> --
>> ---------------------------------------------------------------
>> Valentin Basel
>> Analista en Sistemas Informaticos
>> Departamento informatico
>> Centro de Investigaciones y Estudios sobre Cultura y Sociedad - *CIECS*
>> - UNC - CONICET
>> ---------------------------------------------------------------
>> http://www.sistema-icaro.blogspot.com/
>> http://fedoraproject.org/wiki/User:Valentinbasel
>>
>>
>> ---------------------------------------------------------------------------
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



-- 
---------------------------------------------------------------
Valentin Basel
Analista en Sistemas Informaticos
Departamento informatico
Centro de Investigaciones y Estudios sobre Cultura y Sociedad - *CIECS* -
UNC - CONICET
---------------------------------------------------------------
http://www.sistema-icaro.blogspot.com/
http://fedoraproject.org/wiki/User:Valentinbasel

---------------------------------------------------------------------------
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20150330/d2840f7c/attachment-0001.html>