esecuzione operazioni

[Alan321981PG]

Ciao.

Vorrei sapere se mi conviene fare come da esempio allegato a fare delle operazioni come scrittura su file o su seriale o fare in un'altro modo.

[Alan321981PG]

non so se con l'approccio che ho seguito nell'esempio si possano evitare dei conflitti nell'utilizzo della risorsa (seriale, disco rigido, ecc...) e quale approcci bisogna utilizzare per evitare tale tipo di conflitto.

Ciao, Alan.

[RobertoBozzolo]

Sicuramente quando si accede da più parti alla stessa risorsa occorre gestire (o meglio: tendenzialmente evitare) la contemporaneità dell'uso della risorsa stessa, sia essa la seriale, una scheda di acquisizione, un file su disco o altro.

In questi casi si può creare una struttura generica che prevede l'uso di una coda su cui accodare le richieste alla risorsa e la creazione di un modulo che riceve dalla coda e gestisce la risorsa. Una struttura di questo genere si chiama producer/consumer e la trovi descritta in questo documento. Prova anche a leggere questo thread.

In ogni caso, strutture di questo genere devono essere ottimizzate al fine di evitare overhead nel consumer loop (che deve essere il più rapido possibile per poter servire tutti gli accessi efficientemente): in questo senso, ti sconsiglio di scrivere sul file con il Write to Spreadsheet che ogni volta apre e chiude il file. E' meglio invece aprire il file alla partenza del processo (ma prima che inizino le richieste di scrittura), scrivere i dati con vi specifici di sola scrittura (il Write to Spreadsheet alla fin fine usa il Write Text File) e chiudere il file una volta terminati tutti i processi che devono memorizzare dati.

[Filippo_Persia]

Gentilissimo Alan,

Per avere esempi di programmazione corretta in labview di I/O su file o su risorse seriali le consiglio di guardare
Help>>Find Example>>Fundamentals>>File Input and Output
Help>>Find Example>>Hardware input and Output>>Serial

Per quanto riguarda un corretto approccio alla programmazione le consiglio vivamente di scegliere fin da subito una buona architettura tipo State Machine
Una solida architettura di base aiuta enormemente nella programmazione e nello sviluppo della proprie applicazioni.

Cordiali Saluti

[Alan321981PG]

per essere più precisi dovrei effettuare l'accesso di tipo [A] alla seriale con la frequenza di un 1hz e l'accesso di tipo [B], [C] e [D] con la frequenza di 10hz sullo stesso strumento. [B], [C] e [D] devono essere sequenziali, prima 1 volta [A] poi 10 volte la serie ( [B], [C], [D]) poi un'altra volta [A] e poi 10 volte ([B], [C], [D]) ecc... fino a quando non ho riempito il disco o decido io di spegnere.

Non ho idea come utilizzare le macchine sequenziali, non ce le hanno insegnate in corso e ho poco tempo, non so dove mettere le mani, tra l'altro mi mancano anche 2 esami e non so quando prepararli.

Ciao, Alan. 

[RobertoBozzolo]

Le strutture di cui ti abbiamo parlato sono necessarie nel caso gli accessi alla risorsa condivisa siano più o meno casuali. Nel tuo caso invece c'è una sequenza fissa di messaggi da inviare e quindi si può usare una struttura sequenziale più semplice, come quella sbozzata qui:

Message Edited by Roberto Bozzolo on 04-09-2008 08:54 AM

[Alan321981PG]

Ciao.

la procedura che mi hai inviato tu non funziona.

mi succede che a volte lo strumento a volte mi legge 41 byte come dovrebbe fare dal primo write e dopo mi legge solo 23 byte e però, cosa più grave non mi legge le risposte dello strumento dentro il for. ti posto il programma con i sub vi.

[Alan321981PG]

ho ipotizzato che il vi interfaccia.vi mi scriva contemporaneamente tutti sulla seriale allo stesso tempo. infatti mi da come byte count della prima lettura, quella più a sinistra, un valore casuale.

[RobertoBozzolo]

No, sicuramente non è così: tutti i vi visa sono messi in serie dal visa resource name e dal cluster di errore, il che basta garantire che siano eseguiti sequenzialmente (un vi non può essere eseguito se tutti i suoi ingressi non hanno un segnale: siccome per esempio il cluster error out è disponibile solo quando un sub-vi termina, quello posto dopo sullo stesso filo verrà eseguito dopo).

Piuttosto ho visto che non ci sono pause fra i comandi: sei sicuro che lo strumento sia in grado di digerire un colloquio così fitto?.

Comunque in primis io metterei config, open e close della seriale fuori del while, in modo da eseguirli una sola volta a inizio e fine programma: adesso apri e chiudi la seriale ad ogni ciclo del while, il che sicuramente fa perdere un bel po' di tempo e potrebbe forse anche spiegare alcuni malfunzionamenti del colloquio.

A livello concettuale poi ho visto che ci sono un sacco di bollini rossi (coercion dots) dove prepari i messaggi da mandare sulla seriale, perchè le costanti non hanno tutte la stessa rappresentazione: ti consiglio di formattare tutte le costanti come U8 in modo da evitare in partenza problemi di adattamento del tipo (in fondo alla fine devi arrivare a un array di byte singoli). Questo non avrà un effetto immediato sui tuoi problemi ma alla fin fine semplifica la lettura del diagramma e anche il lavoro del processore che non deve continuamente fare dei casting delle variabili. Anche la preparazione dei messaggi poi potrebbe essere spostata fuori del while visto che sono costanti in tutta la vita del programma.

Per il resto non vedo motivi evidenti per  le anomalie che trovi.

[Alan321981PG]

nonostante abbia apportato le modifiche consigliate e sapendo che il dispositivo gps può gestire scambi di messaggi fino a una frequenza di 10 hz non capisco perhè mi da solamente un pacchetto invece che tutti e tre. ho trovato che in certi punti error out era collegato con error in e resurce name con resurce name out ma anche dopo aver modificato mi da 18 byte del primo pacchetto invece che 41, 25/25 byte del secondo pacchetto e 0/15 byte del terzo pacchetto.

è possibile che i driver visa mi diano problemi. a proposito, utilizzo un dispositivo che mi rende disponibile una porta seriale da usb, con il programma di gestione proprietario della casa costruttrice del gps tutto funziona correttamente ed aggiorna molto intensamente i dati.

ciao,Alan.