Simulazione e Visual Studio

[MassimoB]

Sono d'accordo con rugweri

[venexian]

L'idea è quella di avere più copie del programma che girano su macchine diverse in posizioni diverse, con un unico database con le variabili di stato, accessibile (in modo trasparente per l'utente) sul nostro sito. In questo modo, una simulazione che durerà mesi potrà essere monitorata sia dal cliente, sia da noi, anche se in trasferta per lunghi periodi, come avviene di frequente. Il cliente può interrompere la simulazione e riprenderla in qualunque momento, mentre noi possiamo verificare lo stato della simulazione e interagire nel caso il cliente lo richieda o se riteniamo sia il caso di 'aggiustare' qualcosa.

[MassimoB]

Azure non lo avete preso in considerazione?

[dimaios]

Nella gestione preventiva di un progetto di grandi dimensioni, il cliente chiede un simulatore per valutare le prestazioni e affinare le specifiche prima di iniziare la realizzazione. Il simulatore dovrà essere utilizzato da tecnici non-informatici

Secondo me prima di consigliare il tool bisogna capire cosa devi simulare. Sono sistemi dinamici? Devi far girare modelli? Devi fare identificazione? I dati del simulatore sono sintetici o li acquisisci dal campo in tempo reale? Le variabili sono sia analogiche che digitali?

Fissati questi punti puoi scegliere tra MATLAB, LabVIEW, Python ecc.

Un punto fisso sembra essere un DB condiviso ma non ho compreso se è locale o deve essere nel cloud o in generale remoto ma raggiungibile via internet.

A seconda dei casi potresti optare per una soluzione mista.
Non sarebbe male esporre solo l'interfaccia al cliente mentre le istanze del simulatore girano sul server remoto così eviti la redistribuzione in caso di modifica.

[venexian]

@MassimoB

No. Ma non perché non lo si ritenga adatto.

Il fatto è che il problema non è la connettività. Al momento abbiamo molti sistemi che monitoriamo in tempo reale con software realizzato internamente. La parte di connettività di questo progetto è veramente di basso livello.

Il problema è la simulazione. Il dubbio è se usare un ambiente di sviluppo già stabilizzato e conosciuto come MatLab, o se scrivere anche la parte di simulazione. Nel secondo caso, il carico di lavoro potrebbe essere molto pesante.

Scrivere un simulatore a scopo dimostrativo non è un'impresa impossibile e in qualche modo renderebbe anche più semplice realizzare i modelli dei vari componenti utilizzati, ma il test, il debug e la manutenzione sono voci che al momento hanno la casella dei tempi e dei costi con un gran punto di domanda al loro interno...

[MassimoB]

Il problema è la simulazione. Il dubbio è se usare un ambiente di sviluppo già stabilizzato e conosciuto come MatLab, o se scrivere anche la parte di simulazione. Nel secondo caso, il carico di lavoro potrebbe essere molto pesante.

Ma a dire il vero non mi sembra che simulare con matlab sia una passeggiata, quindi dipende cosa simuli.

Per esempio, da buon microsoft MCP io prediligo l'ambiente visual studio, altri diranno che è meglio matlab, lua, python o altro.

Dire cosa è giusto con le poche informazioni date è davvero difficile, poi subentra l'ambiente di sviluppo con cui uno è abituato a lavorare.

[venexian]

@dimaios

Il cliente deve realizzare una linea di produzione per laminati plastici. Vuole un simulatore al quale possa accedere lui per analizzare i dati di produzione come fa adesso con le altre linee (reali e monitorate). Vuole però che al simulatore possa accedere anche il responsabile di produzione, per cambiare i parametri, come se la linea fosse realmente attiva. Vuole anche simulare i cambi di prodotto con i tempi morti, gli scarti e i fermi macchina in caso di guasto. Il tutto in tempo reale, che significa mesi. Se i risultati non dovessero essere soddisfacenti, il simulatore dovrebbe essere rapidamente aggiornato aumentando o diminuendo la capacità della linea, duplicando in ridondanza alcune funzioni, ecc.

L'accentramento della simulazione, con connettività dei soli input/output, è un'altra delle possibilità. Anche in questo caso, però, il programma su server dovrebbe essere sviluppato in ambiente .NET per uniformità con quanto fatto finora.

[venexian]

Per esempio, da buon microsoft MCP io prediligo l'ambiente visual studio, altri diranno che è meglio matlab, lua, python o altro.

Anch'io mi sono trovato più di una volta con la mano ferma sul mouse, indeciso se aprire MatLab o VisualStudio per una simulazione veloce di un problema semplice.

Proprio per questo motivo ho aperto il thread: valutare, sentire pareri diversi, magari qualcuno che ci è già passato.

[dimaios]

Ok. Quindi ci vuole il modello fisico semplificato della linea e un ottimizzatore per i tempi di attrezzaggio ed in generale del cambio prodotto ( una vecchia conoscenza ).
Ti dico quello che ho fatto in passato.
Simulatore matematico in Matlab compilato nativo ed interfaccia in C#. Questo velocizza le modifiche ambo i lati.
La GUI in Matlab sarebbe complicata mentre la simulazione in C# molto onerosa. L'ottimizzazione con MATLAB è indubbiamente più semplice perché hai già tutti gli algoritmi a disposizione. Anche la simulazione dell'estrusione e delle dinamiche varie degli attuatori cesoie ecc. é semplificata utilizzando MATLAB.
Per l'accesso al DB e ai dati del campo C# o C++ a seconda del fieldbus impiegato ( se hai un canale Modbus TCP semplifichi molto le cose ).
Per esempio in passato con automazione Siemens utilizzavo la libreria libnodave per prelevare i dati del campo collezionati in un datablock. Tutto dipende dalla sorgente dati.

[venexian]

dimaios, hai descritto al 100% ciò che facciamo e ciò che intendiamo fare: MatLab + C# e connessione in Modbus.

Anche le motivazioni che ci spingono verso questa soluzione sono quelle che hai citato. Per noi è routine, escluso l'inserimento del codice MatLab compilato, sul quale sto pasticciando ora. Per chi non lo ha mai fatto è un discreto casino.