-------------------------------------
- 2017.10.19
-------------------------------------
OK - da testare ora invio URL a MoonPro
OK  - ALIVE
OK  - ENABLED
OK  - INPUT
OK - FARE lettura VERA da FANUC almeno della bitmap
OK - fare gestione come rPI-IOB, ovvero
OK  - gestione QUEUE eventi
OK  - salvataggio su file dello storico eventi rilevati
OK  - gestione dei segnali ballerini (BITMASK!)
OK - gestione contapezzi CUSTOM
  - fare gestione configurabile lettura FANUC
OK - gestione dati G43
OK  - togliere dati F (E0 | 90)
  - fare integrazione ALTRI varori FANUC, tra cui
   - allarmi
OK   - load/speed
OK   - overrides (G12, G30)

OK   - nuovo metodo chiamata x MP/IO (che dovrà avere nuovo comando x accettare queste chiamate e salvare su tabella SENZA processing, come eventi o come extra... evento NOTA?)
   - verificare segnali: (vedi doc gsheet)
     - F001.0: ALARM_PRESENT
     - F001.7: CN_READY / POWER_ON
     - STL000.5: AUTO (vers 1)
     - STL000.7: AUTO (vers 2)
- Cambiare ordine valutazione eventi frequenza VLF-->VHF
- Azzerare I contatori quanto si arriva al più lento (quando si azzera lui ripartono comunque tutti...) -> in questo modo scatta un contatore QUANDO GENERAL_COUNTER MOD periodo_Ccntatore == 0
- rendere parametrica l'assegnazione delle funzioni al diverso ambito frequenza tra i 5 (VHF, HF, NF, LF, VLF)
- procedura x gestione dati REALTIME (da NON salvare su db ma al limite su REDIS, simil EQN con 2 tab x eliminare dati scaduti) 

OK FINIRE SISTEMAZIONE JETCO:
OK - install servers
OK - install DB
OK - conf acquisitore togliendo parti abbozzate x contapezzi/fineciclo
OK - part program name MAIN con nuova funzione

CREARE NUOVO SW (o configurazione? o ramo alternativo a develop?) x mapping INIZIALE della macchina... ad esempio
 - si collega a ns server
 - chiede cosa deve fare (es mappa memorie D da 0 a 9999)
 - effettua testing e poi fa upload risultati
 - il ns sw fa i check/controlli modifica
in questo modo ad esmepio possiamo cercare i contapezzi, i segnali ceh cambiano con il fineciclo nelle aree Y, i contatori STANDARD nelle memorie D, ...


GESTIONE LIVE DATA
L'idea è ceh quando una macchina è "sotto osservazione" ovvero live viene aperta pagina questa debba inviare PIU' DATI di tipo realtime e mostrarli nel browser. Per farlo ci saranno questi elementi
- si apre una pagina di dettaglio macchina (da tablet? da SITE principale?)
- questo causa la modifica di una chiave su DB (e/o redis) di stato macchina, del tipo "OnAir=true", e potrebbe essere una chiave a tempo (30 sec poi scade?) e mentre la pagina è aperta e si aggiorna (ogni 1-2 sec oppure Signal-R) questo valore viene confermato (e prorigato)
- ogni IOB-WIN fa una chiamata "extra" all'URL dedicato al checl "OnAir", e se trova che è abilitato passa in modalità letture frequenti (1/2 al sec?) dei parametri LIVE (es: feed, speed, posizioni assi, load istantanei)
- se passa inq eusta modalità live invia DI CONTINUO il dato al server IO
- il server IO salva SU REDIS questi valori sia come "lastVal" che come serie storica
- le pagine che mostrano i dati si continuano ad aggiornare (da redis) con grafici (chartJs come PIC) e/o valori istantanei
- le serie storiche vengono ripulite periodicamente (ogni ora? valori + vecchi di 24h ad esempio?)
- struttura dati REDIS da creare SIMILE a struttura info URL...
- struttura dati LIVE: ../LIVE/COD_MACC/CURR_VAL (contiene TUTTI i dati LIVE, ultimi ricevuti...)
- struttura dati TimeSeries: ../LIVE/COD_MACC/DATA_NAME (contiene TUTTI i dati come timeseries, es SPEEDRATE, FEEDRATE, POS_X1, POS_X2, ...)
- operazione SAVE aggiorna SURR e accoda NUOVO valore...
- LOAD (rilettura9 POTREBBE fare pulizia se + vecchi di 24h...)
- la trasmissione verso IO deve avvenire con "multisend, nel