Samuele Locatelli
61 lines
3.7 KiB
Plaintext
61 lines
3.7 KiB
Plaintext
-------------------------------------
|
|
- 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 |